您是否混淆了您的商业 Java 代码？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12088/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Do you obfuscate your commercial Java code?
提问by cringe
I wonder if anyone uses commercial/free java obfuscators on his own commercial product. I know only about one project that actually had an obfuscating step in the ant build step for releases.
我想知道是否有人在他自己的商业产品上使用商业/免费 Java 混淆器。我只知道一个项目在发布的 ant 构建步骤中实际上有一个混淆步骤。
Do you obfuscate? And if so, why do you obfuscate?
你混淆了吗？如果是这样，你为什么要混淆？
Is it really a way to protect the code or is it just a better feeling for the developers/managers?
它真的是一种保护代码的方法，还是只是让开发人员/管理人员感觉更好？
edit:Ok, I to be exact about my point: Do you obfuscate to protect your IP (your algorithms, the work you've put into your product)? I won't obfuscate for security reasons, that doesn't feel right. So I'm only talking about protecting your applications code against competitors.
编辑：好的，确切地说，我的观点是：您是否进行混淆以保护您的 IP（您的算法，您在产品中投入的工作）？出于安全原因，我不会混淆，这感觉不对。所以我只是在谈论保护您的应用程序代码免受竞争对手的侵害。
@staffanhas a good point:
@staffan有一个很好的观点：
The reason to stay away from chaining code flow is that some of those changes makes it impossible for the JVM to efficiently optimize the code. In effect it will actually degrade the performance of your application.
远离链接代码流的原因是其中一些更改使 JVM 无法有效优化代码。实际上，它实际上会降低应用程序的性能。
采纳答案by staffan
If you do obfuscate, stay away from obfuscators that modify the code by changing code flow and/or adding exception blocks and such to make it hard to disassemble it. To make the code unreadable it is usually enough to just change all names of methods, fields and classes.
如果您进行混淆，请远离通过更改代码流和/或添加异常块等来修改代码的混淆器，从而使其难以反汇编。为了使代码不可读，通常只需更改方法、字段和类的所有名称即可。
The reason to stay away from changing code flow is that some of those changes makes it impossible for the JVM to efficiently optimize the code. In effect it will actually degrade the performance of your application.
远离更改代码流的原因是其中一些更改使 JVM 无法有效优化代码。实际上，它实际上会降低应用程序的性能。
回答by ninesided
I guess it really comes down to whatyour Java code is for, how it's distributed and who your clients are. We don't obfuscate anything, as we've never found one that was particularly good and it tends to be more trouble than it's worth. If someone has access to our JAR files and has the knowledge to be able to sniff around inside them, then there's far more worrying things that they can do than rip off our source code.
我想这真的可以归结为是什么您的Java代码是，它是如何分布的，谁你的客户。我们不会混淆任何东西，因为我们从来没有找到特别好的东西，而且它往往比它的价值更麻烦。如果有人可以访问我们的 JAR 文件并且知道能够在其中嗅探，那么他们可以做的事情远比窃取我们的源代码更令人担忧。
回答by izb
I use proguard for JavaME development. It's not only very very good at making jar files smaller (Essential for mobile) but it is useful as a nicer way of doing device-specific code without resorting to IDE-unfriendly preprocessing tools such as antenna.
我使用 proguard 进行 JavaME 开发。它不仅非常擅长使 jar 文件更小（移动设备必不可少），而且作为一种更好的方式来处理特定于设备的代码而无需求助于 IDE 不友好的预处理工具（如天线），它非常有用。
E.g.
例如
public void doSomething()
{
/* Generated config class containing static finals: */
if (Configuration.ISMOTOROLA)
{
System.out.println("This is a motorola phone");
}
else
{
System.out.println("This is not a motorola phone");
}
}
This gets compiled, obfuscated, and the class file ends up as though you had written:
这会被编译、混淆，并且类文件最终就像你写的一样：
public void doSomething()
{
System.out.println("This is a motorola phone");
}
So you can have variants of code to work around manufacturer bugs in JVM/library implementations without bulking out the final executable class files.
因此，您可以使用代码变体来解决 JVM/库实现中的制造商错误，而无需增加最终的可执行类文件。
I believe that some commercial obfuscators can also merge class files together in certain cases. This is useful because the more classes you have, the larger the size overhead you have in the zip (jar) file.
我相信一些商业混淆器在某些情况下也可以将类文件合并在一起。这很有用，因为您拥有的类越多，您在 zip (jar) 文件中的大小开销就越大。
回答by adum
I spent some time this year trying out various Java obfuscators, and I found one to be miles ahead of the rest: JBCO. It's unfortunately a bit cumbersome to set up, and has no GUI, but in terms of the level of obfuscation it produces, it is unparalleled. You try feeding it a simple loop, and if your decompiler doesn't crash trying to load it, you will see something like this:
今年我花了一些时间尝试各种 Java 混淆器，我发现一个比其他混淆器领先几英里：JBCO。不幸的是，它的设置有点麻烦，并且没有 GUI，但就它产生的混淆程度而言，它是无与伦比的。您尝试为它提供一个简单的循环，如果您的反编译器在尝试加载它时没有崩溃，您将看到如下内容：
if(i < ll1) goto _L6; else goto _L5
_L5:
char ac[] = run(stop(lI1l));
l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
if((int)((l7 & 0xffffffff00000000L) >> 32) != $)
{
l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
} else
{
for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
{
for(int j = III; j < ll1; j++)
{
l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
{
l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
}
}
}
}
You didn't know Java had goto's? Well, the JVM supports them =)
你不知道 Java 有 goto 吗？好吧，JVM 支持它们 =)
回答by Lawrence Dol
I use ProGuardand highly recommend it. While obfuscation does protect your code from casual attackers, it's main benefit is the minimizing effect of removing unused classes and methods and shortening all identifiers to 1 or 2 characters.
我使用ProGuard并强烈推荐它。虽然混淆确实可以保护您的代码免受偶然攻击者的攻击，但它的主要好处是最大限度地减少删除未使用的类和方法并将所有标识符缩短为 1 或 2 个字符的影响。
回答by StaxMan
I think that for the most part obfuscation is pointless: even with full source code it's generally hard enough to figure out what the heck intention was (assuming there are no comments, and no meaningful names for local variables -- which is the case when re-generating sources from byte code). Obfuscation just decorates the cake.
我认为在大多数情况下混淆是没有意义的：即使有完整的源代码，通常也很难弄清楚到底是什么意图（假设没有注释，并且局部变量没有有意义的名称——这是重新- 从字节码生成源代码）。混淆只是装饰蛋糕。
I think developers and especially their managers tend to greatly over-exaggerate risk of someone seeing the source code. While good decompilers can produce nice looking source code, it's not trivial to work with it, and costs associated (not to mention legal risks) are high enough to make this approach seldom useful. I have only decompiled to debug problems with closed-source vendors' products (deadlocks in DB abstraction layer, ugh). Bytecode was actually obfuscated, I think, but we nonetheless found the underlying problem -- it was an actual design problem.
我认为开发人员，尤其是他们的经理，往往会过分夸大有人看到源代码的风险。虽然好的反编译器可以生成漂亮的源代码，但使用它并非易事，并且相关成本（更不用说法律风险）高到足以使这种方法很少有用。我只反编译来调试闭源供应商产品的问题（数据库抽象层中的死锁，呃）。字节码实际上被混淆了，我认为，但我们仍然发现了潜在的问题——这是一个实际的设计问题。
回答by Ivan Kinash
I think that the old (classical) way of the obfuscation is gradually losing its relevance. Because in most cases a classical obfuscators breaking a stack trace (it is not good for support your clients)
我认为旧的（经典）混淆方式正在逐渐失去其相关性。因为在大多数情况下，经典混淆器会破坏堆栈跟踪（这不利于支持您的客户）
Nowadays the main point to not protect some algorithms, but to protect a sensitive data: API logins/passwords/keys, code which responsible for licensing (piracy still here, especially Western Europe, Russia, Asia, IMHO), advertisement account IDs, etc.
现在的重点不是保护某些算法，而是保护敏感数据：API 登录名/密码/密钥、负责许可的代码（盗版仍然存在，尤其是西欧、俄罗斯、亚洲、恕我直言）、广告帐户 ID 等.
Interesting fact: we have all this sensitive data in Strings. Actually Strings is about 50-80% of logic of our applications. It seems to me that future of obfuscation is "String encryption tools".
有趣的事实：我们在字符串中有所有这些敏感数据。实际上，字符串大约占我们应用程序逻辑的 50-80%。在我看来，混淆的未来是“字符串加密工具”。
But now "String encryption" feature is available only in commercial obfuscators, such as: Allatori, Zelix KlassMaster, Smokescreen, Stringer Java Obfuscation Toolkit, DashO.
但现在“字符串加密”功能仅在商业混淆器中可用，例如：Allatori、Zelix KlassMaster、Smokescreen、Stringer Java Obfuscation Toolkit、DashO。
N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.
注意，我是 Licel LLC 的首席执行官。Stringer Java Obfuscator 的开发者。
