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