Protector4J 工作原理
Protector4J 通过将 jar 文件转换为私有加密的 jarx 文件来保护您的 Java 源代码，我们从 JVM 和二进制层面采取多种方法来确保应用程序的安全性，提供高强度的应用程序保护。
代码混淆的问题
由于JVM字节码的高度语义性，极其容易分析和阅读。通过动态调试可以轻松分析其运行逻辑。编写动态调试工具并非非常复杂的任务。因此，混淆不是一个可靠的保护方案。
Class文件加密的问题
由于JVM附加机制的存在，所有未脱离正常JVM运行的所谓加密代码都可以通过附加工具轻松读取。因此，这是最无效的保护方案。
虚拟机保护的问题
虚拟化保护是最安全的代码保护方法，但由于其对性能的显著影响，无法应用于程序中的所有代码。只能保护关键代码，而其他代码仍面临暴露风险。通过针对其他部分的代码，可以获取虚拟化部分代码的功能信息。
AOT编译的问题
AOT编译配置和编译困难，失败概率很高。即使编译成功，代码逻辑也只是从字节码表示变为机器码表示。其固有的运行逻辑仍然存在，没有任何特殊保护。如果能够理解其自身的编译和执行机制，仍然可以反向还原出可读代码。
使用 vlx-vmengine 反混淆
使用JVM字节码执行引擎 vlx-vmengine 反混淆Java代码
用Java/Kotlin编写的JVM字节码执行引擎
传统的Java动态调试只能基于源代码进行，没有源代码或经过混淆的Java class文件，动态调试就不可能实现。Java程序的运行基于JVM，JVM以字节码作为执行基础。我们使用Kotlin构建了一个JVM字节码执行引擎，可以配合现代IDE（如IDEA）在字节码层面调试Java程序以观察程序的运行行为。
GraalVM NativeImage 逆向工程
对于已经进入二进制编译时代的Java程序，其代码是否还能像字节码时代一样轻松反编译？NativeImage编译的二进制文件有什么特点？二进制编译的强度是否足以保护重要代码？为了探究以上问题，我最近编写了一个NativeImage分析工具，已经实现了一定程度的逆向推导。
使用jhsdb（HotSpot调试器）破解加密的Java应用程序
Java代码保护的一种解决方案是加密class文件。此类方案通过自定义类加载器加载加密的class或jar文件，由于JVM附加机制的存在，这种方法无效，可以使用JDK自带的工具轻松破解。
从AOT编译的二进制文件中提取Java类信息
AOT也被认为是Java代码保护的一种方案，但不幸的是，许多Java程序现在无法脱离框架。由于框架的复杂性，即使是AOT编译的程序也必须在最终生成的二进制文件中包含类信息，而class文件实际上整齐地排列在二进制文件的资源区域中。
什么是JARX文件
JARX文件是我们专有的归档文件格式，使用与Zip相同的Deflate压缩算法和AES加密算法来加密数据。
超越混淆的最佳Java代码保护方案
加密代码可以保护您的知识产权，并大大增强应用程序的安全性。它使知识产权盗窃、代码篡改和安全漏洞的发现变得如此复杂和昂贵，以至于配备免费Java反编译器的普通窥探者无法做到。
Excelsior JET 替代方案
Protector4J 不仅仅是 Excelsior JET 的替代品