This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I decompiled my own class files recently to find that the decompile was quite close to the original code i had written. Even after obfuscation by retro guard i find that the code decompiles great with the only difference being that the variable names are some what obscure. Is there an obfuscator out there that renames and rearranges the code enough to confuse the decompilers without sacrificing performance !? I have also tried jobfuscate. Please voice out your opinions on this and name a few obfuscators that you know of.
I gave encrypting the class files a thought but that wont be fool proof like you mentioned. This is the first time i am hearing about gcj. I ll give gcj a shot tonight and look at how well the decompiler can reverse engineer it. Thanks
The vmspec. is easy to read. All one need to do is become capable of emulation of a JVM through spatial experiment - a trivial task. The most extreme obfuscation only requires more spatial ability. It is futile at best and self-referential falsification at worst.
So would you say that the best way to write code would be to obfuscate it when you write it and then run it through an obfuscator to make life hell for the guy thats trying to read it ? Sounds good if we cant prevent the class from being decompiled to begin with.
Joined: Feb 16, 2005
Security through obscurity always fails.
I always advocate writing clean code, and then making sure that all IP claims and copyright terms are specified in the license. There is no way to stop a determined enough person from reverse engineering your code. If, however, your contract specifies that to do so is grounds for legal action, you are safe. And you make the life of maintenance developers that much more pleasant.
Joined: Sep 24, 2003
Originally posted by John Meyers: Sounds good if we cant prevent the class from being decompiled to begin with.
It is possible (though not necessarily desirable) to create a theorem prover that proves that it is impossible to "prevent the class from being decompiled to begin with" - so what now?