How can I prevent reverse engineering of JavaEE 6 .war files?

Question

We have several JavaEE 6 applications (.war files) that we need to protect against reverse engineering, but there don't seem to be many options available.

I like the idea of an encrypted .jar file (SJAR) used in the JarCrypt/JInstaller products, but it's not clear that JarCrypt/JInstaller will work in a JavaEE 6 app. server like Glassfish3.1. The encrypted SJAR files have to be decrypted by a native library using a custom classloader, so apparently I would have to add a custom classloader to Glassfish.

Has anyone used the JInstaller / JarCrypt technologies? Do they work in an Application Server?

I've also looked at obfuscation, but for JavaEE applications there are lots of problems. I would have to leave all web services and JNDI lookups alone. Use of things like a.b.c.MyClass.class (i.e. to create log4j Loggers) is problematic. Reading log files becomes difficult. And for all of those problems obfuscation does next to nothing to secure our code.

I've tried Proguard, but apparently it can't deal with the JavaEE 6 libraries.

Are there other alternatives or are these about all the options I have?

Thanks.

Answer 1

Are you shipping those apps to third parties who will be running it on their infrastructure? Then encryption won't help you at all, because the JVM cannot execute encrypted bytecode, and it is trivial to retrieve the loaded class files from a running app.

Take a look at GuardIT for Java - to date I have had no experience with it, but at least the vendor claims it is specifically designed to protect Java Web apps.

If your apps run on Tomcat, you could have compiled them down to native code. Or do they need a full Java EE app server?

Answer 2

I have been working on software protection for the past two years and I have evaluated most of the European solutions on the market (sorry, we avoid American solutions...).

There are four techniques that we have seen as protection solutions: - Obfuscation - Encryption - Compilation to native code - Transcoding

You probably know most of these techniques except for transcoding.

Obfuscation requires a lot of work for what is, in the end, poor protection. But you can combine obfuscation and with all of the other techniques.

Encryption is pretty easy to break (there is no solution for storing the key in a safe area; even with a Dongle it is easy to retrieve). Further, there is a work around to steal decrypted classes from memory (or, more directly, the encryption key).

Most Java developers think that compilation to native code provides good protection... But, it does not provide protection at all; for more than 20 years it has been possible to reverse native code and there are some very skilled reverse-engineers to do this. There are also some good reverse-compilers to C language to help...

Finally, there is Transcoding (of which there is very little information on internet). This is the only efficient protection against skilled reverse-engineers. It is a pain to break because it requires years of work. It is not impossible but demands a very, very long time.. Further, every time a new patch is released, you must restart reverse engineering again because at each release, the code is totally different. Is there a drawback? Yes, performance. But it can be combined with all the other techniques and there are no deployment limitations (application server, dynamic class generation, etc.) or Java limitations (reflection, etc.).

There is no silver bullet. Each solution can be used depending of your target. Protecting against a government or against script kiddies is not the same... Choose a solution relative to the pros and cons, and more importantly, relative limitations (like Jarcryp and obfuscation on web application).

To answer to the question about Jarcryp (and other solutions doing encryption), it is possible: you just need to ask to Componio (providing JInstaller/Jarcryp) to give you a classloader that inherits from the application server class loader that you use.

Transcoding works with all application servers.