The problems with code obfuscation exist.
Due to the high semantic nature of JVM bytecode, makes it easy to be analyzed and read, using dynamic debugging can easily analyze the running logic, and writing dynamic debugging tools is not a very complicated thing, so obfuscation is not a reliable protection solution.
Problems with encrypting Java class files
Due to the presence of JVM attachment mechanism, all so-called encrypted code that has not escaped ordinary JVM execution can be easily read using attachment tools. Therefore, this is the most ineffective protection scheme.
Issues with Virtualization Protection
Virtualization protection is the most powerful code protection method, but due to its severe impact on performance, it cannot be applied to all code in the program. It can only protect critical code, while other code still has the risk of exposure. By using other parts of the code as an entry point, functional information of the virtualized code can be obtained.
Issues with Ahead of Time Compilation
Compiling AOT configurations is difficult, with a high probability of compilation failure. Even if the compilation is successful, the code logic is converted from bytecode representation to machine code representation, but its operational logic still remains, without any special protection. If one is able to understand its compiling and running mechanism, it is still possible to reverse-engineer readable code.
Using vlx-vmengine for deobfuscation
Using the JVM bytecode execution engine, vlx-vmengine deobfuscates Java code
JVM bytecode execution engine written in Java/Kotlin
Traditional Java dynamic debugging can only be done at the source code level. Without source code or obfuscated Java class files, dynamic debugging cannot be performed. Java programs run on the JVM virtual machine, which uses bytecode as the basis for execution. We have constructed a JVM bytecode execution engine using Kotlin, which allows for debugging Java programs at the bytecode level with modern IDEs such as IntelliJ IDEA, to observe the program's runtime behavior.
GraalVM NativeImage Reverse Engineering
For Java programs that have entered the era of binary compilation, is it still easy to reverse engineer their code, like in the bytecode era? What are the characteristics of binary files compiled with NativeImage, and is the strength of binary compilation enough to protect important code? To explore the above questions, the author has recently developed a NativeImage analysis tool, which has achieved a certain degree of reverse engineering effects.
Using jhsdb (HotSpot Debugger) to crack encrypted Java applications
One solution for protecting Java code is class file encryption. This solution involves loading encrypted class files or jar files using a custom loader. However, this method is ineffective due to the presence of the JVM's Attach mechanism, and can be easily cracked using tools provided by the JDK.
Extract Java class information from binary files compiled from AOT
AOT is also considered to be a solution for Java code protection, but unfortunately, many Java programs cannot be separated from the framework. Due to the complexity of the framework, even programs compiled by AOT must include class information in the final generated binary file, and the class files are actually neatly arranged in the resource area of the binary file.
What is a JARX file
The JARX file is our proprietary archive file format, which uses the same Deflate compression algorithm as Zip, and uses the AES encryption algorithm to encrypt data.
The best Java code protection solution beyond obfuscation
Encrypting your code can protect your intellectual property and greatly enhance the security of your application. It makes IP theft, code tampering, and the discovery of security vulnerabilities involve expensive reverse engineering efforts, while in reality, anyone can download and run a free Java decompiler.
Alternative to Excelsior JET
Protector4J is far more than just a replacement for Excelsior JET