Java Coffee Break

DECOMPILERS
How do they work?
Uses of decompilers

CONCLUSION
Summary
Resources

Software that examines software

Decompilers are programs that analyze compiled code, and from this, reconstruct the original source code. Decompilation and reverse engineering is often prohibited by software license agreements - but this won't always stop an unscrupulous competitor, or an enthusiastic hacker from analyzing your code. Decompilers are freely available for a variety of languages and platforms, including Java! Read on, and I'll introduce you to the world of decompilation.

How do they work?

Decompilers work by analyzing the byte code of software, and making educated guesses about the code that created it. Most classes also contain additional debugging information, which can help the decompiler create a more accurate representation of the original source code. This debugging information is invisible to normal users, and many programmers don't even realize just how much information can be obtained from their classes - but there are ways to protect your code.

Software is available that will strip away debugging information, and even change the names of local and member variables inside your classes. SourceGuard, for example, will rename your variables to meaningless names, which decreases the readability of decompiled source. When you protect your code with applications like SourceGuard, decompilers have less information on which to base their analysis on, and it becomes harder for programmers to understand the code they produce.

// Calculate difference in dates
long numericalDifference = m_Date.getTime()
     - currentDate.getTime();

// Divide by 1000 to find number of seconds difference
numericalDifference = numericalDifference / 1000;

// Get seconds
int seconds = (int) numericalDifference % 60;

// Get minutes
numericalDifference = numericalDifference / 60;
int minutes = (int) numericalDifference % 60;

l = (this.B.getTime() - 
    ((java.util.Date)(obj)).getTime());
l = (l / 1000);
i4 = (((int)l) % 60);
l = (l / 60);
i3 = (((int)l) % 60);
l = (l / 60);

The success of decompilation varies upon the amount of protection that software developers use, and the decompiler software that one uses to decompile. Many decompilers fail to decompile correctly, and some will even produce code that won't compile - particularly when faced with strong protection from a product like SourceGuard which offers a feature called byte-code range modification. BRM prevents most compilers from decompiling methods that have try { } catch blocks, and will produce garbled code with most decompilers.

Preventing decompilation is a valuable feature. Of course, such protection isn't uncrackable. While there are plenty of free decompilers out there, you really get what you pay for. With free tools, the code that is produced ranges from complex to unusable when protected by a tool that is decompiler resistant. With commercial tools, you can get varying degrees of success, and at least one tool is capable of breaking the byte-code range modification technique of SourceGuard.

SourceAgain, by Ahpah Software Inc, is capable of decompiling BRM protected classes effectively, and produces much more readable code than free software like Mocha or DejaVu. SourceAgain is available in three versions, a standalone decompiler, a professional edition that integrates with Symantec Visual Cafe and Microsoft Visual J++, and a Unix version. For those interested in using decompilers, a trial of SourceAgain is accessible from the web, and it can decompile classes that are accessible from a http:// address.

Uses of decompilers

While decompilers do represent a threat, they also can be of great benefit to programmers. There are many legitimate purposes for decompilers, such as reconstructing lost source code from a binary executable. When an old application needs to be upgraded or modified, and the original source code isn't available (perhaps the company which commissioned it never received the original source code, or perhaps the source code was lost because it wasn't considered import enough to backup), reverse engnieering through decompilation can be very useful. Some companies might decompile software of a competitor, to establish the structure of data files to include support for that filetype in their application. Whether or not such actions are legal is a gray area, but including support for competing spreadsheets, word processors, databases, etc is handy for end-users.

Summary

Decompilers aren't necessarily evil - but they do pose an ethical dilemma for many software developers. You can also protect yourself against decompilation (or at least make the task harder), by using special software that protects your executables from prying eyes. All developers should be aware of the risks of decompilation, and should consider protecting their Java applets and applications against reverse engineering. Decompilers offer great potential for legitimate purposes, but can also be used to steal the source code of competitors, or by hackers to determine weaknesses in the design of software. But just don't blame the compiler - its the programmer who uses it for intellectual property theft, or the hacker that decompiles the software to find security holes that is at fault!

Resources

• Mocha, the decompiler
• SourceGuard, from 4thPass Software Corporation
• SourceAgain, from Ahpah Software Inc