|
When a programmer writes
software, and releases it to the public, he (or she) normally
releases a compiled version of the application, that users can run on
their own machine. Whether it is a commercial offering, or a free piece
of software, the programmer has put a considerable amount of time and
effort into producing it. The source code behind software is something
private, that the programmer has created. Programmers don't want people
looking for flaws in their software, and they don't want people to
change the title of the software and then redistribute it as someone
else's product. It is for this reason that programmers don't often
release their source code - but few realize that every time you release
compiled software, you are also giving people the opportunity to
reconstruct the source code!
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.
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;
|
|
Original source code |
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);
|
|
Source decompiled with Mocha, after
SourceGuard protection |
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.
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.
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!
|
