| Developer's Daily | Java Education |
| front page | java | perl | unix | DevDirectory |
The conversion
The conversion of our own AnimatedAd.class file back into a Java source code file was frightening. Frightening in it's accuracy.
If you'll remember from Part 2 of our story, we used the Mocha decompiler to reverse-engineer one of our own Java applets (our AnimatedAd applet) back into a Java source code file. That's where Part 2 of our story ended, and Part 3 begins.
I've seen this code somewhere before ...
After the reverse-engineering, the AnimatedAd.mocha file (the generated source code file) displayed the exact same variable names that we used in our original AnimatedAd.java source code. Not just one variable here and there - every variable in the class had the exact same name.
As we dug into the code, we found several differences in syntax between our original Java code and the reverse-engineered code, but nothing that kept the reverse-engineered code from compiling. In one location, Mocha turned a while loop into an equivalent for loop. It also didn't use our initial array-sizing variables when declaring several arrays. However, the reverse-engineered Java code easily compiled, and there is no visible difference between our original Java applet and the reverse-engineered Java applet.
If you're interested in protecting your code, the one positive thing I can say is that fortunately Mocha has no way of bringing our source code comments back to life. This makes the reverse-engineering task a little more difficult, especially if you have a complex code where comments would be very helpful.
We planned a thorough discussion of the decompilation results of this applet, but the plain fact is that it worked with no significant problems. If you're interested in comparing the two versions of the code yourself, you can download them here:
Mocha was certainly helped by the fact that our code was written for JDK 1.0.x -- we wanted to make sure that this applet would run in almost every browser available. We haven't tested Mocha or other products against JDK 1.1 classes yet, and can't comment on how it will work against these classes. However, several of the companies listed below state that their products are very successful against Java JDK 1.1 classes. (We'll examine these products in our next article as we try to defeat decompilers with their arch rival, Java obfuscators.)
In an initial effort to fight against decompilation, a product named Crema was created at the same time as Mocha. Crema was one of the first (probably the first) Java source obfuscators. However, for every cause there is an effect, and a product named Jasmine (a patch to Mocha) was created to defeat the Crema obfuscator. We tested Jasmine against our AnimatedAd applet and it too had no problems reverse-engineering the bytecode.
In an effort that reminds me of a recent story about a fireman that
was arrested for starting fires to homes, another company named Ahpah
seems to be pushing both ends of the decompiler/obfuscator barrel.
Currently they offer a commercial Java class decompiler product named SourceAgain.
SourceAgain has received good reviews for it's reverse-engineering capabilities.
According to the information on their web site, it appears that Ahpah also
plans to offer an obfuscator product in the future to defeat their own
decompiler.
Other decompiler tools
As we mentioned in one of our earlier articles, Mocha is probably not the best decompiler on the market. It certainly is not the most recent. With the death of the original author, the version of Mocha we used hasn't been updated since 1996. Nonetheless, it obviously works very well.
Here's a list of several Java bytecode decompilers we found while doing our research:
Of course, don't forget that there's also a Java JDK command named javap
that partially disassembles Java class files. This is a good
command if you just want to find out certain information about a class,
such as the names of methods and variables, without completely disassembling
the class.
What can we do for protection?
In the next article in our series, we're going to discuss products and approaches that you can use to try to protect your Java code from those in the world that would like to decompile your Java software. These products are typically called obfuscators. We'll try a simple experiment to try to obfuscate our code, and then try to reverse-engineer the obfuscated code to see how the various products stack up.
We'll complete our series with a full listing of every decompiler/obfuscator
resource we can locate, including tools, articles, and reviews, to help
you protect your Java assets.
Copyright 1998-2009 Alvin Alexander, devdaily.com
All Rights Reserved.