-
-
[原创]几款Android反编译器对循环结构的还原能力测试记录
-
发表于: 2019-6-26 11:29
-
喜欢jadx的人会常常吐槽JEB反编译器：卖的这么贵，反编译效果还不怎么样。这里我想说的是，JEB毕竟是纯dalvik反编译器，从字节码解析到高级代码生成的整个过程都得从头来过，反编译差点也可以理解（ 对于写一款全新的反编译的本人来说深有感触，经典算法和理论也常常有不奏效的时候，因此往往需要改进、优化和扩展，甚至需要提出极端情况下的解决方案，尤其是对抗结构化混淆时）。应该说 JEB 主要槽点是昂贵的费用，其采用的结构化分析技术的确属于比较落后的，但是JEB的功能比jadx更为丰富，更有利于做逆向分析。
我们知道，反编译器是编译器的逆过程，许多反编译器的理论和技术来源于编译理论，这里不细说。反编译器主要包含二进制程序解析、指令(字节码/机器码)解码(句法分析、语义分析)、中间代码生成、控制流图生成、数据流分析、控制流分析、高级代码生成等过程，其中各个阶段都有相关算法来处理。在反编译理论中，控制流分析中最核心的算法是结构化分析算法，结构化算法的优劣决定了反编译器的代码还原能力。而还原循环结构的结构化算法成为反编译实现的一个难点，即便目前的论文已经实现完全无goto的算法，但是这种算法面对复杂混淆后控制结构时还是会出现代码丢失甚至是拒绝工作的情况。
因此，本文简单设计了几种循环类的控制结构来针对性的测试这几款反编译器的还原能力。同时也是为了检验GDA对循环结构的还原能力，发现不足并加以优化。对于反编译结果，我们遵循“语义不变性>代码可读性>代码还原度”的原则。为什么是这个原则，因为语义不变性保证了反编译的代码不会出现程序逻辑上的问题，也就是说，保留程序的等价性，任何输入都能得到同样的输出，出现语义错误在反编译技术领域被视为 不可接受的； 代码可读性需要建立在语义不变性的基础上，更易于人工的阅读和分析； 而代码还原度便是反编译代码与源代码相似程度。
1、Test1
第一个测试中，我设计了循环头和锁节点都为二路条件循环结构，为了测试循环结构化分析能力，我多嵌套了几个if语句(代码标号为基本块号)。程序简单如下：
后面两个图是我做的一张粗略的控制流图，通过android sdk将这段代码生成apk文件后，用Jeb、GDA、Jadx来反编译，并进行代码可读性和语义准确性上进行对比。如下图：
通过对比可以看出，Jeb的还原能力是最差的，其代码可读性比较差，且发生了语义错误，甚至在面对此种循环结构时，还出现了块儿的丢失且多了3个continue。此外还可以看出，JEB反编译对于label的处理是在高级代码输出之后处理的，在做goto-label分析时将其去除，所以导致了空行的存在。
GDA看起来是最接近源代码的，且保持了语义的准确性，并且识别出了符号。
Jadx代码可读性更好，同时反编译后语义和源代码保持了一致，并且对级联的if-else语句做了优化，但已不再是源代码的样子。
该测试案例在Test1的基础上仅仅多一条语句，其结果是在循环内的第一个if-else结构之后加了一个后随节点，源代码如下：
编译成为apk后，我们使用JEB、GDA、Jadx来反编译看看效果。
同样GDA几乎做了完美的复原；JEB将其识别为了for类型循环，同样丢失了退出循环的基本块儿(语句a=a*5)，导致语义发生错误。Jadx同样也高度的还原了代码，且保持语义的正确性。
接下来我们来看看他们对双层循环的结构化分析的能力。我设计一个双层循环，使内层循环break出外层循环，实际上基本块5不仅会是内存循环的锁节点，也会是外层循环的锁节点。并且该锁节点为二路条件节点，其一个分支路径回到内层循环，另外一个分支结构回到外层循环。一般对循环结构算法都是循环头-锁节点一一对应，因此处理过程中可能会复杂化该类结构。代码实现非常简单如下：
编译成apk后，再反编译后可以看出GDA反编译的代码，外层循环并没识别出来，但是保持了语义的正确性；
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
|
|
|---|---|
|
|
|
|
|
对，jadx的作者的确是这么说的，这一点我纠正一下。
最后于 2019-6-26 14:31
被gjden编辑
，原因：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
学界从未说过finally难吧，finally不就是个try-catch的后随么，难在哪儿了？反而解决非结构化问题才是难点，尤其是带循环的非结构化问题 |
|
|
国人终于有拿得出手的反编译器了，@hackevil  ，之前被你莫名的鄙视了
|
|
|
不会吧，这么小心眼，还记得 |
|
|
当然，不要嘲笑菜鸟，尤其是女菜鸟 
|
|
|
|
|
|
|
|
|
|
|
|
这是啥表情 
|
|
|
版主牛逼，文章没有什么花哨的东西，直击编译器的要害，学界泰斗啊，感谢付出与分享！
|
|
|
|
|
|
|
|
|
学界泰斗，这个帽子有点重，扛不动的。 |
|
|
|
|
|
编译器的优化可能会导致某些基本块移动，或者一些表达式的消失，想要完全还原代码，理论上也是不可能的，但是部分函数是可以完全还原的。 |
|
|
(Sorry, my Mandarin is not good enough for me to write an answer in chinese, so I'll type it in English. I hope you don't mind!)
I wanted to give my very different opinion about decompilation results. It seems the author did use an older version of JEB, because I have different results, and in my opinion, they are either as good as JADX or GDA. Our company pays for JEB Pro, we always use the latest beta version, currently a 3.6 Beta July 2019. - 1) JEB has discarded x*5 on purpose, since that variable is deemed useless after assignment. (In fact, JEB's deobfuscation capabilities are one of its great strength, as I'll show later)  - 2) OK  - 3) OK  - 4) OK  5) Here, we do have goto, but JEB provides semantically correct results, where the other two tools, eager to avoid gotos, generate wrong results! Something much worse when reversing is done professionally, with various clients expecting accurate information about the whats and hows of a piece of malware.
 - (De)Obfuscation - Now, let's go one step further and perform simple obfuscation of method test1 (Attaching the dex file) jadx crashes; gda: not tested, unfortunately.  JEB cleans up and decompiles the code almost perfectly: see below (it looks like the obfuscator has inserted a large amount of trampoline and junk code)  It is unfortunate that the original poster seemed to be biased against JEB. I talked to lots of people at conferences and events and it seems almost all companies and research labs doing serious business on the Android security side, at least, use JEB. All that being said, and in my experience, JEB outperforms all other static analysis tools (_except_ IDA when it comes to arm code analysis) in almost all domains: coverage (full APK support, including obfuscated resources, but also native processors and non-native processors), decompilation, debugging. Not to mention it supports refactioring and cross-references with virtuals and overrides, and has a full API to automate pretty much everything. IDA is really the only real competitor to JEB when it comes to x86 and arm, and HexRays decompiler in that regards still outperform JEB generally. We have examined complicated x86 malware where JEB was doing a better job at deobfuscating the code. Sorry again for writing in English, I hope that's okay. I'm sometimes browsing pediy because it contains interesting articles, but I rarely post, my Chinese is not good enough for lengthy messages. (Disclaimer: we use JEB everyday at our for-profit security company, and so we pay for it and to have the latest version at all times. We do Android malware reversing, Windows malware reversing, Ethereum contracts reversing. We love the tool and the support from the PNF Software guys, so obviously our opinion may be a little bit skewed!)
