如何保护已编译的 Java 类？答案

【问题标题】：How to protect compiled Java classes?如何保护已编译的 Java 类？
【发布时间】：2011-01-27 11:07:52
【问题描述】：

我知道，这里有很多类似的问题。我不是在问我是否可以保护我编译的 Java 类——因为显然你会说“不，你不能”。我在问保护 Java 类免受反编译的最著名方法是什么？如果您知道该领域的任何研究或学术论文，请告诉我。另外，如果您使用过一些方法或软件，请分享您的经验？任何类型的信息都会非常有用。谢谢。

【问题讨论】：

与您的类似问题 - stackoverflow.com/questions/49379/…
您是否对防止反编译或保护嵌入在代码中的商业机密感兴趣？
@ Yuval - 我对两者都感兴趣...
除了我的回答之外，另一种选择不是使用 .java 到 .exe 转换器，而是以“软件即服务”(SaaS) 方式提供您的应用程序，您可以在其中转换您的 .java到 GWT 并使部分计算发生在网络服务器端......“我如何找到 .java 的 GMail 代码？”：你没有，因为它已被翻译成 GWT/JavaScript 和（网络）服务器端发生了很多事情......

标签： java decompiling source-code-protection

【解决方案1】：

首先，如果您的目标是“仅”Windows 市场，那么很容易防止“.class to .java”反编译：使用 Excelsior Jet 之类的工具来转换 .jar在 .exe.

中

这是万无一失的：如果您使用 Excelsior Jet，则 不可能 恢复 .java 文件（只要所有人都说“不可能防止 .class 的反编译 文件”）。当然，攻击者可以启动 SoftIce 并尝试追踪您的 .exe，但这会比使用 JAD 反编译 .class 更棘手到 .java 并且它肯定不允许找到 .java 文件。

现在，也许您的目标也是 OS X 和 Linux，或者您没有 $$$ 可用于 Excelsior Jet。

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

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

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

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

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

所以我们的流程是：

字符串混淆
随机代码流混淆
Proguard
最终的 .jar 依赖于在服务器端（不同地）动态生成的 .class。

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

当然更容易放弃并思考：“我无能为力让攻击者的生活更加艰难，因为 JAD 无论如何都能找回 .java 文件”（这更在您使用 .class 到 .exe 转换器来保护您的 .class 免受反编译的情况下，这比非常有争议和明显错误）。

【讨论】：

我怀疑它是万无一失的，尽管我自己正在使用 Launch4J 将一个 jar 包装在一个 exe 中。我相信通过对exe文件结构的正确理解和Launch4J的帮助，逆向工程是可以完成的。当然，这比使用Java反编译器要困难得多。
我有一个小的更正：Excelsior JET 可用于 Windows 和 Linux。
@Yan Cheng CHEOK：Excelsior JET 不是 .jar 的包装器：它在本地 Windows（或 Linux）可执行文件中转换 Java 字节码。所以它不是“万无一失的”，当然，人们仍然可以尝试反编译它。但是没有办法他们会取回允许编译 .class 的 .java 文件（因为不再有 .class 文件，不再有字节码，它都是原生的 .exe [或 Linux 可执行文件] ）。这根本不像 izpack 或 Launch4J 等包装器。
@Dmitry Leskov：太好了，制作一个 OS X 版本，您可以将我的公司视为客户 :)

【解决方案2】：

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

【讨论】：

【解决方案3】：

有几种方法：

混淆
软件加密 (flawed)
硬件加密 (nearly unbreakable but the performance hit is huge)
原生编译

都在我的文章里详细讨论过Protect Your Java Code - Through Obfuscators And Beyond

【讨论】：

【解决方案4】：

那么如何保护你的类不被反编译呢？一个答案是克丽玛。 Crema 会扰乱 .class 文件中的符号信息，以便它们不易被反编译。 Crema 打乱的符号信息包括类的名称、它的超类、接口、变量名、方法等。 Java 虚拟机 (JVM) 需要这些符号名称来将您的类与库包链接。 Crema 对这些符号名称进行打乱，并以相同的方式对它们进行引用，以便 JVM 仍然可以实现类和包之间的正确链接。

那么 Crema 是如何工作的呢？基本上，在 Internet 上分发您的类文件之前，在它们上运行 Crema。 Crema 将打乱其中包含的符号信息，并将每个新类放在文件 1.crema 中。然后，您的工作是将 1.crema 重命名为 filename.class 之类的名称，然后再将其发布到 Internet。

HOW TO PROJECT JAVA COMPLIED CLASSSES

【讨论】：

【解决方案5】：

你可以试试Java Protector。这是一种比混淆更好的方法。它通过修改 OpenJDK 的源代码来制作 Native ClassLoader，可以加密你想要通过 AES 保护的类并在他们的自定义 JRE 中解析它们。你可以使用 JRE 发布你的软件并分发您的软件安全。

【讨论】：

【解决方案6】：

如果你使用 Linux 和 x86-64 CPU，你可以试试PackerLX。

这是一个基于网络的免费打包程序解决方案。将 jar 文件打包到 ELF 可执行文件中并对其进行保护。 ELF 文件有一些保护技术，如加密和反编译保护。 PackerLX 是一种新的解决方案，它可以保护各种 linux 可执行文件免受非专业逆向工程的影响。

【讨论】：