Does compilng java code to exe (e.g. using Launch4

Question

After experimenting myself, I am convinced that java code obsfucation is not safe in terms of preventing reverse code engineering. So, I turn to using Launch4J to bundle one of my core jar file into a single EXE file. The jar file contains the main entry method as well. Is this going to protect again code reverse engineering?

Answer 1

If a computer can run it, a human can reverse engineer it.

Answer 2

If you rename the executable file from .exe to .zip you'll be able to view all .class files and stuff like renaming from .jar to .zip, and with an decompiler like http://java.decompiler.free.fr people will still be able to view your source-code.

Answer 3

It should. However that would be missing the whole point of Java.

Answer 4

I have performed reverse engineering on exe(generated from launch4j) over a jar.
Following are the steps which followed to check the source if you have missed the jar file and only have exe.

1. suppose your exe name is xyz.exe rename it to xyz.exe.zip
2. Go to RAD/eclipse create a jave project for ex: temp.
3. Go to file select Import, Import window will get open.
4. Go to General and select Archive File an click on Next.
5. In Archive file window click browse and select your zip(for ex: xyz.exe.zip)
6. In Into folder select destination path here I have selected created jave project temp an click on Finish.
7. you can see your all .class file in the above project.
8. In jd-gui you open the .class file which source you need to check, you can see the src.

Answer 5

Simply put, you can't prevent your code from being reverse engineered.

• You've already noticed yourself what obfuscation benefits (nothing much, really)
• Class slicing/combining (purposefully mix'n'match various classes to break the logical structure of the code) isn't going to be that helpful either, especially when you have to debug the monstrosity.
• You also can't really encrypt/obfuscate the bytecode either because after the bytecode has hit your custom ClassLoader, it's already back in completely readable format. More information here.

Even if you'd get the code protected, it can be monitored. Maybe on bytecode level, maybe on ASM level, that doesn't matter - what matters is that when one can monitor the code being executed, it can also be reverse engineered. Some methods do take more time than others but there isn't a case where it would be impossible.

Stop thinking in the terms of security through obscurity and instead start analyzing the real security etc. issues you have and fix them accordingly. Preventing reverse engineering - even if it wouldn't be an exercise in futility - isn't going to magically fix the problems of your software.

Answer 6

Launch4J doesn't translate your Java code into native executable code, it just provides a native launcher that looks for a JDK and has your JAR as a resource (either packaged inside the executable or not). This is just a convenience - not security. If your JAR is external to the executable, someone can reverse engineer your code like a regular Java application. If your JAR is packaged into the executable - Presumably, someone programmed the logic to wrap the JAR in the executable, and someone can program the logic to unwrap the JAR from the executable (or use one of many tools that can extract resources from executables) - and can then reverse engineer your code like a regular Java application.