如何保护已编译的 Java 类？

How to protect compiled Java classes?

提问by Registered User

I know, many similar questions has been asked here. I am not asking if I can protect my compiled Java class - because obviously you will say 'no you can't'. I am asking what is the best known method of protecting Java classes against de-compiling? If you aware of any research or academic paper in this field please do let me know. Also if you have used some methods or software please share you experience? Any kind of information will be very useful. Thank you.

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

采纳答案by SyntaxT3rr0r

First if you're targeting "only" the Windows market there's a very easy to prevent the ".class to .java" decompilation: use a tool like Excelsior Jet that will transform the .jarin an .exe.

首先，如果你的目标“只” Windows的市场有一个非常简单的防止“的.class来的.java”编译：使用像怡东喷气一种工具，将改变的.jar中的.exe文件。

This is foolproof: it is impossibleto get the .java file back if you use Excelsior Jet (so long for all the people saying "it's impossible to prevent decompilation of a .classfile"). Sure, an attacker could launch SoftIceand try to trace your .exebut that will prove a bit trickier than using JAD to decompile the .classto a .javaand it certainly won't allow to find the .javafile back.

这是万无一失的：如果您使用 Excelsior Jet ，就不可能取回 .java 文件（因为所有的人都说“不可能防止.class文件的反编译”）。当然，攻击者可以启动SoftIce并尝试跟踪您的.exe，但这将证明比使用 JAD 将.class反编译为.java有点棘手，而且它肯定不允许找到.java文件。

Now maybe you're targetting OS X and Linux too or you don't have $$$ to shell off for Excelsior Jet.

现在，也许您的目标也是 OS X 和 Linux，或者您没有钱购买 Excelsior Jet。

I'm writing a commercial software written in Java. That software only makes sense if there's an Internet connection. Hence we "protect" our software, amongst other, by having part of the computation happening on the server side: we have several .classthat won't work unless they're generated from the server side and we send them down the wire (and what is sent on the wire is alwaysdifferent: we're generating unique, one-off .classfiles on the server side).

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

This requires an Internet connection but if the user doesn't like how our software works then he's free to buy one our competitor's inferior product ;)

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

Decompiling will not do much good: you actively need to crack the software (ie reproduce what is happening on the server side) or you won't be able to use it.

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

We use our own "string obfuscation" beforewe use Proguard. We also do source code instrumentation (we could have done bytecode instrumenation as well) where we remove lots of things from the code (like the "assert" that we comment out) and introduce some random "code flow obfuscation" [the software can take different paths yet obtain the same result, this is something that really makes the software hard to trace]).

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

Then we use Proguard (which is free) to flatten all our OO hierarchy and to obfuscate the already-code-flow-and-string-obfuscated code.

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

So our flow is:

所以我们的流程是：

• string obfuscation
• random code flow obfuscation
• Proguard
• final .jarthat depends on .classthat are (differently) dynamically generated on the server side.

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

In addition to that we release very regular (and automated) update which always make sure to modify a bit our client/server protection scheme (so that with each release an hypotethical attacker has to start mostly from scratch).

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

Of course it's easier to throw the towel in and to think: "there's nothing I can do to make an attacker's life harder because JAD can find back the .java file anyway"(which is more than very debatable and blatantly wrong in the case where you use a .class to .exe converter to protect your .class from decompiling).

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

回答by Itay Maman

An obfuscator (see http://java-source.net/open-source/obfuscators) will "scramble" the code such that it will not make any sense when de-compiled.

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

回答by Dmitry Leskov

There are several methods:

有几种方法：

• Obfuscation
• Software encryption (flawed)
• Hardware encryption (nearly unbreakable but the performance hit is huge)
• Native compilation

• 混淆
• 软件加密（有缺陷）
• 硬件加密（几乎牢不可破，但性能损失巨大）
• 本机编译

all discussed in details in my article Protect Your Java Code - Through Obfuscators And Beyond

在我的文章Protect Your Java Code - Through Obfuscators And Beyond中详细讨论了所有内容

回答by Ravindra Shekhawat

So how can you protect your classes from being decompiled? One answer is Crema. Crema scrambles the symbolic information in your .class files so that they will become less vulnerable to decompilation. The symbolic information that Crema scrambles includes the name of the class, its superclass, interfaces, variable names, methods, and so on. These symbolic names are needed by the Java virtual machine (JVM) to link your classes with library packages. Crema scrambles these symbolic names and makes references to them in the same way so that the JVM can still achieve the correct linking between classes and packages.

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

So how does Crema work? Basically, before distributing your class files on the Internet, run Crema on them. Crema will scramble the symbolic information contained in them, and will place each new class in the file 1.crema. Your job then is to rename 1.crema to something like filename.class before distributing it on the Internet.

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

HOW TO PROJECT JAVA COMPLIED CLASSSES

如何投影 Java 兼容的类

回答by Yongfa Lin

You can try the Java Protector. It is a better way than obfuscation.It makes a Native ClassLoader by modifying the source of OpenJDK, could encrypt the classes that you want to protect by AES and parse them in their custom-JRE.You can publish your software with the JRE and distribute your software safety.

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