Java 由本机库处理解密的加密类文件

“破解Java字节码加密”（Cracking Java byte code encryption）一文解释了为什么使用自定义类加载器进行类文件加密是毫无意义的，因为在某些时候，您总是需要调用defineClass（），它将类文件作为未加密的字节数组传递给JVM

然而，我看到的解决方案使用了稍微不同的方法；该类由本机库解密，并通过findClass（）方法作为java.lang.class实例移交给JVM——决不调用defineClass（）

这是否意味着这些解决方案没有这个弱点？当然，通过在汇编程序级别上使用调试器，您始终可以提取类文件，而坚定的黑客可以破坏任何保护。但至少这使得反编译比仅仅修补defineClass（）将未加密的.class文件转储到磁盘要困难一些。还是我忽略了什么

但至少这使得反编译比仅仅修补defineClass（）将未加密的.class文件转储到磁盘要困难一些

只有一点点。这还不足以产生很大的影响

还是我忽略了什么

---

在某些时候，本机库必须解密字节码。在那一点上，修补本机库进行snarf并不难。反汇编和修补二进制库不是“火箭科学”。

如果您需要本机库，您将放弃平台独立性。此时，您可能希望直接调查并编译为可执行文件

当然，这不是火箭科学。但是我想你会承认，能够破解本机代码的人比能够反编译Java类的人要少：-）不一定。有数以百万计的开发人员在他们的教育中学习了一些汇编语言编程。机器代码和字节码没有那么大的区别，当所有的说和做。无论哪种方式，能够反向工程本地代码（给定时间和激励）的“人的宇宙”仍然非常大。好吧，不必讨论哪个宇宙更大。您是否同意为了打破这种保护，需要在汇编程序级别上工作？还是我忽略了一些显而易见的事情（显而易见==相当于拦截对defineClass（）的调用）@Grodriguez-我同意这一点，虽然我不认为逆向工程是一个很大的障碍。放弃平台独立性——是的和不。我的应用程序仍然会在相同的代码库中运行在所有支持的平台上，我不介意包括一个小型本地库来实现这个特定的目的。话虽如此，我当然愿意使用gcj，但目前运行时还远未完成，特别是在AWT和Swing支持方面。事实上，如果我只能将我的应用程序编译为本机，但仍然让它使用标准的JRE，那就太完美了。