反编译器字节码和混淆器 [英] Decompiler Bytecode and Obfuscators

问题描述

我们可以从java字节码完全反向设计源代码吗？为什么在Java中允许这个功能？java反编译器对反混淆器的成功程度如何？

解决方案

我知道这个问题很老但是我在我什么也没发现之前，一直在寻找可靠的答案。
所以在这篇文章中，我总结了一些混淆J2EE JAR的努力。
看来，到2014年（写作时间），那里的选择并不多。
如果您稍后阅读此评论，那么事情可能已经改变或修复。
当我想到原因时，我开始意识到整个混淆工作给人一种虚假的安全感。别误会我的意思。它确实增加了一定程度的安全性，但没有我希望的那么多。
我会尝试预览我发现的解释自己。我的建议是个人的，其他人可能会不同意。

首先：Java中的混淆是获取字节码并使其可读性降低的过程（使用反编译器在保持其原始功能的同时，我们可以做些什么，Java作为一个交换器，必须保持其字节码暴露。如果类文件落入坏人手中，则运行混淆器作为安全措施。混淆的结果是反向映射文件和带有混淆类的JAR。反向映射文件用于执行堆栈跟踪读取（a.k.a re-trace）或将字节码恢复为其原始形状。模糊类的运行时性能命中率不应超过10％（但这实际上取决于您在代码中执行的操作）。

但是有一个很大的但是。混淆将扰乱你的代码，但它不会使它成为黑客防范。请记住，你只会花时间和坚定的黑客找到一种方法将你的字节码逆向工程为纯算法。

恕我直言：隐藏敏感片段的最好方法代码是将它淹没在一堆无意义的代码中。

一些黑客会尝试修改你的字节码（通过代码注入）来帮助他们实现目标。一些混淆器提供额外级别的JAR强化，使其更难修改。

去混淆器和反编译器：我最喜欢的Java反编译器是JD-GUI。然而，当谈到去混淆器时，我发现市场很空洞。大多数工具都会要求您提供一个提示（用于加密源JAR的混淆工具），但它们都没有真正提供结果（其中一些甚至在尝试解密JAR时崩溃）。它们是低维护的开源项目。我甚至找不到付费应用程序来进行体面的去混淆。如果你知道的话，请告诉我。

免费解决方案

有开源，免费的混淆器，通常只是重命名类/方法名称，使其成为一个字母方法（即从printUsage（String params）到（String p））。
他们可能会在这里暗示，甚至剥离调试信息以使其更难一些。 （调试信息保存在每个Java方法字节码的末尾，包含：行号，变量名等）。
这是一项不错的工作，但是使用调试器的Java开发人员可以很容易地推断出每个参数的用途，同时进行一些实时运行。
一个很好的开源混淆器是ProGuard，但还有几个工具。
尽管如此，如果你真的是安全狂热的话，你可能会想要更强大的东西。更强烈的要求更多的功能（和更多的钱）导致我们下一个项目：

付费解决方案

虽然免费产品只能更改课程方法名称，付费产品通常会提供更多功能：

1. 代码/ flow obfuscation：这将改变方法代码并注入空循环/死代码/混淆切换表等。他们中的一些甚至可能加扰异常表内容。混淆强度通常决定输出大小。
   注意：关于代码混淆：我故意在我的评论中避免了细节。我看到和分析的一些字节码暴露了他们的混淆方法，我希望保护他们的IP。我对谁使用更好的算法有一个看法。如果你想知道，请联系我。




2. 类/方法重命名：这很明显，我们在免费混淆中讨论过它。某些产品将重命名类名，然后递归搜索该类的反射用法并修复它们。付费产品甚至可以为同一目的重命名Spring / Wink配置文件（在反射中重命名）。
   字符串加密：对于代码中的每个字符串like this，它会将其加密到某个级别并将密钥保存在某处（在类常量表/静态块/新方法或任何其他方法中）。 / p>




