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?
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.
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+).