2007-06-20

Eclipse aware Java Obfuscator wanted

It is not the first I have heard this request from a customer: how do we obfuscate the Java code for an Eclipse RCP based application? Because it is not as trivial as it might seem.

There are a number of problem with obfuscation of Java code when using Eclipse RCP:
  • Any class that is mentioned in the plugin.xml should either not be obfuscated or the plugin.xml should be changed as well.
  • Any Java package that is exported by a plug-in, should not be obfuscated as other plug-ins might depend on these.
Of cause it is possible to built a list of packages and classes that should not be obfuscated by hand, but this is Eclipse - the tool integration platform - so it must be possible to automate this work.

Has anybody done this? Any pointers to obfuscation applications and Eclipse plug-ins will be appreciated.

10 comments:

Pascal said...

Someone from our VM team had done a prototype a while back, however it never graduated to anything concrete and through bug reports coming in PDE build I gathered that other people have done it. However nothing public to my knowledge.
This sounds like a fine technology or equinox incubator project.

On the technical points, the difficulty are that if you do not obfuscate the packages that are exported, in the case of eclipse plug-ins nothing would get obfuscated since everything is exported. Of course you could use the x-internal / x-friends markup in the APIs but that would mean that no internals are ever used.

Anyway the approach is good, we just need code :-)

Looking at the APIs and

Patrick Paulin said...

My experience is that it's actually not that hard to obfuscate without an Eclipse-specific tool, but you're right that it would be nice. The main problem I've had is that you forget to add a new class as an exclusion and then your app blows up. But once this happens a few times, you can quickly diagnose and fix the problem.

To make the process easier, you need to clearly distinguish between internal and external packages and put as much code into internal packages as possible. You can also obfuscate much of the code in external packages, just not the package names and classes referred to in extension points. And even these classes can have their internals obfuscated.

I wrote an article a while back on this topic and just reposted it to my current blog.

If you find something out there (or build something) that makes the process easier, I'd love to hear about it.

Unknown said...
This comment has been removed by the author.
Unknown said...

What about obfuscate4e?
What about obfuscate4e?
http://ondemand.yoxos.com/geteclipse/start?features=de.partmaster.obfuscate4e

Unknown said...

What is your take on this way to protect Eclipse RCP applications?

Anonymous said...

@dleskov, re Excelsior JET, I normally advise my customer to be very careful before they start to either obfuscate or compile the Java code.

The reason is simply, that as long as you don't do this you can actually receive log file from the customers - either automatically or manually - and do something about them. If the code is modified - via obfuscation or compilation - it is extremely difficult to find any errors from a log entry...

And we all want to improve our products, right?

Unknown said...

I can see your point applied to obfuscation, but natively compiled code produced the exact same stack traces, at least with Excelsior JET.

Anonymous said...

@dleskov, in that case, this is not problem...

I guess I'll have check out this product before I come with any further comments :-)

Unknown said...

Just make sure to set stack trace support to Full as it is disabled by default in the current version to reduce the overheads. But that also breaks APIs such as log4j, so the default setting in the next release will be Minimal.

The respective control is on page Target of the JET Control Panel.

Unknown said...

It's official:

Excelsior JET 6.5 Protects Eclipse RCP Applications From Reverse Engineering and Tampering