3. 调试信息：剥离部件或加扰。他们将删除行号信息。
   class




4. 强化：各种方法，比如在类/方法的开头注入一些签名方案，确保外人不会能够轻松修改JAR并运行它。对Android或applet来说不那么重要，因为大多数都是数字签名的无论如何。一些将硬化与水印结合起来跟踪盗版。但我们都知道软件的反盗版方法注定要被黑客入侵。几十年来，游戏行业一直受到影响，直到基于网络的订阅到来。




5. 由于这里的大多数产品都处理Java，因此其中一些产品提供Android集成。这意味着它不仅会混淆Java（dalvik）代码，还会操纵Android的清单文件和资源。一些提供反调试：删除Android应用程序中的调试标志。




6. 很好的GUI应用程序来配置各种选项，并可能在给定的日志上重新恍惚文件。 UI通常用于生成配置文件。使用此类文件，您可以稍后重新进行模糊处理，甚至可以从命令行重新进行模糊处理。




7. 增量构建支持 - 这对于发布产品的大型组很有用经常更新/修复。您可以告诉混淆器保留旧的混淆结果，并随机混淆新代码流。通过这种方式，您可以确保对方法签名的影响最小。如果没有此标志，JAR上的每个混淆周期都会产生不同的输出，因为大多数优秀工具在其算法中使用某种级别的随机性。




8. CLI和分布式构建。当你独自工作时，运行混淆器不是一个大问题。您需要将混淆器配置为相关选项并运行它。但是，在企业中，当将混淆器集成到构建脚本时，事情会有所不同。还有另一个复杂程度：构建引擎任务（如ant / maven）和许可证管理。我测试的所有混淆器都有命令行API的好消息。在分布式构建环境中，有一些构建机器的集群/池来支持构建的并发需求。群集是动态和虚拟的，机器正在上升或下降，具体取决于各种条件。一些混淆产品基于cpuID许可证文件或主机名。这可能会给构建团队带来相当大的挑战。有些人更喜欢本地浮动许可服务器。有些可能需要公共许可证服务器（但那时：并非所有构建服务器场都可以访问公共Internet）。有些提供多站点许可证（在我看来是最好的）。




9. 一些提供代码优化 - 代数等价和丢弃死代码。它很好，但我相信今天的JDK在优化字节码方面做得很好。确实，死代码可以让你下载更大，但今天的带宽不是一个问题。我还想相信，在软件今天20:80拇指规则仍然适用。在任何应用程序中，20％可能都是死代码。

那么我试过的玩家是谁？

• Zelix.com的KlassMaster - 业内历史最悠久的之一。然而，他们提供的固体产品每年发布3-4次。这种情况持续了数十年（自1997年以来）。 Zelix提供良好的电子邮件支持并及时回复我的所有电子邮件。他们有一个很好的GUI客户端来混淆JAR或创建配置文件以供将来混淆。它简单而光滑。这里没什么特别的他们为所有标志提供了简单易读的在线文档。它们支持引擎应该混淆的排除和包含正则表达式。我最喜欢他们的过程的是它还为异常表添加了噪音。它使方法异常处理更加混乱。它们的流动混淆器强​​度非常好，可以配置在3个可能的级别（轻，中和攻击性）之间。我喜欢的另一个功能是它们为调试信息剥离（在线行号或在线局部变量或两者）提供的微调。 Klass Master不提供任何
  专用的Android标志或防篡改方法。他们的许可模式非常简单：一个文本文件放在KlassMaster主JAR附近。它们还支持增量混淆。




