How to protect jar from "simple/easy" decompilation

Question

I know this is a very common question, and a good topic is actually here:
How to lock compiled Java classes to prevent decompilation?

But I'm asking something different, not an absolute protection, but at least some basic protection against decompilers.

I have tried some decompilers like JD and Jode with some .jar files, and they couldn't decompile all the .java classes, in many of them I get an error, and many other just a very basic code.
How are they protecting the jar files from those decompilers? when I use the same decompilers with my jar all the classes are decompiled with full detail.

So basically my question is, what could be causing this error on those decompilers? is because the java classes are encrypted?

EDIT:
I have noted Jode is showing this error in some java files:

Exception while decompiling:java.lang.NoClassDefFoundError: [package.ClassName]
    at jode.bytecode.ClassInfo.loadInfo(ClassInfo.java:631)
    at jode.decompiler.ClassAnalyzer.<init>(ClassAnalyzer.java:86)
    at jode.decompiler.ClassAnalyzer.<init>(ClassAnalyzer.java:123)
    at jode.decompiler.Decompiler.decompile(Decompiler.java:191)
    at jode.swingui.Main.run(Main.java:204)
    at java.lang.Thread.run(Unknown Source)

Also tried with FernFlower decompiler, with this error:

java.lang.ClassCastException: g cannot be cast to T
        at bK.a(Unknown Source)
        at T.a(Unknown Source)
        at bK.<init>(Unknown Source)
        at bW.a(Unknown Source)
        at bW.<init>(Unknown Source)
        at bW.<init>(Unknown Source)
        at i.a(Unknown Source)
        at i.a(Unknown Source)
        at i.a(Unknown Source)
        at de.fernflower.main.decompiler.ConsoleDecompiler.addSpace(Unknown Source)
        at de.fernflower.main.decompiler.ConsoleDecompiler.main(Unknown Source)

What was the protection there? I think that could be good enough for my jar files

Using Java 8 confuses decompilers which don't support it. Fernflower (built in to InteliJ) seems to handle Java 8 just fine. — Peter Lawrey, May 21 '17 at 17:46

score 2 · Answer 1 · answered May 21 '17 at 18:00

One very simple approach is to add lambdas to your class. Many decompilers can't handle lambdas. Another thing you can do is give your class a Unicode name, especially one using astral characters. Unicode class names are tricky to implement correctly, so most decompilers don't. Try-with-resources is another good thing to try, since it is complex and doesn't have any equivalent in vanilla Java code.

This won't break a good decompiler, but that's not what you're asking for.

Lambdas as in the Java 8 Lambdas. Would appreciate if you could give an example of this please. — prakash krishnan, May 27 '18 at 12:14

score 0 · Answer 2 · answered May 21 '17 at 17:44

0

Have a look at this http://www.thegeekstuff.com/2008/06/protect-your-java-code-from-reverse-engineering.If you ship a program in the form of JAR you effectively loose control. This program can be modified/copied. The only thing you can do is to make such things harder by obfuscating code or similar techniques.

answered May 21 '17 at 17:44

Nitin Prabhu

462
3
9

please read the Edit on my question, the are programs shipped as jar files, and decompilers are not working on them, how they achieved that? – Enrique May 21 '17 at 17:47
can you please list all the classes in the jar file and see if it contains the class name for which the error is thrown? – Nitin Prabhu May 21 '17 at 17:54

How to protect jar from "simple/easy" decompilation

2 Answers2