如何保护编译后的Java类?

Question

我知道，这里已经有很多类似的问题了。我并不是在问我能否保护我的编译后的Java类 - 因为显而易见你会说“不行”。我想问的是，保护Java类免受反编译的最佳方法是什么？如果您了解这个领域的任何研究或学术论文，请告诉我。同样，如果您使用过某些方法或软件，请分享您的经验。任何信息都将非常有用。谢谢。

- Registered User

---

类似于您的问题 - https://dev59.com/7XVD5IYBdhLWcg3wNY1Z - James Goodwin

你是否有兴趣防止反编译或保护嵌入在代码中的商业机密？ - Yuval

@Yuval - 我对两者都很感兴趣... - Registered User

除了我的答案之外，另一个选项是不使用 .java 到 .exe 转换器，而是以“软件即服务”（SaaS）的方式提供您的应用程序，其中将 .java 转换为 GWT，并使部分计算在 Web 服务器端进行...“如何找到 GMail 代码的 .java 文件？”：您不需要找到它，因为它已被转换为 GWT/JavaScript，并且许多东西都发生在（Web）服务器端... - SyntaxT3rr0r

Answer 1

如果你的目标市场仅限于Windows，那么有一种非常容易防止 ".class转为.java" 反编译的方法：使用像Excelsior Jet这样的工具将 .jar 转换为 .exe。

这是绝对可靠的：如果使用 Excelsior Jet，就 不可能 获取 .java 文件（因此所有声称 "无法防止 .class 文件反编译" 的人都错了）。当然，攻击者可以启动 SoftIce 并尝试跟踪你的 .exe，但这比使用 JAD 反编译 .class 为 .java 难多了，而且肯定无法找回 .java 文件。

现在也许你的目标市场还包括 macOS 和 Linux，或者你没有足够的资金购买 Excelsior Jet。

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

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

反编译没有什么用：你需要积极破解软件（即复制服务器端发生的情况），否则就无法使用它。

在使用Proguard之前，我们会先使用自己的"字符串混淆"技术。另外，我们进行源代码注入(也可以进行字节码注入)，从代码中删除很多内容(如我们注释掉的"assert")，并引入一些随机的"代码流混淆"技术[软件可以采用不同的路径得出相同的结果，这使得软件非常难以追踪]。

然后我们使用免费的Proguard对所有OO层次结构进行优化，并对已经进行了代码流和字符串混淆的代码进行混淆。

因此，我们的流程是:

• 字符串混淆
• 随机代码流混淆
• Proguard
• 最终的.jar文件依赖于在服务器端生成的(differently)动态生成的.class文件。

除此之外，我们还定期(且自动化)地发布更新，始终确保修改一下客户端/服务器端的保护方案(这样每次发布都需要重新开始攻击)。

当然，放弃并认为：“我无法让攻击者的生活更加艰难，因为JAD仍然可以找回.java文件"(这在你使用.class到.exe转换器来保护你的.class文件免受反编译时显然是错误的)是更容易的。

- SyntaxT3rr0r

---

我怀疑它并不是百分之百可靠的，尽管我自己正在使用Launch4J将一个jar包装成exe文件。我相信只要对exe文件结构有正确的理解，并得到Launch4J的帮助，反向工程就有可能完成。当然，这比使用Java反编译器要困难得多。 - Cheok Yan Cheng

我有一个小修正：Excelsior JET 可用于 Windows 和 Linux 两个平台。 - Dmitry Leskov

Excelsior JET不是一个 .jar 文件的封装器：它会将Java字节码转换成本地的Windows（或Linux）可执行文件。因此，它并非完全可靠，人们仍可以尝试反编译它。但是，他们将无法获取回原始的 .java 文件以编译 .class 文件（因为没有 .class 文件和字节码了，全部都是本地的 .exe 或 Linux 可执行文件）。这与 izpack 或 Launch4J 等包装器完全不同。 - SyntaxT3rr0r

@Dmitry Leskov：太棒了，如果你能制作一个OS X版本，我们公司一定会成为你的客户 :) - SyntaxT3rr0r

有没有关于如何动态创建类文件的文章或任何内容，或者是否有API在服务器端运行可靠代码的？ - Mosch

Answer 2

一个混淆器（见http://java-source.net/open-source/obfuscators）可以“混淆”代码，使得反编译后的代码没有任何意义。

- Itay Maman

Answer 3

有几种方法：

• 混淆
• 软件加密（存在缺陷）
• 硬件加密（几乎无法破解，但性能损失巨大）
• 本地编译

这些方法在我的文章中有详细讨论：通过混淆器和更多方式保护Java代码

- Dmitry Leskov

Answer 4

你可以尝试使用Java Protector。它比混淆更好。它通过修改OpenJDK的源代码创建了一个本地ClassLoader，可以使用AES加密要保护的类，并在自定义JRE中解析它们。你可以使用该JRE发布你的软件并安全地分发你的软件。

- Yongfa Lin

Answer 5

那么如何保护你的类不被反编译呢？一个答案是Crema。Crema会混淆你的.class文件中的符号信息，使它们变得不那么容易被反编译。Crema混淆的符号信息包括类名、超类、接口、变量名、方法等。这些符号名称是Java虚拟机（JVM）用来将你的类与库包链接起来所需的。Crema会混淆这些符号名称，并以相同的方式引用它们，以便JVM仍然可以在类和包之间实现正确的链接。

那么Crema是如何工作的呢？基本上，在将你的类文件分发到互联网上之前，先运行Crema。Crema会混淆其中包含的符号信息，并将每个新类放入文件1.crema中。然后你需要将1.crema重命名为类似于filename.class的东西，然后再将其分发到互联网上。

如何保护Java编译后的类

- Ravindra Shekhawat

Answer 6

如果您正在使用Linux和x86-64 CPU，则可以尝试PackerLX。

它是一种免费的基于Web的打包解决方案。将jar文件打包成ELF可执行文件并保护它。 ELF文件具有一些保护技术，例如加密和反编译保护。 PackerLX是一种新的解决方案，它可以保护所有类型的Linux可执行文件免受非专业逆向工程的影响。

- Engin Kuzu

---

PackerLX的链接已经失效。请考虑更换存档链接或其他方式。 - NsaNinja