除了混淆之外，还可以做些什么来保护jar文件？ [英] What can done to secure jar files besides obfuscation?

问题描述

我担心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?

推荐答案

在之前的公司中，我们遇到过这样的问题，主要是由管理偏执狂引起的。

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.

关于混淆：它可以被视为第一级保护，如它使Java代码完全不可读。像 ProGuard 这样的优秀混淆器在变量/方法名称中使用禁用字符，从而阻止执行反编译代码。现在，人们可以认为它是一个足够好的安全措施，因为反编译代码不就像运行Jad或其他反编译器并具有完美的Java代码一样简单。但是，可以理解在此类代码中公开的大多数算法（因为可读代码与可编译的代码非常不同）。

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

其他安全措施包括：

• 使用某种网络服务发送结果，在服务器上运行敏感代码并获取结果（使用REST / SOAP / YouNameIt）


• 使用HTTPS和（可能）其他安全层从远程服务器加载敏感代码。

从这两项安全措施中，我会诚实地选择第一项。实际上，第二种可能会被典型的HTTPS攻击（中间人，日志代理等等）破坏，并且主要将代码放在不受信任的硬件上会带来不便，使它可以从那里借来。

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.

这篇关于除了混淆之外，还可以做些什么来保护jar文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！