记一次对Ghidra反编译的修复

问题

最开始发现问题是在逆Rust的时候，IDA 在逆Rust的时候一向有点问题，这次更是出现了分析出来 500 多个参数的情况，实在让人有点难受。于是我觉得尝试下ghidra ，但是打开发现，虽然没有了 500 多个参数，但是情况也好不了太多，出现了奇妙的情况：

相比之下IDA就没有这种奇怪的东西：

我找了半天，当时也没能发现 0x178a97 、0x178aa9 之类的玩意儿是从哪里来的，但是这肯定是个比较严重的问题，因为这基本让反编译没法看了。比赛期间没有办法，只能继续用IDA了。但是赛后这个问题是肯定要处理处理的。

反编译的原理

反编译基本都可分为这么几步：

基础准备

基础准备：一般就是由反汇编器 来完成的几个步骤，包括：

1. 加载镜像：将文件中的代码、数据分析出来，从而知道内存中某个地址对应文件中的什么数据。

2. 代码识别+反汇编+代码提升（lifting）：猜测哪些地方应该是机器代码，然后对机器代码进行解码得到汇编语言，同时还可以将汇编语言进行代码提升，也就是liting，得到中间语言 。之后的分析一般就发生在中间语言上，这样可以避免直接对不同架构的汇编代码进行处理，从而可以方便地支持多架构。

控制流图获取

控制流图获取：这部分开始就是反编译器的工作了（一般来说是）。首先就是需要进行控制流图的获取，控制流图是一种图结构，图上的每一个节点叫做一个基本块 ，也就是会连续执行的指令。例如以下的汇编程序：

mov eax, 1add ebx, eax ; 假设 ebx 是外部的输入cmp ebx, 0x10jne label1mov ebx, 0x20jmp endlabel1:mov ebx, 0x30end:xor eax, eax

这一段程序如果画成控制流图：

每一个基本块一旦进入就一定会执行到结尾。这样做之后，就会让分析更加方便，因为以前我们只能以一句汇编为一个单位进行分析，现在就可以一个基本块为一个单位进行分析了。另外，有了图的结构，也比较清晰的知道一个基本块之后可以走到什么分支了。最后的控制流恢复也和这个步骤息息相关。

SSA 生成

SSA，Static Single Assignment，中文叫做静态单赋值，是说，每一个变量都只应该被赋值一次（只写入一次）。怎么做到呢？就是将变量进行改名，例如eax被写了两次，那么第一次写入，假设是 mov eax, 1 就可以表示为eax_0 = 1 ，第二次用到的eax，假设是add eax, 1 就会表示为eax_1 = eax_0 + 1 这样，一看到eax_1就知道是第二个，不会是第一个了。

但是如果出现分支，就会有一点问题，例如这样的程序：

cmp ebx, 100jne L1mov eax, 1jmp endL1:mov eax, 2end:add ebx, eax

如果重新命名

if ebx_0 != 100 then jmp L1eax_1 = 1jmp endL1:eax_2 = 2end:ebx_1 = ? ; 这里出现了问题，应该是 eax_1 还是 eax_2？

所以在SSA里边，我们会加入一个特殊的语句，叫做phi，有时候也叫做phi-node（phi 节点），他的作用就是将分支导致的多个变量进行合并，例如上面的程序就可以被写作：

if ebx_0 != 100 then jmp L1eax_1 = 1jmp endL1:eax_2 = 2end:eax_3 = phi(eax_1, eax_2)ebx_1 = eax_3

SSA的目的是让分析更加高效便捷，因为在分析的时候，你用到的变量都可以很清楚的知道是由哪一条语句进行定义的，而不需要往前挨个去找（因为只有一条语句可以定义，所以就很清楚是哪一条，就不需要全部找一遍才能确认）。

变量恢复

即，将变量进行分析恢复，这也是本次Bug的修复重点。变量分为多种可能，包括栈上的变量、寄存器里的变量等等。栈上的变量目前所使用的方法一般是找到栈指针，查看其在函数内开辟了多少空间（加、减了多大的偏移），然后对于用到这一段空间的认为是可能的变量。

类型恢复

在变量恢复之后，会进行类型恢复，也就是“猜”恢复出来的变量可能是什么类型，如果实在猜不出来，就猜一个大小，这个大小可以根据是怎么使用的来确定。例如：加载一个位于rsp + 0x30的 8 个字节，就会认为这个位置所对应的变量的大小是 8 个字节。至于是指针还是整数还是浮点数，这就需要利用后续对这个变量的其他使用方式来确定了。

控制流恢复

即，将控制流图打上标记，确认控制流图所对应的程序结构，例如在上面控制流图示例中所对应的就应该是 if-else语句。

这一部分一般是通过图匹配算法来实现的，也就是根据图长什么样子来确定是什么语句。

AST 恢复

在控制流图打上标记之后，就可以进行AST（Abstract Syntax Tree，抽象语法树）恢复了。这一部分将基本块里的内容进行转换，转换成高级语言的形式，以及根据控制流恢复的结果，决定应该使用什么条件语句、循环语句等进行表达。

