As every coin has two sides, Decompiler also can be used positively or negatively. License agreements don\u2019t offer any real protection from a programmer that wants to decompile your code. So to avoid misuse of this concept, we need the ways to avoid misuse of Decompiler. That is, need of protection if decompiler is misused.
An obfuscator acts like a filter, removing any useful information such as variable names and line attributes and only allowing the bare minimum of information to pass through. Essentially the obfuscator parses the constant pool to find and then rename all variable names and parameters. It is only been marginally effective, it allows the class-file to run as normal and it prevents the decompiled code from being recompiled. However that is not the end of the story. True, it is more difficult to understand and recompile and once a class-file has been through an obfuscator we can never recover the original variable names, but we could have accomplished some of that by compiling.
Using some Obfuscator as many methods as possible are renamed a using overloading where ever possible. Overloaded methods have the same name but have different numbers of parameters. True, the overloaded methods are difficult to understand but they are not impossible to comprehend. They too can be renamed into something easier to read.
Some obfuscators have a far more aggressive form of obfuscation known as high mode obfuscation. For example, Zelix Klassmaster encrypts all strings in a class-file and Neil Aggarwal\u2019s Obfuscate adds extra invalid entries to the symbolic table rather like a bytecode manipulator. Unfortunately while they do succeed in mangling the symbolic names beyond all recognition, some decompilers such as SourceAgain can substitute new strings automatically.
Some companies are finding that if source code is so readily accessible then why not just sell it at a higher price. JClass is available from the KL Group as both class file and source code. The difference in price is so small that it just doesn\u2019t make any sense to decompile, given the time and energy that is sometimes required. We\u2019ve already talked about the possibility of giving away our code at a higher price. If the price is not too high we could convince the decompiler to pay for the code as programmer\u2019s comments are usually very informative. This won\u2019t be for everyone but why not make some money on the fact that some people will decompile our code to copy it, so why not try to gain some revenue on these otherwise illegal activities.
In a court of law, one of the best ways of proving that an application or applet was decompiled and recompiled is to show spurious code which has no function and yet is in the original as well as the decompiled code.
However most decompilers will be able to spot spurious code put in there for fingerprinting and it too will be ultimately useless, like stretching a watermarked image to remove the watermark. Both JAD and SourceAgain can already search out unexecuted code and remove it from the decompiled code.
IPR protection schemes are one of the areas where real strides are likely to be made in class-file protection. The logic behind IPR protection schemes with respect to Java is that if we can\u2019t get at the class-file then we cannot possibly decompile it and to do that we need a secure browser cache.
Already secure browsers that don\u2019t dump class-files, HTML or images to the Internet Explorer or Netscape Navigator cache are on the market. Breaker Technologies have a secure browser and IBM\u2019s CryptoLive claims to have one and no doubt there are others. For the moment this technology is in it\u2019s infancy but expect it to grow.
Intellectual Property Rights (IPR) protection schemes such as IBM\u2019s Cryptolope Live or InterTrust\u2019s DigiBox and Breaker Technologies\u2019 SoftSEAL are normally used to sell HTML documents or audio files on some pay-per-view basis or pay-per-group scheme. However as they typically have built in trusted HTML viewers they allow Java applets to be seen but not copied. Unfortunately IPR protection schemes are not cheap. Worse still some of the clients are written in 100% pure Java and can therefore be decompiled. Similar protection schemes in the future are likely to provide the best chance of success in nailing the decompiler issue once and for all.
The safest protection for Java applications is to compile them into executables. This is an option on many Java compilers, for example SuperCede. Your code will now be as safe as any C or C++ executables \u2013 read a lot safer \u2013 but are no longer portable as they no longer use the JVM.
The safest protection for applets is to hide all the interesting code on the web server and only use the applet as a thin front end GUI. However this increases web server load and goes against the Java methodology.
Crema is the original obfuscator and was a complementary program to the above mentioned Mocha. Of course we know Mocha was given away free but Crema cost somewhere around $30 and to safeguard against Mocha we had to buy Crema. It performs some rudimentary obfuscation as we\u2019ll see later and it also has one interesting side effect. It flags class files so that Mocha refuses to decompile any applets or applications that had been previously run through Crema. However other decompiler soon came onto the market which was not so Crema friendly. Now we
Now bringing you back...
Does that email address look wrong? Try again with a different email.