如何保护编译的Java类？

首先，如果您“仅”针对Windows市场，则很容易防止“.class.java”反编译：使用像Excelsior Jet这样的工具，它将在.exe中转换.jar。

这是万无一失的：如果您使用Excelsior Jet，则不可能取回.java文件（对于所有说“不可能防止.class文件反编译”的人来说，这是很长时间）。当然，攻击者可以启动SoftIce并尝试跟踪您的.exe但这比使用JAD将.class反编译为.java并且肯定不允许找到.java文件要棘手一些。

现在，也许你也瞄准了OS X和Linux，或者你没有$ $ $来为Excelsior Jet做准备。

我正在编写一个用Java编写的商业软件。该软件只有在有互联网连接时才有意义。因此，我们通过在服务器端进行部分计算来“保护”我们的软件：我们有几个.class除非它们从服务器端生成并且我们沿着线路发送它们，否则它们将无法正常工作（并且在线上发送的内容总是不同的：我们在服务器端生成唯一的，一次性.class文件）。

这需要互联网连接，但如果用户不喜欢我们的软件的工作方式，那么他可以自由地购买竞争对手的劣质产品;)

反编译不会有太大的好处：你积极地需要破解软件（即重现服务器端发生的事情），否则你将无法使用它。

在使用Proguard之前，我们使用自己的“字符串混淆”。我们还进行源代码检测（我们也可以进行字节码输入），从代码中删除很多东西（例如我们注释掉的“断言”），并引入一些随机的“代码流混淆”[软件可以采取不同的路径但获得相同的结果，这确实使软件难以跟踪]）。

然后，我们使用Proguard（是免费的）来扁平化我们所有的OO层次结构，并对已经代码流和字符串混淆的代码进行模糊处理。

所以我们的流程是：

• 字符串模糊处理
• 随机代码流模糊处理
• 护卫
• 最终.jar，这取决于在服务器端（以不同的方式）动态生成的.class。

除此之外，我们还发布了非常定期（和自动）的更新，这些更新始终确保修改我们的客户端/服务器保护方案（因此，每次发布时，假设攻击者必须主要从头开始）。

当然，扔掉毛巾并思考：“我无能为力，无法使攻击者的生活更加艰难，因为JAD无论如何都可以找到.java文件”（如果您使用.class来.exe转换器来保护.class免受反编译，这是非常值得商榷的，而且明显是错误的）。

混淆器（参见 http://java-source.net/open-source/obfuscators）将“扰乱”代码，使其在反编译时没有任何意义。