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.
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.
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".
我使用 proguard 进行 JavaME 开发。 它不仅非常擅长缩小 jar 文件（对于移动设备来说至关重要），而且作为一种更好的方式来执行特定于设备的代码，而无需诉诸 IDE 不友好的预处理工具（例如天线），它非常有用。
例如，
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");
}
}
这会被编译、混淆，并且类文件最终就像您编写的一样：
public void doSomething()
{
System.out.println("This is a motorola phone");
}
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.
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.
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.
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:
I use ProGuard and 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.
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.
我想这实际上取决于您的 Java 代码的用途、它的分发方式以及您的客户是谁。 我们不会混淆任何东西，因为我们从未找到过特别好的东西，而且它往往会带来比其价值更多的麻烦。 如果有人可以访问我们的 JAR 文件并且拥有能够嗅探其中内部的知识，那么他们可以做的事情比窃取我们的源代码更令人担忧。
I guess it really comes down to what your 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.
发布评论
评论（7）
如果您确实进行混淆，请远离混淆器，这些混淆器通过更改代码流和/或添加异常块等来修改代码，从而使其难以反汇编。 为了使代码不可读，通常只需更改方法、字段和类的所有名称即可。
避免更改代码流的原因是，其中一些更改使 JVM 无法有效地优化代码。 实际上，它实际上会降低应用程序的性能。
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.
我认为旧的（经典的）混淆方式正在逐渐失去其相关性。 因为在大多数情况下，经典的混淆器会破坏堆栈跟踪（这不利于支持您的客户端），
现在的要点是不保护某些算法，而是保护敏感数据：API 登录/密码/密钥、负责许可的代码（盗版仍然存在，尤其是西欧、俄罗斯、亚洲，恕我直言）、广告帐户 ID 等。
有趣的事实：我们在字符串中拥有所有这些敏感数据。 实际上，字符串约占我们应用程序逻辑的 50-80%。
在我看来，混淆的未来是“字符串加密工具”。
但现在“字符串加密”功能仅在商业混淆器中可用，例如：Allatori、Zelix KlassMaster, 烟幕、Stringer Java 混淆工具包、DashO。
注意
我是 Licel LLC 的首席执行官。 Stringer Java Obfuscator 的开发者。
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.
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".
But now "String encryption" feature is available only in commercial obfuscators, such as: Allatori, Zelix KlassMaster, Smokescreen, Stringer Java Obfuscation Toolkit, DashO.
N.B.
I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.
我使用 proguard 进行 JavaME 开发。 它不仅非常擅长缩小 jar 文件（对于移动设备来说至关重要），而且作为一种更好的方式来执行特定于设备的代码，而无需诉诸 IDE 不友好的预处理工具（例如天线），它非常有用。
例如，
这会被编译、混淆，并且类文件最终就像您编写的一样：
因此您可以使用代码变体来解决 JVM/库实现中的制造商错误，而无需批量处理最终的可执行类文件。
我相信一些商业混淆器在某些情况下也可以将类文件合并在一起。 这很有用，因为您拥有的类越多，zip (jar) 文件的大小开销就越大。
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.
E.g.
This gets compiled, obfuscated, and the class file ends up as though you had written:
So you can have variants of code to work around manufacturer bugs in JVM/library implementations without bulking out the final executable class files.
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.
今年我花了一些时间尝试各种 Java 混淆器，我发现其中一个远远领先于其他混淆器： JBCO。 不幸的是，它的设置有点麻烦，并且没有 GUI，但就其产生的混淆程度而言，它是无与伦比的。 您尝试为其提供一个简单的循环，如果您的反编译器在尝试加载它时没有崩溃，您将看到类似这样的内容：
您不知道 Java 有 goto？ 好吧，JVM 支持它们 =)
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:
You didn't know Java had goto's? Well, the JVM supports them =)
我使用 ProGuard 并强烈推荐它。 虽然混淆确实可以保护您的代码免受偶然攻击，但它的主要好处是最大程度地减少删除未使用的类和方法以及将所有标识符缩短为 1 或 2 个字符的影响。
I use ProGuard and 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.
我认为在大多数情况下，混淆是毫无意义的：即使有完整的源代码，通常也很难弄清楚到底是什么意图（假设没有注释，并且局部变量没有有意义的名称 - 重新编译时就是这种情况） -从字节代码生成源）。 混淆只是装饰蛋糕。
我认为开发人员，尤其是他们的经理往往会过分夸大某人看到源代码的风险。 虽然好的反编译器可以生成漂亮的源代码，但使用它并不容易，而且相关成本（更不用说法律风险）足够高，使得这种方法很少有用。 我只进行了反编译以调试闭源供应商产品的问题（数据库抽象层中的死锁，呃）。
我认为字节码实际上被混淆了，但我们仍然发现了根本问题——这是一个实际的设计问题。
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.
我想这实际上取决于您的 Java 代码的用途、它的分发方式以及您的客户是谁。 我们不会混淆任何东西，因为我们从未找到过特别好的东西，而且它往往会带来比其价值更多的麻烦。 如果有人可以访问我们的 JAR 文件并且拥有能够嗅探其中内部的知识，那么他们可以做的事情比窃取我们的源代码更令人担忧。
I guess it really comes down to what your 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.