Decompiler:

Reversing Compilation

Written By,
Tushar B Kute,
Lecturer in Information Technology
(K. K. Wagh Polytechnic, Nashik – 3, Maharashtra, INDIA)
Email – tbkute@gmail.com

Decompiler: Reversing Compilation -1-

Protection from Decompilers

As every coin has two sides, Decompiler also can be used positively or
negatively. License agreements don’t offer any real protection from a programmer
that wants to decompile your code. So to avoid misuse of this concept, we need the
ways to avoid misuse of Decompiler. That is, need of protection if decompiler is
misused.

Use of Obfuscator:

An obfuscator acts like a filter, removing any useful information such as

variable names and line attributes and only allowing the bare minimum of information
to pass through. Essentially the obfuscator parses the constant pool to find and then
rename all variable names and parameters. It is only been marginally effective, it
allows the class-file to run as normal and it prevents the decompiled code from being
recompiled. However that is not the end of the story. True, it is more difficult to
understand and recompile and once a class-file has been through an obfuscator we
can never recover the original variable names, but we could have accomplished
some of that by compiling.
Using some Obfuscator as many methods as possible are renamed a using
overloading where ever possible. Overloaded methods have the same name but
have different numbers of parameters. True, the overloaded methods are difficult to
understand but they are not impossible to comprehend. They too can be renamed
into something easier to read.
Some obfuscators have a far more aggressive form of obfuscation known as
high mode obfuscation. For example, Zelix Klassmaster encrypts all strings in a
class-file and Neil Aggarwal’s Obfuscate adds extra invalid entries to the symbolic
table rather like a bytecode manipulator. Unfortunately while they do succeed in
mangling the symbolic names beyond all recognition, some decompilers such as
SourceAgain can substitute new strings automatically.

Selling source code with application by charging extra

Some companies are finding that if source code is so readily accessible then
why not just sell it at a higher price. JClass is available from the KL Group as both
class file and source code. The difference in price is so small that it just doesn’t
make any sense to decompile, given the time and energy that is sometimes required.
We’ve already talked about the possibility of giving away our code at a higher price.
If the price is not too high we could convince the decompiler to pay for the code as
programmer’s comments are usually very informative. This won’t be for everyone but
why not make some money on the fact that some people will decompile our code to
copy it, so why not try to gain some revenue on these otherwise illegal activities.

License agreement

License agreements don’t offer any real protection from a programmer that
wants to decompile our code.

Code Fingerprinting

Decompiler: Reversing Compilation - 14 -

 In a court of law, one of the best ways of proving that an application or applet
was decompiled and recompiled is to show spurious code which has no function and
yet is in the original as well as the decompiled code.
However most decompilers will be able to spot spurious code put in there for
fingerprinting and it too will be ultimately useless, like stretching a watermarked
image to remove the watermark. Both JAD and SourceAgain can already search out
unexecuted code and remove it from the decompiled code.

IPR Protection Schemes

IPR protection schemes are one of the areas where real strides are likely to
be made in class-file protection. The logic behind IPR protection schemes with
respect to Java is that if we can’t get at the class-file then we cannot possibly
decompile it and to do that we need a secure browser cache.
Already secure browsers that don’t dump class-files, HTML or images to the
Internet Explorer or Netscape Navigator cache are on the market. Breaker
Technologies have a secure browser and IBM’s CryptoLive claims to have one and
no doubt there are others. For the moment this technology is in it’s infancy but
expect it to grow.
Intellectual Property Rights (IPR) protection schemes such as IBM’s
Cryptolope Live or InterTrust’s DigiBox and Breaker Technologies’ SoftSEAL are
normally used to sell HTML documents or audio files on some pay-per-view basis or
pay-per-group scheme. However as they typically have built in trusted HTML viewers
they allow Java applets to be seen but not copied. Unfortunately IPR protection
schemes are not cheap. Worse still some of the clients are written in 100% pure
Java and can therefore be decompiled. Similar protection schemes in the future are
likely to provide the best chance of success in nailing the decompiler issue once and
for all.

