我知道，这里有很多类似的问题。我不是在问我是否可以保护我编译的Java类 - 因为很明显你会说“不，你不能”。我在问什么是保护Java类不被反编译的最着名的方法？如果您知道该领域的任何研究或学术论文，请告诉我。如果您使用过某些方法或软件，请分享您的经验吗？任何类型的信息都将非常有用。谢谢。
答案 0 :(得分：16)
首先，如果您只针对Windows市场，那么很容易阻止“.class到.java”反编译：使用像Excelsior Jet这样的工具来转换 .jar 在 .exe 。
这是万无一失的：如果你使用Excelsior Jet，那么获取.java文件是不可能（所有人都说“不可能阻止 .class的反编译” 文件“）。当然，攻击者可以启动 SoftIce 并尝试跟踪您的 .exe ，但这比使用JAD反编译 .class 有点棘手到 .java ，它肯定不会允许找回 .java 文件。
现在也许你的目标是OS X和Linux，或者你没有使用$$$来为Excelsior Jet打包。
我正在编写一个用Java编写的商业软件。如果有互联网连接，该软件才有意义。因此，我们“保护”我们的软件，其中包括在服务器端进行部分计算：我们有几个 .class ，除非它们是从服务器端生成的，否则无法工作我们将它们发送到线路（并且线路上发送的内容总是不同：我们在服务器端生成唯一的，一次性的 .class 文件）。
这需要互联网连接，但如果用户不喜欢我们的软件如何工作，那么他可以自由购买我们的竞争对手的劣质产品;）
反编译不会带来太多好处：你主动需要破解软件（即重现服务器端发生的事情），否则你将无法使用它。
我们在使用Proguard之前使用我们自己的“字符串混淆”。我们也做了源代码检测（我们也可以完成字节码的检测），我们从代码中删除了很多东西（比如我们注释掉的“断言”）并引入一些随机的“代码流混淆”[该软件可以采取不同的路径却获得了相同的结果，这真的让软件难以追踪]。
然后我们使用Proguard（它是免费的）来展平我们所有的OO层次结构并混淆已经代码流和字符串混淆的代码。
所以我们的流程是：
除此之外，我们发布非常规则（和自动化）的更新，总是确保修改我们的客户端/服务器保护方案（这样每次发布时，一个低位的攻击者必须从头开始）。
当然，更容易抛出并思考：“我无能为力让攻击者的生活变得更难，因为JAD无论如何都能找到.java文件”（这是更多在使用.class到.exe转换器来保护.class免于反编译的情况下，比非常有争议和明显错误。
答案 1 :(得分：6)
混淆器（参见http://java-source.net/open-source/obfuscators）将“扰乱”代码，使其在解编译时没有任何意义。
答案 2 :(得分：6)
有几种方法：
我的文章 Protect Your Java Code - Through Obfuscators And Beyond
中详细讨论了所有内容答案 3 :(得分：0)
那么如何保护您的课程免遭反编译？一个答案是Crema。 Crema会对.class文件中的符号信息进行加密，以便它们不易受到反编译的影响。 Crema扰乱的符号信息包括类的名称，其超类，接口，变量名，方法等。 Java虚拟机（JVM）需要这些符号名称来将类与库包链接起来。 Crema对这些符号名称进行加密，并以相同的方式对它们进行引用，以便JVM仍然可以实现类和包之间的正确链接。
那么Crema如何运作？基本上，在Internet上分发类文件之前，请在它们上运行Crema。 Crema将对其中包含的符号信息进行加扰，并将每个新类放在1.crema文件中。然后，您的工作是将1.crema重命名为filename.class，然后再将其分发到Internet上。
答案 4 :(得分：0)
您可以尝试 Java Protector 。这是一种比混淆更好的方法。它通过修改OpenJDK的源来创建一个Native ClassLoader，可以加密你想要通过AES保护的类并在他们的custom -JRE中解析它们。你可以用JRE发布你的软件并分发你的软件安全。
答案 5 :(得分：0)
如果您使用的是Linux和x86-64 CPU，则可以尝试PackerLX。
这是一个基于Web的免费打包程序解决方案。将jar文件打包到ELF可执行文件中并对其进行保护。 ELF文件具有一些保护技术，例如加密和反编译保护。 PackerLX是一种新的解决方案，它可以保护所有类型的linux可执行文件免于非专业的反向工程。