输出高级语言

最后就是将AST恢复的结果打印出来。就得到了我们看到的结果了。

Pcode

在了解ghidra的反编译之前，必须先了解ghidra的中间语言：p-code。和其他所有的中间语言一样，这个中间语言和MIPS之类的架构比较接近，指令数量不多。

总结一下pcode中的重点概念：

2. varnode：即pcode所使用的变量，varnode包含地址空间(Address Space)、偏移量、大小，三个属性。

3. opcode：操作符，基本和常见的类似，例如INT_ADD, INT_SUB, BRANCH，这里就不详细列举了，基本上看见名字也能猜出来是什么意思。不过需要注意的是，除了在ghidra中显示pcode时能看到的操作符以外，还有部分操作符是ghidra内部使用的，例如 MULTIEQUAL（phi指令），这一部分并不会显示在ghidra当中，只在反编译器内部使用。

Ghidra 的反编译引擎

反编译过程的具体步骤可以看coreaction.cc文件中的ActionDatabase::universalAction，其中定义了反编译的步骤，在ghidra的反编译引擎中，每一个操作被定义为一个Action，一个函数的数据记录在Funcdata中，一个Action一般就是对Funcdata中的数据进行操作。除此以外，还有一系列优化效果的规则，定义为Rule，一个Rule会在特定的IR指令上进行操作，对IR进行修改。

由于反编译引擎内容比较多，没有办法在这里彻底解决，我们就在后续的调试步骤中去讲解所需要利用到的代码啦。

调试环境准备

        {             "type": "java",             "name": "Launch Ghidra",             "request": "launch",             "projectName": "Framework Utility",             "mainClass": "ghidra.GhidraLauncher",             "vmArgs": "-Djava.system.class.loader=ghidra.GhidraClassLoader -DbinaryPath=build/classes/java/main:build/resources/main/:bin/default/::src/main/resources/",             "classPaths": ["${workspaceFolder}\Ghidra\Framework\Utility\build\classes\java\main"],             "args": "ghidra.GhidraRun"         }

‍

这个配置需要添加在launch.json中的configurations里。主要是设置主类、vm参数、class路径还有启动时候的参数。这几点设置完之后就可以正常下断点啦。

编译的话，通过gradle classes可以进行编译，不要开vscode插件里的自动build ，虽然不知道为什么，但是我发现开了之后他会一直在build。（2019年我在开发的时候发现ghidra的gradle对license文件的处理，导致会有没办法缓存class的问题，不知道现在这个问题还存在不存在，说不定也是这个问题导致的）

所以基本的流程就是：

1. 修改java代码

2. 修改cpp代码

3. 跑gradle classes编译java层

4. 跑gradle buildNatives_win64或gradle buildNatives_linux64或gradle buildNatives_osx64编译C++层

5. 利用vscode或IDE 启动调试

不过这里说的是对java层开发的方式。

如果是C++层，还可以使用反编译器提供的命令行接口，事实上我在调试中更多的是使用的命令行接口，因为可以直接gdb。

命令行接口可以在cpp那个目录下，执行 make decomp_dbg 进行编译，得到一个decomp_dbg文件，打开之后会有一个decomp> 的提示符，就可以在这里输入命令了。注意这个功能目前看来应该只在linux上支持（倒不是说别的系统不能用，只是你可能需要处理一大堆依赖……感觉没这个必要，直接搞个虚拟机跑就好了）。

这个提示符的命令没什么文档，我是通过看代码了解用法的，当然还是有一些诡异的输出实在是看不懂。

代码位于consolemain.cc（main 函数，也定义了 load/save/restore几条命令）、ifacedecomp.hh/cc （反编译相关命令）。

然鹅，我用到的就只有：

• load file XXX XXX是路径，加载一个二进制文件

• load addr XXX XXX是地址，加载特定地址

• decompile进行反编译

• print C打印C出来。

不过，有命令行之后，就可以gdb跑起来了！还是可以的。

（和d8的调试体验相比，应该还是差很多的，后续可能我会加一些调试的功能，不然确实调起来不太方便）

开始调试！

好了！那么就让我们进入到正题！

第一步，当然是要处理下程序，不然这么大的Rust程序，该怎么调试呢？所以需要找到关键点，也就是到底是哪一步出现了这个问题。

所以我选择使用nasm自己写汇编代码，模拟出Rust程序上栈帧的处理，最后发现这样一个程序可以最小化的出现问题：

; test program for ghidra decompiler; nasm -felf64 test.S && ld test.o          global    _starttest_func:    ret          section   .text_start:    push rbp    mov rbp, rsp    push r15    push r14    push r13    push r12    push rbx    and rsp, -0x1000 ; 罪魁祸首！就它！    mov rax, 0x1c000    sub rsp, rax    mov rax, 1    mov qword [rsp + 0xa020], rax    mov qword [rsp + 0xa028], rax    lea r12, [rsp + 0xa020]    mov rdi, r12    mov esi, 0x1    call test_func    pop rbx    pop r12    pop r13    pop r14    pop r15    pop rbp    ret

