如何保护已编译的Java类？ [英] How to protect compiled Java classes?

问题描述

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

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.

推荐答案

首先，如果您的目标是仅Windows市场，那么很容易阻止.class to .java反编译：使用像Excelsior Jet这样的工具，它将转换 .exe 中的 .jar 。

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 .jar in an .exe.

这是万无一失的：如果你使用Excelsior Jet，那么获取.java文件是不可能（所有人都说不可能阻止 .class <的反编译 / em>文件）。当然，攻击者可以启动 SoftIce 并尝试跟踪您的 .exe ，但这比使用JAD反编译 .class 有点棘手到 .java ，它肯定不会允许找回 .java 文件。

This is foolproof: it is impossible to 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 .class file"). Sure, an attacker could launch SoftIce and try to trace your .exe but that will prove a bit trickier than using JAD to decompile the .class to a .java and it certainly won't allow to find the .java file back.

现在也许你也是针对OS X和Linux的，或者你没有为Excelsior Jet解决问题。

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

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

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 .class that 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 always different: we're generating unique, one-off .class files on the server side).

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

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.

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

We use our own "string obfuscation" before we 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（免费）来压扁我们所有的OO层次结构并模糊已经代码流和字符串混淆的代码。

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


• final .jar 依赖于 .class 在服务器端动态生成的（不同的）。

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

除此之外，我们还发布了非常规则（和自动化）的更新，总是确保修改一下我们的客户端/服务器保护方案（这样每个版本都会发布一个hypot道德攻击者必须从头开始。）

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).

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

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).

这篇关于如何保护已编译的Java类？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！