|
|
|
首先要明确的是本文并没有否定jeb也对其没有偏见，每个工具都有他的优缺点，就连优秀的苹果系统也很多人吐槽难用。本人也是非常喜欢JEB，只是本文内容限制在对循环结构的还原上，专门针对的是结构化算法的测试，并没有对比其他方面。文中也提及相应的观点，第一段：" 应该说 JEB 主要槽点是昂贵的费用，其采用的结构化分析技术的确属于比较落后的，但是JEB的功能比jadx更为丰富，更有利于做逆向分析 ", 并在文末也说了：“ 当然本次测试的情况属于极端一点的测试，一般情况下，JEB的循环识别也非常不错 ” 。看你也在论坛混了很长时间，应该是能看懂中文，我这里就不费劲儿翻译成英文了。 然后正式回复： 仔细看了你的回答，你可能使用的是最新版本，所以反编译效果有较大的改善，但是仍然有丢失基本块的bug. 对于test1，你的辩解完全不对："JEB has discarded x*5 on purpose, since that variable is deemed useless after assignment",你认为是因为变量a(v1)分配值(a=Math.getExponent(88))之后后被jeb视为无效，这是不正确的，a(v1)的值是由method的返回值决定，jeb不会去做预判，jeb的问题仍然是结构化算法的问题，所以导致了(a=a*5)语句丢失，实际上是整个基本块的丢失。一个简单的测试就可以证明，我把a的值初始化为能够覆盖>100这个路径，并且给该基本块多加几条语句，jeb仍然将该基本块弄丢失了。test2中也一样，会出现丢失块的情况。 test1改后的源代码： super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
int a = 200;
int y = 0;
while(y<100){
if(a<=0){
a=a+1;
y=y+1;
}else{
if(a>10){
if(a>100){
a=a*5;
a=a&0xff;
break;
}else{
y=y/a;
}
}
}
}
this.attachBaseContext(this);三款工具反编译结果：从结果来看，jeb依然丢失了这个块，这次是两条语句。  图中第二个图的篮筐里就是jeb丢失的块。 然后是你认为反编译ok的后几个test，本文目的不是测试反编译器是否能够反编译，而是测试反编译器的还原能力。 最后对于反混淆这一块儿，jeb的确做得很好，不过这完全是反编译器的兼容性和稳定性决定的，这靠的是完备的测试案例(如大量的采用不同反混淆手段的apk)以及使用者的错误反馈，最后做出相应改进，这一块儿商业的jeb本应具备的，不过最本质上和反编译器的核心算法关系不大。就你给出的例子，jeb只是考虑处理了这种垃圾指令或者那些控制流图上不可达的基本块，这种情况我也遇到过很多，也在GDA中加入了相应的处理。最后，也希望Jeb能改进优化。 |
，多有得罪