• 来自secureTeam.net的JFuscator：虽然secureTeam也有.Net工具，但我专注于他们的Java工具功能。他们的（基于Swing的）GUI工具看起来不错，但在尝试最简单的混淆任务时会崩溃。错误始终相同：读取'/opt/sun-jdk1.7.0_55/jre\lib\rt.jar'时出错。原因：''/ opt / sun-jdk1.7.0_55 / jre \ lib\rt.jar'：没有这样的文件或目录'。当然，我在/opt/sun-jdk1.7.0_55/jre中安装了我的Java。你可以想象他们根本不希望linux反斜杠结构。我通过电子邮件联系了secureTeam.net支持，其中包含轻微的路径问题。他们问我是不是一个linux用户，在我回复之后，他们从未回复我的电子邮件。我也试过他们的网站在线聊天：没有回应。所以我停止了测试。没有进一步的结果，我无法检查混淆的字节码质量。从他们的网站看来，他们似乎有防篡改方法，字符串操作，方法重命名和其他一些功能。




• GuartIt4J（由Arxan.com提供）：Arxan在移动环境中是相当坚实的玩家，因此他们提供Android混淆器，这当然适用于Java。他们拥有最灵活的引擎之一。他们提供代码混淆，字符串加密等相似您可以定义代码混淆的复杂性。它只是一个整数。越高 - 你的方法越长。当然，你必须小心不要超过每个类的JVM 64KB限制......正如我之前所说的，隐藏敏感代码的最佳策略之一不是加密它，而是将其注入大量垃圾中。这正是GuardIt所做的。它也可以以与方法异常表相同的方式进行爆炸。我设法在其异常表中创建了一个包含100个异常的方法（pre-obfuscator它是5）。他们错过了什么：他们的重新追踪计划不是所提供的主要JAR的一部分。然而，他们非常友好地向我发送了一个示例Java程序，该程序在给定反向映射文件和日志的情况下执行重新跟踪。它们不支持增量混淆，也不支持调试信息的灵活性。调试信息剥离是全部或全部。观察输出JAR，你将注入大量的条件和跳跃。不用考虑，爆炸的班级规模有其性能受到打击。在某些方法中，我在应用长混淆时测量了几乎50％的性能（在这些方法中没有I / O）。所以推断代码需要付出代价。（从400个操作码 - 我在混淆后达到了2200个操作码）。 JD-GUI，我的de-compiler无法打开这样的类并崩溃（IndexOutOfBoundException）。它们还提供完整的类加密。这意味着该类是使用一些对称密钥加密的，这需要一个特殊的（或自定义编写的）类加载器来在内存中打开它。这是一种反篡改机制以及隐藏代码。请记住，如果没有类加载器帮助，JVM就无法运行该类。它是一个很好的功能，但秘密密钥和引导加载程序JAR可能就在那里。如果他得到加密的JAR，黑客最终会得到他的手并解密课程。然而，这是普通黑客需要通过的另一个障碍。我在这里不喜欢的是许可证文件策略：受限于CPUid或需要安装浮动许可证服务器。




• SecureIt（由Allatori.com提供） ）：SecureIt提供所有通用代码混淆，字符串加密，重命名等。除了标准的混淆方法之外，它们还提供某种水印，这是一种防篡改/盗版方法。他们支持Android和JavaME（最近谁使用ME ?!）。他们支持增量混淆。关于配置SecureIt的一点需要注意：它是所有命令行。这次没有GUI工具。就个人而言，我不介意命令行工具，只要它们有良好的文档。幸运的是，他们有一个非常好的文档和丰富的API，如果你愿意，可以调整许多标志。您可以使用它们的工具（也是命令行）重新跟踪。他们不能混淆异常表。我没有检查他们的许可机制。




• DashO（由Preemptive.com提供）：DashO obfuscator可能会被记住，因为它可能是您可以获得的最佳UI工具（创建您的配置）。与SecureIt一样，他们使用异常表混淆，但它们具有所有其他所需功能（以及CLI，Spring框架和gradle / ant集成，甚至是eclipse插件）。好吧，他们确实记录了一个try-catch混淆器（与异常表混淆器相同），但它只是对引擎的推荐。当我尝试它时，它对异常表没有影响。正如我所说，GUI工具非常棒，并且嵌入了重新跟踪。他们还提供某种应用程序签名和水印作为防篡改/盗版机制。 DashO提供卓越的Android集成，并在其产品中结合了分析上传的大门。您实际上可以跟踪您的申请。注入崩溃日志上传程序并向JAR报告代码。然而，这不是混淆的范围 - 这是一个完全不同的代码注入产品。他们有很好的支持。在线和通过电话。他们的许可计划基于每月订阅或一次性购买付款。有点不同于其他人。他们使用浮动许可证服务器来支持大型环境。

