Makes me wonder what exactly Teh Freak said to him to get this…
edit:
It works, but it is very very slow, uses 100% of the CPU quite a bit and a lot of RAM. That isn’t necessarily a bad thing though, if it does it’s job right. I’m attaching to this post the decompiled version without renamed variables, and one with once it finishes. To be able to recompile it I need to find all the jars runescape links to now (directx, opengl, netscape), does anyone have links to them or something?
There also seems to be some other various errors during recompiling, but until I get those other jars, I’m not sure how serious they are or even if the other jars can help fix them.
This functionality looks great:
[code]5. Renaming identifiers
Some obfuscators give classes and their member elements short, meaningless and above all ambiguous names. Recompiling of such
code leads to a great number of conflicts. Therefore it is advisable to let the decompiler rename elements in its turn,
ensuring uniqueness of each identifier.
Option ‘ren’ (i.e. -ren=1) activates renaming functionality. Default renaming strategy goes as follows:
- rename an element if its name is a reserved word or is shorter than 3 characters
- new names are built according to a simple pattern: (class|method|field)_
You can overwrite this rules by providing your own implementation of the 4 key methods invoked by the decompiler while renaming. Simply
pass a class that implements de.fernflower.main.extern.IIdentifierRenamer in the option ‘urc’ (e.g. -urc=com.mypackage.MyRenamer) to
Fernflower. The class must be available on the application classpath.
The meaning of each method should be clear from naming: toBeRenamed determine whether the element will be renamed, while the other three
provide new names for classes, methods and fields respectively. [/code]
Because it would be easy to write a class that renames the client based on an updater’s output, not so much for use in cheating as for making it easier and more comfortable to examine the client source code.