如何锁定已编译的Java类以防止反编译？
如何锁定已编译的Java类以防止反编译？
我知道这一点在互联网上必须讨论得非常好，但是在提到它们之后我不能得出任何结论。
许多人确实提出了混淆器，但他们只是用难以记忆的字符序列重命名类，方法和字段，但敏感常量值又如何呢？
例如，您已经基于基于密码的加密技术开发了加密和解密组件。 现在，在这种情况下，任何普通的Java人都可以使用JAD来反编译类文件，并轻松地检索密码值（定义为常量）以及salt，然后通过编写小型独立程序来解密数据！
或者应该使用本地代码（例如VC ++）构建这些敏感组件并通过JNI调用它们？
一些更高级的Java字节码混淆器不仅仅是类名称混合。 例如，Zelix KlassMaster也可以以一种非常难以遵循的方式扰乱您的代码流，并且作为优秀的代码优化器工作。
还有许多混淆器也能够扰乱你的字符串常量并删除未使用的代码。
另一个可能的解决方案（不一定排除混淆）是使用加密的JAR文件和执行解密的定制类加载器（最好使用本机运行时库）。
第三个（也可能提供最强的保护）是使用本地提前编译器，例如GCC或Excelsior JET，它将Java代码直接编译为特定于平台的本地二进制文件。
无论如何，你必须记住，正如爱沙尼亚语所说的“锁定是为了动物”。 意思是说，在运行期间，每一段代码都可用（加载到内存中），并给予足够的技巧，决心和动力，人们可以并将反编译，解密和破解你的代码......你的工作仅仅是让程序不舒服，你可以并且仍然保持着这个东西的工作...
只要他们能够访问加密的数据和解密它的软件，基本上没有办法让这个安全。 之前解决的方法是使用某种形式的外部黑盒来处理加密/解密，如加密狗，远程认证服务器等。但即使如此，由于用户可以完全访问自己的系统，这只会使事情困难，并非不可能 - 除非您可以将您的产品直接绑定到存储在“黑匣子”中的功能，例如在线游戏服务器。
免责声明：我不是安全专家。
这听起来像个不好的主意：你让某人用你给他的一个'隐藏'键加密东西。 我不认为这可以做到安全。
也许不对称的钥匙可以工作：
我不确定，但我相信客户实际上可以使用您提供的公钥对许可证密钥进行加密。 然后您可以使用您的私钥解密并重新加密。
您可以为每个客户保留一个单独的公钥/私钥对，以确保您实际上从正确的客户那里获得东西 - 现在您负责密钥......
链接地址: http://www.djcxy.com/p/81881.html上一篇: How to lock compiled Java classes to prevent decompilation?