我希望这有点帮助..

Can we completely reverse-engineer the source code from java bytecode ? Why this feature is allowed in Java and How successful are java decompilers against obfuscators.?

解决方案

I know this question is old but I kept looking for a reliable answer until I found nothing. So in this post I summarize some of my effort to obfuscate a J2EE JAR. It seems , that by year 2014 (time of writing) there are not many options out there. If you read this review later then things may have changed or fixed. When I think why , I start to sense that the whole obfuscation effort gives a false sense of security. Don't get me wrong. It does add a level of security, but not as much as I would hope. I will try to give a preview of what I found to explain myself. My recommendation are personal , others may disagree with it.

So to begin with: obfuscation in Java is the process of taking bytecode and making it less readable (using a decompiler of course) while maintaining its original functionality.What can we do, Java ,working as an interperter, must keep its bytecode exposed. You run the obfuscator as a measure of security in case the class file falls into the wrong hands. The result of the obfuscation is a reverse-mapping files and a JAR with the obfuscated classes. The reverse mapping file is used of-course to perform stack trace reading (a.k.a re-trace) or to revert the bytecode to its original shape. The runtime performance hit of an obfuscated class should not pass the 10% (but this really depends on what you do in your code).

But there is a big "but" . Obfuscation will scramble your code but it won’t make it hacker-proof. Bare in mind you only buy time and a determined hacker will find a way to reverse engineer your bytecode into its pure algorithm.

IMHO: the best way to hide a sensitive piece of code is to drown it in some huge pile of meaningless code.

Some of the hackers will try to modify your bytecode (by code injection) to help them achieve their goals. Some obfuscators offer additional level of JAR hardening , making it harder to modify.

De-obfuscators and de-compilers: my favourite Java decompiler is JD-GUI . However, when it comes to de-obfuscators I found the market pretty empty. Most of the tools ask you for a hint (what obfuscation tool was used to encrypt the source JAR) , yet none of them really deliver results (some of them even crash when trying to de-cipher the JAR). They are open source projects with low maintenance. I couldn’t even find a paid application to do a decent de-obfuscation. so enlighten me if you know something.

Free solutions

There are open source , free obfuscators which usually simply rename the classes/methods names, making it one letter method (i.e. from printUsage(String params) to a(String p) ). They might ,as hinted here , even strip debugging information to make it a bit more difficult. (debugging information is kept at the end of every Java method bytecode and contains: line numbers, variables names ,etc.). Its a nice effort , but an experience Java developer with a debugger can very easily deduce the purpose of each parameter while doing few live runs. One of the nice open source obfuscators is ProGuard but there are several more tools. Nevertheless , if you truly security fanatic you will probably want something stronger. Stronger demands more features (and more money) which leads us to the next bullet:

Paid solutions

While free products may only change classes method names , paid product will usually offer more features:

1. code/flow obfuscation: this will change the method code and inject empty loops/dead code/confusing switch tables and alike. Some of them may even scramble the exception table content. the obfuscation strength usually determine the output size. Note: regarding code obfuscation: I deliberately avoided the details in my review. Some of the bytecode I saw and analyzed expose their obfuscation methods, and I wish to protect their IP. I do have an opinion about who uses better algorithms. contact me if you wish to know.

2. classes/method renaming : well this is the obvious , we discussed it in the free obfuscation. Some of the product will rename the class name and then recursively search for reflection usage of that class and fix those too. Paid products may even rename Spring /Wink configuration files for the same purpose (renaming in reflection). String encryption: for every string "like this" in the code, it will encrypt it to some level and keep the key somewhere (in the class constant table/static blocks/a new method or any other mean).

