Tuesday, December 20, 2005

The Problem With Java Client Development

I love Java as a language and as a platform. It is a very clear language to understand and there is a plathora of code available on the web for you to put together a relatively complex application together in no time. It has the support of far too many companies to mention here and it also has the seal of approval from Open Software and Free Software developers.

I recently looked up into decompilers for Java programs and I was horrified to see the results. A Java program can be decompiled back into its original source code with very little work. There are many free and commercial decompilers available. I decompiled one of my older programs that I made for a client (who never paid up) and it was converted back into its original source code within seconds.

This prompted me to look up into how I could make sure that my Java programs would be safer from decompilation. There are 3 techniques to do so:

  1. Obfuscation: This is the process of changing the class / method / variable names so that they are not easy to interpret once decompiled. It does not stop decompilation though, just makes it slightly more irritating for the one who is trying to decompile your code. But keep in mind that it does not change the names of the core Java API packages/methods etc. So your algorithms are pretty much given away to the one hacking your code.

  2. Compilation to Native Code: You can compile your Java code to Windows or Linux native code like for a C/C++ program which can be decompiled but not easy to make sense of the decompiled code. A person like me will not be able to do it. Two programs used by programmers are the commercial Excelsior JET and the open source GCJ. Excelsior JET has licenced the J2SE code from Sun Microsystems so your code will not break at all. GCJ still lacks a lot of J2SE packages and classes (e.g. there still no AWT implementation). So your code will break a lot.

  3. Light-Weight Clients: This is a client / server approach for applications where the actual bulk of the program logic resides on a server and the client is mainly used for display purposes. So if the end user decides to decompile the Java client the most he will get out of it is the code for displaying. He will not be able to alter how the logic of the program actually works. This might be perfect for enterprises that will deploying the application in an intranet environment but it is not sufficient for standalone everyday use applications like editors, mail clients etc.

Come to think of it all those free applets out there can be easily decompiled, code changed, your company logo added and then served on your own webpage without anyone ever finding out.

I think Sun Microsystems should provide a free compile to native code compiler with their SDK for people who want to keep their source code safe from hacking attempts.