So I have managed to automatically de-obfuscate an obfuscated Java project. Remember, there are 2 major challenges in reverse engineering: 1) Understanding the original code flow, and 2) understanding what the original identifier names could have been. My experiment was focused on problem #2. Problem #1 is generally a non-issue in decompiled Java code since Java classes retain so much information about the original code flow.

Are there better approaches for obfuscating Java code?

Read the rest of this entry »

For those who would like to try out the RetroGuard program, only modified to be a quasi-de-obfuscator, check out Deobfuscating Obfuscated Code With RetroGuard. It explains everything you need to know about running the experiment.

This evening, I implemented the VerbNameMaker Java class for the Retroguard project by simply copying the NounNameMaker class and replacing the animal list with a list of English verbs extracted from verba.org. So the class picks a random verb from a list of over 4000 verbs and replaces obfuscated method names. Remember that dequantizer method from the previous post? Guess what the new Java class, working in conjunction with Java’s random number generator, decided to name the method?

    private void fondle(int i)
    {
        short aword0[] = australianKestrel[i];
        for(int j = 0; j < 64; j++)
            kingsnake[eastAfricanCrownedCrane[j]] = aword0[j] * conch[j];
    }

Just as I have long suspected, Java is a sick, perverted language.

Read the rest of this entry »

So I finally managed to recompile the Retroguard project. Then I created my own class to help in de-obfuscating obfuscated Java source code. The first part of this exercise is to de-obfuscate fields, i.e. nouns. For my list of nouns, I used this impressive list of animal names (2400+).

Read the rest of this entry »

I am not especially proficient in understanding software projects that were written in an excessively object-oriented manner, as languages like C++ and Java encourage a programmer to do. So I had trouble getting my head around the GPL’d source code for the Retroguard Java obfuscator, which I had hoped to subvert into a source code de-obfuscator. Fortunately, Doxygen proved invaluable for generating documentation and hierarchy diagrams that helped illustrate the program’s architecture (I think Javadoc can be used for the same purpose, but I find that Doxygen is easier to install). I think I see where I can hook in to get a basic de-obfuscator.

Read the rest of this entry »

Welcome to another edition of my personal multimedia research scratchpad. Diego Biurrun forwarded some intelligence about some custom Java image formats. It seems that a company named eyewonder has seen fit to develop a streaming video technology aimed at delivering obnoxious short ads delivered via Java applets.

So, custom Java image formats. Or, more likely, a slightly customized image format that is presently only decodable via some proprietary Java class. As is typical, it is difficult to glean any useful technical details from the website. But if the marketing literature is to be believed, this stuff has caught on in a big way.

Read the rest of this entry »

Just found this proprietary program: YourKit Java Profiler. One of its many touted features is automated de-obfuscation. Based on the site copy, I get the impression that it uses log files generated by various code obfuscators to do a search and replace. Darn. Not quite what I was hoping for.

If they value their intellectual property, responsible Java-developing software companies use some kind of code obfuscator as part of their build process. This way, there is very little chance that a Java class file will be unleashed that retains the original identifiers. One such Java source code obfuscator is called Retroguard. But can the tool be used for its opposite purpose?

As an aside, I need to point out some irony: I once took a Java course where the instructor claimed that Java is desirable to proprietary software outfits because it can be compiled, and IP implicitly guarded, whereas programs written in interpreted languages, notably Perl, need their source code redistributed. In fact, Java code is very trivial to decompile, whereas languages like Perl can be compiled for redistribution.

Read the rest of this entry »

The Jad Java Decompiler has a wonderful logo:

Oh Java, for so long I wished I would not have to deal with you in any meaningful way. Now, I welcome your bloated, verbose, object-glorifying code. What changed?

Read the rest of this entry »