27

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.

JasonMArcher
  • 12,386
  • 20
  • 54
  • 51
Registered User
  • 2,880
  • 5
  • 24
  • 32
  • 3
    Similar question to yours - http://stackoverflow.com/questions/49379/how-to-lock-compiled-java-classes-to-prevent-decompilation – James Goodwin Mar 14 '10 at 20:05
  • 1
    Are you interested in preventing decompilation, or protecting your trade secrets embedded in the code? – Yuval Mar 14 '10 at 20:25
  • 5
    @ Yuval - I am interested in both... – Registered User Mar 14 '10 at 20:45
  • 1
    in addition to my answer, another option instead of using a .java to .exe converter is to provide your application in a "Software as a Service" (SaaS) fashion, where you convert your .java to GWT and make part of the computation happen on the web-server-side... "How do I find the .java back for the GMail code?": you don't, because it has been translated to GWT/JavaScript and a lot of stuff is happening on the (web)server-side... – SyntaxT3rr0r Mar 14 '10 at 22:06

6 Answers6

19

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).

SyntaxT3rr0r
  • 26,196
  • 20
  • 81
  • 119
  • 1
    I doubt it is fool proof, although myself are using Launch4J to wrap a jar within an exe. I believe with correct understanding on exe file structure and assistance from Launch4J, reverse engineering is possible to be done. Of course, it will be much difficult than using Java decompiler. – Cheok Yan Cheng Mar 15 '10 at 03:45
  • 1
    I have a small correction: Excelsior JET is available for both Windows and Linux. – Dmitry Leskov Mar 15 '10 at 05:37
  • 4
    @Yan Cheng CHEOK: Excelsior JET is not a wrapper around a .jar: it's transforming your Java bytecode in a native Windows (or Linux) executable. So it's not "foolproof" in that, sure, people can still try to decompile it. But there's *no way* they'll get back the .java file allowing to compile the .class (because there are no .class files anymore, no bytecode anymore, it's all native .exe [or Linux executable]). This is not at all like a wrapper like izpack or Launch4J etc. – SyntaxT3rr0r Mar 15 '10 at 14:22
  • 1
    @Dmitry Leskov: Excellent, make an OS X version and you can count my company as a customer :) – SyntaxT3rr0r Mar 15 '10 at 14:22
6

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.

Itay Maman
  • 28,289
  • 9
  • 76
  • 114
6

There are several methods:

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

Dmitry Leskov
  • 3,205
  • 17
  • 17
0

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

Ravindra Shekhawat
  • 3,977
  • 1
  • 15
  • 26
0

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.

Yongfa Lin
  • 1
  • 1
0

If you are using Linux and x86-64 CPUs, you can try PackerLX.

It is a free and web based packer solution. Packs jar file in an ELF executable file and protects it. ELF file has some protection techniques like encryption and decompile protection. PackerLX is a new solution and it protects all kind of linux executables from non-professional reverse engineering.

Engin Kuzu
  • 1