How to protect compiled Java classes?

问题:

I know, many similar questions has been asked here. I am not asking if I can protect my compiled Java class - because obviously you will say 'no you can't'. I am asking what is the best known method of protecting Java classes against de-compiling? If you aware of any research or academic paper in this field please do let me know. Also if you have used some methods or software please share you experience? Any kind of information will be very useful. Thank you.

回答1:

First if you're targeting "only" the Windows market there's a very easy to prevent the ".class to .java" decompilation: use a tool like Excelsior Jet that will transform the .jar in an .exe.

This is foolproof: it is impossible to get the .java file back if you use Excelsior Jet (so long for all the people saying "it's impossible to prevent decompilation of a .class file"). Sure, an attacker could launch SoftIce and try to trace your .exe but that will prove a bit trickier than using JAD to decompile the .class to a .java and it certainly won't allow to find the .java file back.

Now maybe you're targetting OS X and Linux too or you don't have $$$ to shell off for Excelsior Jet.

I'm writing a commercial software written in Java. That software only makes sense if there's an Internet connection. Hence we "protect" our software, amongst other, by having part of the computation happening on the server side: we have several .class that won't work unless they're generated from the server side and we send them down the wire (and what is sent on the wire is always different: we're generating unique, one-off .class files on the server side).

This requires an Internet connection but if the user doesn't like how our software works then he's free to buy one our competitor's inferior product ;)

Decompiling will not do much good: you actively need to crack the software (ie reproduce what is happening on the server side) or you won't be able to use it.

We use our own "string obfuscation" before we use Proguard. We also do source code instrumentation (we could have done bytecode instrumenation as well) where we remove lots of things from the code (like the "assert" that we comment out) and introduce some random "code flow obfuscation" [the software can take different paths yet obtain the same result, this is something that really makes the software hard to trace]).

Then we use Proguard (which is free) to flatten all our OO hierarchy and to obfuscate the already-code-flow-and-string-obfuscated code.

So our flow is:

• string obfuscation
• random code flow obfuscation
• Proguard
• final .jar that depends on .class that are (differently) dynamically generated on the server side.

In addition to that we release very regular (and automated) update which always make sure to modify a bit our client/server protection scheme (so that with each release an hypotethical attacker has to start mostly from scratch).

Of course it's easier to throw the towel in and to think: "there's nothing I can do to make an attacker's life harder because JAD can find back the .java file anyway" (which is more than very debatable and blatantly wrong in the case where you use a .class to .exe converter to protect your .class from decompiling).

回答2:

An obfuscator (see http://java-source.net/open-source/obfuscators) will "scramble" the code such that it will not make any sense when de-compiled.

回答3:

There are several methods:

• Obfuscation
• Software encryption (flawed)
• Hardware encryption (nearly unbreakable but the performance hit is huge)
• Native compilation

all discussed in details in my article Protect Your Java Code - Through Obfuscators And Beyond

回答4:

So how can you protect your classes from being decompiled? One answer is Crema. Crema scrambles the symbolic information in your .class files so that they will become less vulnerable to decompilation. The symbolic information that Crema scrambles includes the name of the class, its superclass, interfaces, variable names, methods, and so on. These symbolic names are needed by the Java virtual machine (JVM) to link your classes with library packages. Crema scrambles these symbolic names and makes references to them in the same way so that the JVM can still achieve the correct linking between classes and packages.

So how does Crema work? Basically, before distributing your class files on the Internet, run Crema on them. Crema will scramble the symbolic information contained in them, and will place each new class in the file 1.crema. Your job then is to rename 1.crema to something like filename.class before distributing it on the Internet.

HOW TO PROJECT JAVA COMPLIED CLASSSES

回答5:

You can try the Java Protector. It is a better way than obfuscation.It makes a Native ClassLoader by modifying the source of OpenJDK, could encrypt the classes that you want to protect by AES and parse them in their custom-JRE.You can publish your software with the JRE and distribute your software safety.