3. debug information : stripping parts or scrambling.many of them will remove the line numbers info. class

4. hardening: all kinds of methods like injecting some signing scheme into the beginning of the class/method, making sure an outsider won’t be able to easily modify the JAR and run it. Less important for Android or applets as most of them are digitally signed anyhow. some will combine hardening with water-marking to track pirated copies. But we all know anti-pirating methods by software are doomed to be hacked. Game industry suffered from it for decades until network based subscriptions arrived.

5. Since most products here deal with Java , some of them provides Android integration. It means it will not only obfuscate the Java (dalvik) code , but also manipulates the Android's manifest file and resources. Some offer anti debugging: remove the debug flag in android apps.

6. Nice GUI app to configure the various options and maybe do a re-trance on a given log file. The UI is usually used to generate a config file. with such file you can later re-play the obfuscation many times, even from command line.

7. Incremental build support - this is useful for large groups who release product updates/fixes frequently. You can tell the obfuscator to preserve old "obfuscation" result and randomly obfuscate only "new" code flows. this way you can be sure minimal impact on your methods signature. Without this flag , each obfuscation cycle on a JAR would yield a different output as most good tools use some level of randomness in their algorithms.

8. CLI and distributed builds. When you work alone then running an obfuscator is not a big issue. you need to configure the obfuscator to your relevant options and run it.However, in enterprise , when integrating obfuscator into the the build script things are a bit different. There is another level of complexity: build engine tasks (like ant/maven) and license management. The good news that all obfuscator I tested have command line API. In distributed build environment there are cluster/pool of build machines to support concurrent demand of builds. The cluster is dynamic and virtual, machines are going up or down, depending on various conditions. Some obfuscation products are based on cpuID license file or hostname. This can create quite a challenge for the build teams to integrate. Some prefer a local floating license server. Some may require public license server (but then: not all build farms have access to the public internet). Some offer multi-site license (which in my opinion is the best).

9. Some offer code optimizations - algebric equivalence and dropping of dead code. Its nice, but I believe that today's JDK do good job in optimizing bytecode. Its true that dead code makes you downloadable bigger, but with today's bandwidth its less than a problem. I also want to believe that in software today 20:80 thumb rule still applies. in any application 20% is probably a dead code anyway.

So who are the players I tried ?

• KlassMaster by Zelix.com - one of the oldest in the industry. Yet they deliver a solid product with 3-4 releases per year. This been going for decades (since 1997). Zelix provides good email support and answered all my emails in a timely manner. They have a nice GUI client to either obfuscate a JAR or create a config file for future obfuscation. It simple and slick. nothing special here. They provided simple to read on-line documentation for all their flags. they support both "exclude" and "include" regular expressions for what the engine should obfuscate. The thing I liked about their process most is that it also adds "noise" to the exception table. It makes it a bit more confusing regarding the method exception handling. Their flow obfuscator strength is quite good and can be configured between 3 possible levels (light,medium and aggressive). Another feature I liked is the fine tuning they provide for debug info stripping (online line numbers, or online local variables or both). Klass Master doesn’t provide any dedicated Android flags or anti-tamper methods. Their licensing model is quite simple: a text file to be placed near the KlassMaster main JAR. They also support incremental obfuscation.

• JFuscator from secureTeam.net : While secureTeam also has a .Net tool , I focus on their Java tool capabilities. Their (Swing based) GUI tool seems nice but it crash when trying the simplest obfuscation task. the error was always the same: Error reading '/opt/sun-jdk1.7.0_55/jre\lib\rt.jar'. Reason: ''/opt/sun-jdk1.7.0_55/jre\lib\rt.jar': no such file or directory' . Now of course I have my Java installed in /opt/sun-jdk1.7.0_55/jre. You can image that they simply didn’t expect linux back slash structure. I contacted secureTeam.net support by email with the minor "path" problem. They asked if I am a linux user and after I replied I am , they never answered my email. I also tried their web site on-line chat : no response. So there I stopped testing. Without further results, I couldn’t examine the obfuscated bytecode quality. From their web site it seems they have anti-tamper method , String manipulation, method renaming and few other features.

