除了混淆之外，还可以采取哪些措施来保护 JAR 文件的安全？
我担心 Java 可执行文件的安全性。它们对反编译几乎没有提供保护。使用 Java Decompiler 这样的工具，即使是小孩子也可以反编译类文件以获得原始代码。
除了代码混淆之外，还可以采取什么措施来保护类文件？加密类加载器仍然是一个神话吗？
I'm concerned about the security of Java executables. They offer little protection against decompilation. With tools like Java Decompiler even a kid can decompile the class files to get the original code.
Apart from code obfuscation what can be done to protect a class file? Is the Encrypted Class Loader still a myth?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在之前的一家公司中，我们曾有过这样的问题，主要是由于管理层的偏执所致。
首先，你必须明白，绝对安全只是一个神话：只要你的程序运行在不受信任的硬件上，它就可以被反编译，无论你使用什么语言。您唯一可以改变的是攻击者了解您的软件/算法/数据的成本。
关于混淆：它可以被认为是第一级保护，因为它使 Java 代码完全不可读。像 ProGuard 这样的优秀混淆器会在变量/方法名称中使用禁用字符，从而防止执行反编译代码。现在，人们可以认为它是一种足够好的安全措施，因为反编译代码并不像运行 Jad 或其他反编译器并拥有完美运行的 Java 代码那么简单。但是，可以理解此类代码中公开的大多数算法（因为可读代码与可编译代码非常不同）。
其他安全措施包括：
从这两个安全措施中，我诚实地选择第一个。事实上，第二种攻击可以通过典型的 HTTPS 攻击（中间人、日志代理等）来破坏，并且将代码放在不受信任的硬件上会带来主要的不便，这使得它可以从那里借用。
In a previous company we had such questions, mainly driven by management paranoia.
First of all, you have to understand that absolute security is only a myth: As long as your program is run on untrusted hardware, it can be decompiled, no matter what language you use. The only thing you can change is the cost of an attacker to understand your software/algorithm/data.
Concerning obfuscation: it can be considered a first level of protection, as it makes the Java code totally unreadable. Good obfuscators like ProGuard use forbidden characters in variables/methods names, preventing execution of decompiled code. Now, one can consider it a good enough security measure, as decompiling code is not as simple as running Jad or other decompilers and having perfectly working Java code. However, it is possible to understand most of the algorithms exposed in such code (as readable code is very different from compilable code).
Additional security measures include:
From those two security measures, I would honestly choose the first. Indeed, the second can be subverted by typical HTTPS attacks (man in the middle, logging proxies, and so on, ...), and has the major inconvenience of putting the code on untrusted hardware, which makes it possibly borrowable from there.
基本上，您可以对字节码执行四件事，以保护其免受 Java 反编译器的攻击：
我的文章中介绍了所有内容 通过混淆器及其他方式保护您的 Java 代码
Basically, there are four things you can do with your bytecode to protect it against Java decompilers:
all covered in my article Protect Your Java Code - Through Obfuscators And Beyond
您可以使用
native编写所有代码。无论如何，逆向工程是可以完成的。但比较难。好吧，这不是一个严格的 java 解决方案。
正如 nfechner 在评论中所说，编写开源应用程序。
You can write all your code with in
native. The reverse engineering can be done anyway. But is harder.Ok, this is not a strictly java solution.
As nfechner said in a comment write open source application.