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?
views:
247answers:
4
+1
Q:
Does compilng java code to exe (e.g. using Launch4Java) ensure code cannot be reversed engineered?
+10
A:
If a computer can run it, a human can reverse engineer it.
Thorbjørn Ravn Andersen
2010-02-11 12:24:22
care to explain how can that be done in my case?
SS
2010-02-11 12:27:49
The compiled .exe file needs to contain the information that is needed to run your program logic. If the computer is able to run it, then a human can read it. It might be a bit harder (because byte code is simpler than native assembly), but it's still possible.
Joachim Sauer
2010-02-11 12:36:35
plus I just tested on ubuntu, and file-roller was able to open the exe and give me the untouched jar
Valentin Rocher
2010-02-11 12:49:29
Indeed, there have been tools (e.g. disassemblers) around to help reverse engineering native code since ... at least the 1970's, to my certain knowledge.
Stephen C
2010-02-11 12:54:12
@Valentin -- too easy :-)
Stephen C
2010-02-11 12:54:45
java is an extremely versatile and easy language. don't think can easily get as productive using another language. for my app, i don't need the "write once, run everywhere" feature.
SS
2010-02-11 12:27:21
It won't. If people can reverse engineer bits of Windows etc to figure out how to break in, they can surely reverse engineer an exe file.
Stephen C
2010-02-11 12:51:08
+2
A:
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.
Esko
2010-02-11 12:36:04
+4
A:
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.
Nate
2010-02-11 12:53:20