• GuartIt4J (by Arxan.com) : Arxan is fairly solid player in the mobile environment and as such they offer Android obfuscator which of course works well for Java. They have one of the most flexible engines.They provide code obfuscation,string encryption and alike You can define the complexity of code obfuscation. it is simply an integer. the higher - the longer your method turns out. ofcourse, you must be carefull not to exceed the JVM 64KB limit per class… As I said before one of the best strategies to hide a sensitive code is not to encrypt it , but to inject it into huge pile of garbage. This is exactly what GuardIt does. It can also explode in the same way the methods exception table. I managed to create a method with 100 exceptions in its exception table (pre-obfuscator it was 5). what they miss: their re-trace program is not part of the supplied main JAR. Nevertheless, they were kind enough to send me a sample Java program that performs re-trace given the reverse mapping file and the log. They don’t support incremental obfuscation and no flexibility regarding debug information. Debug information stripping is either all or nothing. watching the output JAR you will tons of conditions and jumps that were injected. Bare in mind , exploding the class size has its performance hit. In some methods I measured almost 50% performance hit when applying long obfuscation (no I/O in those methods). so extrapolating the code comes with a price.(from a 400 opcodes - I went up to 2200 opcodes after obfuscation). JD-GUI , my de-compiler failed to open such classes and crashed (IndexOutOfBoundException). They also supply complete class encryption . Meaning the class is encrypted with some symetrical key which demands a special (or custom written) class loader to open it in memory. This is an anti-tamper mechanism as well as hiding code. Just remember that a JVM can’t run that class without the class loader help. Its a nice feature, but the secret key and the bootstrap loader JAR are probably there. If he got the encrypted JAR the hacker will eventually get his hands and decrypt the classes. Yet this another level of obstacle the common hacker will need to pass. What I didn’t like here is the license file policy: is bounded to CPUid or need to install a floating license server.

• SecureIt (by Allatori.com) : SecureIt offers all the general code obfuscation, string encryption ,renaming and such. On top of the standard obfuscation methods they also offer some kind of water-marking which is an anti-tamper/pirating method. They support Android and JavaME (who uses ME these days?!). They support incremental obfuscation. The one thing to note about configuring SecureIt: it is all command line. No GUI tool this time. Personally , I don’t mind command line tools as long as they come with good documentation. Luckily they have a very good documentation and a rich API with many flags to tune if you wish. you can re-trace with they tool (also a command line ) . They can’t obfuscate the exception table. I didn’t check their licensing mechanism.

• DashO (by Preemptive.com) : DashO obfuscator will be remembered probably as the best UI tool you can get (to create your configuration). Like SecureIt they lake the exception table obfuscation but they have all the rest of the required features (as well as CLI, Spring framework and gradle/ant integration, and even an eclipse plugin) . Well, they do document a try-catch obfuscator (which is same as exception table obfuscator) , but it is only a recommendation to the engine. When I tried it , it had nil effect on the exception table. As I said , the GUI tool is superb and has a re-trace embedded into it. they also offer some kind of application signing and water-marking as an anti-tamper/pirating mechanism. DashO provides superb Android integration and also combine in their product a door for analytics uploads. You can actually track your application. Injecting crash log uploaders and reporting code to your JAR. Nevertheless that’s not the scope of obfuscation - that’s a whole different code injection product. They have a very good support. both online and by phone. Their licensing scheme is based on monthly subscription or one time purchase payment. A bit different than others. They are using a floating license server to support large environments.

I hope this helps a bit..

这篇关于反编译器字节码和混淆器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！