Make your jar not decompiled

How can I pack a Java application in an executable jar that cannot be decompiled (e.g. Jadclipse)?

+3
source share
5 answers

You can not. If the JRE can run it, the application can decompile it.

The best you can hope for is to make it very difficult to read (replace all characters with the combinations ā€œlā€ and ā€œ1ā€ and ā€œOā€ and ā€œ0ā€, add a lot of useless code, and so on), you would be surprised how unreadable you can make the code, even with a relatively dumb translation tool. This is called obfuscation and, although not perfect, sometimes adequate.

Remember, you cannot stop a particular hacker more than a specific burglar. What you are trying to do is make things very difficult for a random attacker. When the characters are O001l1ll10O , O001llll10O , OO01l1ll10O , O0Ol11ll10O and O001l1ll1OO , and a code that seems to be of no use to most people will give up.

+9
source

Firstly, you cannot avoid reverse code conversion. The JVM bytecode should be easy to execute, and there are several programs for reverse engineering it (the same applies to the .NET CLR). You can only make it harder to raise the barrier (i.e. Cost) to see and understand your code.

The obfuscate source is usually used with some tool. Classes, methods and fields are renamed throughout the code base, even with invalid identifiers, if you decide what the code does that is impossible to understand. I have had good results with JODE in the past. After obfuscation, use the decompiler to see what your code looks like ...

Next to obfuscation, you can encrypt your class files (everything except a small start class) using any method, and use an expander for the user class. Unfortunately, the class loader class cannot be encrypted by itself, so people can determine the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code has become smaller. Again, this does not stop people from seeing your code, but simply makes it harder for a random attacker.

You can also try converting the Java application to some EXE windows that will hide the key that it is Java at all (to some extent) or is really compiled into machine code, depending on your need for JVM functions. (I have not tried this.)

+3
source

GCJ is a free tool that can compile either bytecode or native code. Remembering that this is a kind of defeat of the purpose of Java.

+2
source

I know a little late, but the answer is no.

Even if you write in C and compile your own code, there are dissasemblers / debuggers that let people go through your code. Provided - debugging optimized code without symbolic information is a pain, but it can be done, I had to do it sometimes.

There are steps you can take to make this harder - for example, on windows you can call the IsDebuggerPresent API in a loop to find out if someone is debugging your process, and if so, and this is a release build, complete the process. Of course, a strong enough attacker can intercept your IsDebuggerPresent call and always return false.

There are a number of methods that have appeared - people who want to protect something, and people who want to crack it widely, this is a real arms race! As soon as you go along this path, you will have to constantly update / update your defenses, there is no stop.

+1
source

This is not my practical solution, but here I think that a good collection or resource and tutorials in order to do this with the highest level of satisfaction.

Offer from this site (oracle community)

(clean way) Obfuscate your code, There are many open source and free obfuscator tools, here is a simple list of them: [Open source obfuscators lis t]. These tools make your code unreadable (although you can still decompile it) by changing the names. This is the most common way to protect your code.

2. (Not so clean). If you have a specific target platform (for example, windows) or you can have different versions for different platforms, you can write a complex part of your algorithms at a low level, a language like C (which is very difficult to decompile and understand) and use it as a native library in java application. it's not clean because many of us use java for cross-platform capabilities and this method weakens this ability.

and below - step by step: ProtectYourJavaCode

Enjoy it! Keep your decisions added, we need it more.

0
source

Source: https://habr.com/ru/post/1384255/


All Articles