Originally Posted by diba
Amazing, could not resist to check immediatelly. How the f... do you do all this stuff?
Well, it's a combination of curiosity, patience (to the point of masochism at times) and the will to break out of the Matrix and defeat the system... backed by 15+ years of reverse engineering experience, continuous learning and (in this case) relatively good knowledge of some of the more scary internals of Java.
Still, I would never have been able to do this without the truely excellent serp bytecode manipulation framework
. In fact, I had used it for the first time for the localization, so without that, maybe this wouldn't even have crossed my mind. So you see, it's all a continuous process
BTW, it's astonishing with how little code (and relatively little effort, actually) this works. All of this together is only around 400 lines of code for now, and it's amazingly elegant (I think). You can simply decompile the code and you'll see
In short, the way that it works is by injecting a ClassLoader in the hierarchy as early as possible, which can then intercept all class load requests. And instead of loading classes normally, it can modify them (using the mentioned serp library) before
they are loaded. This means that as little or as many changes as you want can be made. For example, the actual "TTS enabling" patch changes exactly one opcode, and consists of 7 lines of code in total.
Note that this is not fully dynamic, because classes cannot be redefined at runtime, but only once at load time. This is a limitation of the underlying JVM itself. Still, we can essentially arbitrarily change all classes without needing to touch a single original file. (Well, yeah, one. The configuration file