Spring and Obfuscationen

[cm sannies]

Hi,

my task is to remove the Spring Configuration XML to enable full obfuscation.
There are oviously 2 ways of doing so:
1. Rename all bean classes, etc. in the config file according to obfuscation. Hmm - I don't like that.
2. Do all application context definition in Java, so that the obfuscator can obfuscate the code. Is there a simple way? Implementing the WebApplicationContext does not seem a good idea. Using StaticWebApplicationContext is not intended as stated in javadoc, nevertheless it seems to be a possibility - a very complicated possibility.
Is there a way to instantiate a bunch of objects and make that bunch a applicationContext?
Or does anybody know a better possibility to use spring in conjunction with obfuscation?

Thanks in advance,
Sebastian

[Kees de Kooter]

I think the solution is to obfuscate the applicationcontext.xml as well. There are obfucation tools out there that can do that.

[jbetancourt]

You could have a bean, ObfuscatedApplicationLoader, that contains or loads a String that is encrypted or obfuscated. That String contains the application context definition. I think you can then create a resource of that String so that it can be loaded with one of the xml application context bean loaders.

Of course, this bean would not be part of any application context definition.

[Cowboy Bob]

You do realise that obfuscation is a complete waste of time anyway? There are tools out there that will be able to decompile your code no matter what you do. Security by obscurity never works.

[cm sannies]

Cowboy Bob: You do realise that there are necessities beyond reason? My boss wants it - so the discussion is wasted time.

jbetancourt: Embed an encrypted applicationContext.xml into my application? Ok, but how do I get my classnames in that file obfuscated according to the obfuscation tool?

There comes Kees de Kooter: You tell me that there are tools that can obfuscate applicationContexts but can also tell me these tools' names? That would help a lot.

Thanks,
Sebastian

[Kees de Kooter]

Sorry Sebastian, didn't mention the name because I am not too keen on plugging commercial products. But this one seems to be free.

It is yGuard: http://www.yworks.com/en/products_yguard_about.htm

[jbetancourt]

At a prior company we looked at obfuscation. What a pain, and ultimately, as Cowboy Bob mentioned, not a foolproof way to protect code. I was surprised that even encryption of classes is also problematic. Also, if dynamic techniques such as reflection, aop, and class loading, not sure some things will not even work. Does not work with EJB, for example.

[Costin Leau]

I agree with jbetancourt - obfuscation doesn't work very well from my experience - the names of methods are changed and the appcontext and any other reflection mechanism has to be updated as well. There are some solutions out there which involve custom classloaders that can encrypt and decrypt class definitions once they are loaded but this is not an option once you have to supply your product packaged as a war/ear for usage on the client own server stack.
Moreover, we had to change the way we reported bugs and our logging messages since they didn't made any sense.