Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338518

Summary:	Code obfuscation and class stripping
Product:	[Eclipse Project] JDT	Reporter:	Marvin Fröhlich <eclipse>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	pwebster, stephan.herrmann
Version:	3.6.2
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Marvin Fröhlich

2011-03-01 05:39:28 EST

Build Identifier: 20100917-0705

When I compile a class with Eclipse, it includes the complete source into the class file with all whitespaces and comments. When the class is decompiled you'll get the complete source code with all comments, whitespaces, variable names and everything else. This is too simple for thiefs. And it is not smart as for the resulting class/jar size.

I would like to see an option to strip the source on the fly before encoded to the class file (remove all whitespaces except for new-lines and remove all comments). Only linefeeds (no carriage returns) need to be preserved to keep stack traces intact.

Additionally it would be great to have two more options: 1) to obfuscate the code slightly by renaming all local variable names to single letter names and 2) to do the same to private fields. This also saves a little disc space and makes it a little harder to understand decompiled code.

I guess, this is all, you can do to obfuscate the code while keeping stack traces intact. And this only uses out-of-the-box eclipse featuers like refactoring of local variable names and removing white spaces (code formatter).

If there are smarter and more advanced ways to obfuscate the code on the fly, they should also be included in Eclipse and be selectable. But the above few options really should be in there.

Reproducible: Always

Comment 1 Stephan Herrmann

2011-03-01 06:19:50 EST

(In reply to comment #0)
> Build Identifier: 20100917-0705
> 
> When I compile a class with Eclipse, it includes the complete source into the
> class file with all whitespaces and comments.

No, it doesn't. :)
Whitespace and comments are never stored in .class files.
If you see the original whitespace and comments you are not looking at a 
.class file. If you did click on a .class file the IDE obviously knew where
to find the source file and presented that instead (via "source attachment"
in the build path configuration).

> Additionally it would be great to have two more options: 1) to obfuscate the
> code slightly by renaming all local variable names to single letter names and
> 2) to do the same to private fields. This also saves a little disc space and
> makes it a little harder to understand decompiled code.

Obfuscation must be done as a post-processing step, the incremental compiler
needs un-obfuscated .class files to work efficiently.

Therefor, I recommend to use an existing standalone tool for that.
I don't see any benefits (but obvious difficulties) if this would be 
integrated in the JDT/Core.

Am I missing anything?

Comment 2 Marvin Fröhlich

2011-03-29 08:38:40 EDT

I am sure, that I once decompiled one of my classes and was shocked, that it contained everything. Now this seems to have changed indeed.

I used cavaj to decompile a class and the non-empty lines were indented. I guess, cavaj did that. So whitespaces are indeed eliminated as well as comments.

So far so good.

Wouldn't it be a great feature, if the jar exporter would provide a combo box with three options? These were NO_OBFUSCATION, LIGHT_OBFUSCATION, FULL_OBFUSCATION and they you work as described above.

This way the incremental compiler could work efficiently and when rolling out your source as a jar you could use obfuscation to make the lives of thieves harder.

I think, this would be a great eclipse feature and - depending on the quality of the obfuscation - would put Java more into place as a language of choice for commercial software.

Maybe it would also be nice, if eclipse would provide an interface to plug in an arbitrary obfuscator, so that this functionality doesn't need to be done by the eclipse team.