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