其中最关键的就是一句and rsp, -0x1000，如果没有这一句，就完全分析正常。

对比下正常情况：

加了and之后：

int func() {  char uStackxx[1024];  stackVar = stackVarxxx & 0xfffffffffffff000;  // ...}

其中的uStackxx在程序中完全没有用到。

和正常程序对比调试了一下发现，在MapState::gatherVarnodes时，是没有检查到使用到的几个变量的，也就是说，使用到的几个变量没有被认为是在 spacebase （也就是栈）上。所以，没有出现open 的 RangeHint 和 varnode交叉的情况，从而并没有联系起来。

虽然这个点并不是我需要的点，但是在这一次调试之中，我发现了一个问题：其实第一次MapState::gatherVarnodes本来就没什么作用（将正常和不正常程序对比调试可以发现），到第二次的时候才出现的作用，也就是分析流程循环的第二轮，MapState::gatherVarnodes 才应当有作用。这就说明，并不一定是之前的action没能分析出来栈变量的问题，还可能是之后的action的问题。

所以，我将范围扩大到在heritage 、restructureVarnodes action之后，然后找到了相关的action ：RuleLoadVarnode和 RuleStoreVarnode。

这两个action（其实是Rule）应该就是分析的主要了，他们都会经过RuleLoadVarnode::checkSpacebase -> RuleLoadVarnode::vnSpacebase -> RuleLoadVarnode::correctSpacebase (ruleaction.cc) 的检查。调试发现，没能分析出来的变量所对应的 store/load在correctSpacebase的检查中失败了 。

所以问题应该就在这里了。失败的位置在于 !vn->isSpacebase 也就是这里判断出来了变量对应的varnode 没有被认为是栈变量。

在vnSpacebase中有检查，如果是CPUI_INT_ADD的code，会检查其define的op所对应的参数 0 是不是正确的Spacebase，这个值应该是rsp，是应该返回正常的，但是事实上这里的检查失败了，失败在vn->isInput() 这里，认为不是input。

这个isInput是什么意思呢？通过查看注释，可以发现这个判断是说这个 varnode 是不是 ssa 的 input node，也就是是不是在这个函数的“外面”给进来的。

断在heritage.cc:2163 也就是 Heritage::renameRecurse 里的循环获取到op = *oiter 之后，发现CPUI_INT_ADD 指令的时候，两个对比程序都是 isInput() == false ，这就说明后续其实应该有地方修改了isInput() 的结果，或者修改 inrefs （也就是 opcode 访问到的 varnode ）。

通过下watchpoint 查看inrefs 处的第一个元素，发现通过data.opSetInput 和 对应的clear input 设置了新的 input ，第一次设置的内容打印出来看（p vn->isInput() ）发现依然是 false ，直到第二次的时候才发现是 true 了，这个时候通过backtrace 查看到设置的函数是RuleAddMultCollapse ！

查看了一下，发现这个函数是用来做常量折叠的，然而他把涉及到栈指针的常量也折叠了，经过这个折叠之后，如果input 是栈指针+（或减）得到的，这个时候就会直接和栈指针搭上关系了，所以才会出现isInput() == true 。

到这里这个Bug的原因就找到了，是因为decompiler假设所有的栈指针相对访问经过常量折叠之后都会与栈指针直接相关，由于按位与运算的存在，导致常量折叠做不完了。然后因为SSA，所以除了第一个rsp被认为是栈指针，后面都是等着常量折叠过去的。结果一个and，折叠不过去了就断开了，后面的rsp就不认为是栈指针了。

解决问题

最后的解决其实并不算很完美，我自己添加了一个Rule ，将 AND 的其中一个值是spacebase （也就是会开辟一个子空间的，例如栈帧）的情况进行了处理，直接将对齐操作忽略掉了。

为了解决这个问题，我还对比了一下IDA的操作，发现IDA 虽然没有出这个问题，但是也好不到哪去。

IDA的结果：

多了一个莫名其妙的alloca出来。

另外：

看起来分析还是有点问题的，但是如果看栈空间就会发现，其实也是直接把and操作给忽略了，那么我这么改应该就问题不大啦。

最后的效果：

在Rust上运行的效果：

（还有好多问题，但是至少前面奇怪的保存返回地址的语句没了）

后记

Ghidra 虽然实现了类似 IDA的功能，但是从Bug情况来看，确实还有太多太多值得改进的地方。另外，ghidra 的官方对PR 、issue的反应并不算太快，似乎他们一直有自己内部的安排在做。想要达到和IDA匹敌的地步确实还有很长的路要走。

我们正在尝试对ghidra进行改进，后续可能以发行版（更快的 fix 、一些方便使用的插件、默认配置）的方式对ghidra进行再发布。

我们的代码已经开源在 [https://github.com/StarCrossPortal/bincraft ] ，欢迎大家保持关注~ 

本文始发于微信公众号（星阑科技）：记一次对Ghidra反编译的修复