The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

dwschulze (36) [Avatar] Offline
#1
We will have the need to prevent reverse engineering of our Java source code which is currently distributed as .war files. The most interesting way I've seen of doing this is by encrypting the .jar files. This requires a custom classloader to decrypt the .jar files. Our target is currently Glassfish 3.1, but I can't find anything on what it would take to replace the appropriate Glassfish classloader with a custom classloader that would decrypt our .jar files.

Would distributing our binaries as OSGI bundles be a better way to go since I would also have to load them with a custom classloader?

I'm groping in the dark with this as there doesn't seem to be any serious work done to prevent reverse engineering of Java EE binaries (.war and .ear files).

Thanks.
timothy.ward (8) [Avatar] Offline
#2
Re: Is it possible to prevent reverse engineering of an OSGI bundle?
Hi,

It seems to me that what you're looking for is an obfuscation rather than encryption.

Using a custom classloader to decrypt the archive will prevent the jar from being opened easily outside of the server, but it will not prevent the application from being able to load (and output) its own contents if the resources are present in the .war/.ear binary.

In order for the WAR to work it needs to be able to access things like properties files and classes that are on its internal classpath, so the encryption really doesn't help here.

If you are really concerned then you could obfuscate your code. This would make reverse engineering (but also debugging) much harder.

As for OSGi, it is the OSGi framework that creates the classloader so you would need to add some sort of plugin. You could potentially use a WeavingHook to decrypt the application bytes, but this would require at least some of the application to be packaged without encryption to bootstrap the WeavingHook implementation.
dwschulze (36) [Avatar] Offline
#3
Re: Is it possible to prevent reverse engineering of an OSGI bundle?
Obfuscation provides very little protection against reverse engineering. It also introduces a bunch of problems. All of your public interfaces (Web Services and SessionBeans) have to remain unchanged. Strings that you use to do JNDI lookups have to remain unchanged. The log files become a mess.

And after all of that you've accomplished very little in terms of preventing reverse engineering.

When I look at the classloader hierarchy in Glassfish it looks like I would need to replace the Archive classloader:

http://download.oracle.com/docs/cd/E19226-01/820-7695/6niugesfp/index.html#indexterm-28

The Glassfish docs don't say how their classloader hierarchy is related to OSGI and bundle classloaders. That's what I'm trying to figure out.
timothy.ward (8) [Avatar] Offline
#4
Re: Is it possible to prevent reverse engineering of an OSGI bundle?
I agree that obfuscation isn't a pleasant thing to do, and I wouldn't do it myself.

I don't think that Glassfish will offer a way to replace the underlying OSGi classloader, but neither of us are involved with developing Glassfish so that isn't a guarantee.

I would be interested to know how a decrypting classloader protects you from clients calling getResourceAsStream() and writing out the stream content. Doesn't this give you a decrypted version of the output and make the encryption pretty easy to work around?
dwschulze (36) [Avatar] Offline
#5
Re: Is it possible to prevent reverse engineering of an OSGI bundle?
There are ways around encrypting .jar files, but my purpose is to make it so it is not so easy to reverse engineer the code.

There is an interesting product here (it's been dormant for some time):

www.componio.com/support/jinstaller/jinstaller_faq.html

It uses a native library in addition to a custom classloader to make it more difficult to intercept the decrypted classes.

If this product were still alive I would use it, but it looks like I'll have to roll my own.