标题: 为什么关注Java反编译器

创建: 2014-10-15 17:25
链接: https://scz.617.cn/misc/201410151725.txt

对Java反编译器最近关注了一段时间，有些朋友表示好奇，我说说这个事。

单个class或者class不多的时候，可以在反编译结果上进行修改，然后再次编译回去。
如果jar包结构复杂，涉及class众多，前述办法较吃力。比较靠谱的办法是反编译出
单个.java进行修改，充分利用原有.class再编译。

有个Java Bytecode Editor，可以在Java汇编基础上修改class。它有别的问题，比
如涉及try块、删除增加指令导致字节码大小变化时，JBE未自动进行相关修正。我一
般静态看看反编译结果，然后用16进制编辑器直接操作class中的字节码，中间会结
合使用reJ。

BTrace跟前述需求无关。Javassist使得字节码处理变得简单，在Java源码级处理字
节码，给用户提供封装好的API操作class，把中间各种繁杂的细节隐藏起来。用好这
个工具，就不用考虑JBE了。

从静态修改jar包来说，前面说的这些都是常规手段。我以前基本不考虑反编译、修
改、再编译这条路。如果有人特别推崇这种办法，据我观察，TA的目标都不是什么复
杂目标。但后来发生了一件事，改变了我的看法。道长在我司内网提到一个针对
Android的反编译工具JEB，它本身是跑在Sun JVM上的。我花了点时间逆向分析JEB，
它混淆得比较厉害，幸好我还算擅长直接操作字节码，最终把JEB破解并补了部分被
屏蔽掉的功能。

我在看雪上发布了修正后的JEB，引来一位Java大牛，TA主要是说一些往日的隐密。
从来往信件中发现这位大牛比较低调，所以就不提TA的看雪ID了，下面代之以X。我
提到JEB混淆得特别厉害，自己纯肉眼反混淆的情况下把这事办了。X说，可以研究研
究Y软件，可以用来反混淆。我去看了Y，这是一款开源混淆工具，其实当时并没有第
一时刻理解X的话。X又说，如果我答应不公开，TA会给我一份JEB的反编译工程。收
到这份JEB的反编译工程时，立刻明白了X之前说过的话。在Eclipse里相当顺利地将
这份JEB反编译工程重新编译过去，找了几个APK测试，无误。当时我问候了无名对象
的女性亲属，大白话就是，我惊呆了。原谅我这么容易惊呆，没见识过Java大牛呗，
这次见识了。

某天我有空时真去看了Y的源代码，也用了用Y。由于有X提供的信息做指引，很快我
就在Y的基础上实现了一定程度的反混淆。关于Java代码反混淆，不是说恢复到混淆
之前的状态，而是说从一种很干挠人工分析的状态转变到一种人工分析可接受的状态，
可以大致类比x86汇编插花之后去花。只要你有办法完成这种变化，就可以说你在反
混淆。

中间发生很多事，没再纠缠这个事。大概一个月后，我又有点时间了，这次我雄心勃
勃地用修改过的Y反混淆了JEB，用JD-GUI反编译，然后试图在Eclipse里重新编译，
可耻地失败了。检查错误信息之后，我发现JD-GUI反编译效果不理想，有些class用
古老的JAD能反编译，JD-GUI却不能。检查X发给我的JEB反编译结果，发现它们不像
是JD-GUI的输出。再次去看雪找X，直接问TA当时用的反编译器是什么。X说，反编译
器是从开源的改的，参考了Z。

以前我那些修改jar包的搞法，理论上可以包打天下。但随着Java反逆向领域的不断
增强，时间成本越来越高。破解JEB这次，就感觉不太好。如果说之前我的那些搞法
是常规武器，X展示的反混淆->反编译->修改->再编译之路就是核武器。与传统小白
们相比，这里的重点在前两步，反混淆->反编译->。以前我不关注，因为觉得这条路
荆棘丛生未必可行，现在不同了，X成功了。相当于美国率先爆了原子弹，后面四大
流氓知道这条路一定存在，然后依次摸索出来。

干这件事，就是前面痛苦，成功后只剩爽死。可以一劳永逸地解决一大类问题，而不
用停留在低阶重复阶段。

当然，我现在还没爽死。我只是不断地考察各种Java反编译器，无论闭源、开源，统
统拿经Y反混淆后的JEB测试，然后尝试修正开源反编译器暴露出来的问题。等到出现
一个修改后的Java反编译器，用它反编译经Y反混淆后的JEB，不必再手工修改什么的
情况下一次性再编译成功，就算初步成功。以后只需长期维护这款修改过的Java反编
译器，在不断地失败中走向长久的成功。

解决问题，很重要的一点是，解决一类问题，而不是解决单个问题。

这就是我为什么关注Java反编译器。