Executables applications

The safest protection for Java applications is to compile them into

executables. This is an option on many Java compilers, for example SuperCede.
Your code will now be as safe as any C or C++ executables – read a lot safer – but
are no longer portable as they no longer use the JVM.

Keeping code on server side

The safest protection for applets is to hide all the interesting code on the web
server and only use the applet as a thin front end GUI. However this increases web
server load and goes against the Java methodology.

Decompiler developer’s develops obfuscator

Crema is the original obfuscator and was a complementary program to the

above mentioned Mocha. Of course we know Mocha was given away free but Crema
cost somewhere around $30 and to safeguard against Mocha we had to buy Crema.
It performs some rudimentary obfuscation as we’ll see later and it also has one
interesting side effect. It flags class files so that Mocha refuses to decompile any
applets or applications that had been previously run through Crema. However other
decompiler soon came onto the market which was not so Crema friendly. Now we

Decompiler: Reversing Compilation - 15 -

find obfuscators and decompilers are in what we could describe as a cold war
scenario without any entente cordiale. So far the decompilers are winning but that’s
not to say the climate won’t change.

Best Defense

It is said that perhaps the best defense is to provide a stable, useful

application with all the usual phone support and good documentation. The majority of
our customers will much prefer a supported application than an illegal copy that they
will have to support themselves. So before we start worrying too much about
decompilation, remember that people need someone to shout at when things go
wrong.

Drawbacks

• Functionality not user Friendly: Using Decompiler’s i.e. getting full use of
Functionality of Decompiler is not much user friendly, some times due to need
of technical background, lack of GUI.
• Presence of Larger Size of Source Code: It is harder to get source code back
from larger size of decompiled data. For e.g. Decompiling Office 97 using dcc
(A Decompiler) would create so much code that it is about as user friendly as
debug or a hexadecimal dump. Most modern commercial software’s source
code is so large that it becomes unintelligible without the design documents
and lots of source code comments. Let’s face it; many people’s C++ is hard
enough to read six months after they wrote it. So how easy would it be for
someone else to decipher C code that came from compiled C++ code without
any help even if the library calls aren’t traversed?
• No GUI for older ones: As older Decompiler’s where mainly used by
developers hence the lack GUI which is common for many softwares, hence
due to lack of GUI handling Decompiler becomes harder.
• Compiler Dependent: As Design of Decompiler depends on compiler for which
it is been developed. Hence change in compiler causes to write updated
Decompiler.
• Increasing Trend towards Stealing code: Habits of using Decompiler are
increasing trends towards stealing code other than for educational purpose.
• Giving Trusted Secrets to Competitors, Hackers: Using Decompiler the
competitors, hackers can get inside the product and can acquire Trusted
Secrets, which else was hard to known.
• Security holes Exposed: The security holes can be made public using
Decompilers in software developed.

Conclusion

• The future of decompilation and obfuscation techniques looks like being fairly
reminiscent of the Cold War. An arms race is brewing between the decompiler
developers and the obfuscator developers. Oddly enough these are often the
same companies trying to break a rival’s product and then sell there own
obfuscator as the only 100% secure solution.
• The Attitude towards Decompiler’s is needed to be changed, as there are
many positive uses of this concept, so more attention is needed to be given to
this concept.

Decompiler: Reversing Compilation - 16 -

 • More research is required in executable to assembly code decompilation.

References

• Thesis paper by Cristina Confluents On “Decompiler Techniques”.

• http://www.riis.com/book
• http://www.debugmode.com/index.htm
• http://www.program-transformation.org
• http://www.itee.uq.edu.au/~csmweb/decompilation/
• http://www.decompiler.com/
• http://en.wikipedia.org/
• http://research.sun.com/research/people/cristina/index.html
• Google Groups at http://www.google.com/
• E-book On Building decompilers http://www.riis.com/book
• “C Column Collection” by Yeshwant Kanetkar

----------------

Decompiler: Reversing Compilation - 17 -