新年第一帖!
年初做了道很有意思的代码混淆题crackme_pls，自闭了一个多星期后终于想出了相对比较好的去混淆方法，在这里给大伙分享一下分析思路。
题目附件和源代码：https://github.com/lkmidas/MyCTFPublic/tree/main/tetctf2022/crackme_pls

以main函数为例，这题的控制流图是这样的（IDA识别函数范围有误，需要手动修复一下）：

为啥说是魔改的控制流平坦化呢？因为这个混淆从分发块到真实块之间是间接跳转，因此更难处理。

所有的字符串常量都已经被加密了，运行时在init()函数中解密，但这个混淆其实对我们分析程序的干扰不大，动调一下就能拿到解密后的字符串：

所有的函数调用都变成了间接调用，IDA无法识别函数的真实地址：


这一坨看起来奇奇怪怪的式子实际上就是函数表的地址加上一个偏移，然后从这个地址取出函数的真实地址，40CAA0就是函数表的地址，之所以看起来这么“奇怪，是因为加法运算经过了MBA表达式替换混淆。
复原MBA表达式确实很困难，但实际上我们并不需要复原MBA表达式，直接动态调试就能拿到函数的真实地址，符号执行、手动计算也是OK的。还有个WP说Ghirda和Binary Ninja能识别出函数的真实地址在函数表中的位置，我用Binary Ninja试了一下确实可以，还是挺香的：

IDA在main函数下断点动调，然后就能在函数表中找到对应的真实地址，比如这里其实是调用了fork函数，在Binary Ninja中把函数名改掉，代码的可读性就很高了：


所以去混淆的关键是恢复被平坦化的控制流。

这题是控制流平坦化变体，所以函数被混淆后的结构和去混淆方法其实和控制流平坦化是有异曲同工之妙的，关于怎么去普通的控制流平坦化，可以参考一下两篇文章：

参考WP：

所谓知己知彼才能百战百胜，首先我们来研究下函数被混淆的结构。总体来说跟控制流平坦化是很像的，因此我们可以把控制流平坦化的结构图拿来作为参考，对这道题的CFG进行划分，还是以main函数为例：


这个划分规则暂时还是非常适用的（注意，只是暂时适用，一个小伏笔）。
完整的过程是每个真实块执行完毕后都会返回预分发块，预分发块返回主分发块，再由主分发块经过若干个自分发块到达下一个真实块，和控制流平坦化是一样的，只不过跳转方式由直接跳转变成了间接跳转。

这题跟控制流平坦化很像，那么能不能直接套用控制流平坦化的去混淆思路呢？答案是不能，主要有两点原因：

但是这两个问题也是我们不得不面对的问题，因为要恢复控制流就得找到真实块之间的跳转关系，要找到真实块就得拿到函数的CFG。既然常规的思路没法结果，那我们就发挥才智想出一些新的方法来，解决方案如下：

既然angr的“正规”手段分析不出函数CFG，那么我们就用一些“野蛮”手段来生成一个简易的CFG。
首先定义一个叫做SuperBlock的类，表示一个IDA-like的基本块，跟angr-management中的SuperCFGNode很相似，这里重新定义一个是为了方便后续处理：

接下来怎么分析出一个函数中的所有SuperNode呢，方法很简单粗暴：

我写了一个FunctionCFG来表示函数的CFG，这个简易CFG存储了函数的所有SuperNode，但没有保存基本块之间的跳转关系：

来测试一下用这种方法分析CFG的效果：

输出，经过检验结果是正确的：

至此，我们已经拿到了函数的全部基本块。

在控制流平坦化的去混淆中，我们可以通过基本块的前驱块和后继块来识别哪些是真实块，但在上一步中我们仅仅是得到了函数的所有基本块，而没有识别基本块之间的跳转关系，所以传统的方法行不通。
但仍然有很简单粗暴的方法来识别哪些是真实块：

代码如下，main函数中还没有出现call exit，所以其实可以先忽略这种情况：

其中useless_blocks即无用块包括主分发块、子分发块以及预分发块，这些基本块是没有用的，之后都要被nop掉，所以顺便也收集起来。
打印一下结果：

输出，也是完全正确的：

之前提到了不能直接通过符号执行找到真实块的后继真实块，那么就从函数入口点开始符号执行，explore到当前的真实块，然后继续符号执行找到下一个真实块？这种方法或许可行，但是速度肯定很慢。我们可以用另一个方法曲线救国。
通过分析汇编我们发现程序在分发块中的执行路径其实是由eax这个寄存器决定的，也就是每一个真实块对应了一个固定的值，只要程序在主分发块时eax的值等于该分发块对应的值，那么程序接下来就会到达这个真实块：

那么怎么找到每个真实块对应的eax值呢？最简单的方法肯定是符号执行。我的思路是：

代码实现如下：

输出：

如何得到真实块的后继真实块呢？只需要知道真实块执行完毕后eax的值即可，有两个方法：一个是符号执行，另外一个是正则匹配。一开始我用的是符号执行的方法，但后来在处理其他函数的时候我发现符号执行处理不了一些特殊情况，无奈只能改成正则匹配了。
正则匹配的方法如下：

通过正则匹配可以识别出哪些真实块是绝对跳转，哪些真实块是条件跳转，同时也能得到后继块的key，进而通过k2n_map得到跳转的地址。条件跳转的类型其实就是cmov指令的类型（例如cmovnz对应jnz）。如此以来便可以得到真实块之间的跳转关系。

通过正则匹配得到了真实块之间的跳转关系之后就可以直接patch了，代码实现如下：

首先丢进虚拟机跑一下确定没有爆炸：

IDA中查看，控制流已经恢复：

Binary Ninja查看，恢复一下函数符号和字符串，代码的逻辑就很清晰了：

在复原后的main函数中我们可以看到子进程读取了60个字节的输入之后调用了child_func函数，接下来我们来看看如何复原child_func函数。

还是先来看看混淆结构：

乍一看好像变成两层的控制流平坦化了？仔细分析发现原来是有几个基本块“特立独行”，它们的末尾是直接跳转，但没有像正常真实块那样跳转到预分发块，而是直接跳到了另外一个真实块：

至于为什么会出现这种特立独行的基本块，根据题目的源代码来看，应该是因为编译器的神奇优化，将这几个异或操作之后的赋值操作合并到一个基本块中了（也即是402AA0中的mov [rax], cl指令）:

对于这几个特立独行的基本块，我们在分析时仍然将其当做真实块，但不要对它的跳转进行Patch。v1版本的去混淆脚本仍然适用，因为这几个基本块中没有mov eax, xxx指令，也就会被认为没有后继真实块，自然不会被Patch。

还是先运行一下，确定没有爆炸：

拖进IDA查看，基本是正常的：

用Biary Ninja复原一下函数调用，ptrace表明有父进程调试子进程的操作：

中间的一大坨循环暂且跳过，再看看最后的函数调用：

中间的循环Binary Ninja的反汇编效果不是很好，所以还是用IDA看，结合最后的函数调用可以看出是一个解密ELF文件然后执行的操作：

加密后的ELF前四个字节与输入的前四个字节异或，要得到合法的ELF头0x7F和ELF三个字符。于是得到了输入的前四个字符：

动态调试把解密后的 ELF dump下来，因为这个帖主要是讲去混淆，所以这部分就不细说了。

这题最难搞的函数，首先还是来看看CFG，基本块展开成了4层：

决定接下来要跳转到哪个真实块的关键寄存器变成了ecx：

第一层基本块都是真实块，直接跳转到预分发块：

第二层基本块都跳转到了第一层的两个基本块之一，并且两个基本块没有mov ecx, xxx指令，也就是说接下来要跳转到哪个真实块实际上是由第二层的基本块自己决定的：

这样就导致了patch工作非常困难，显然不能在标红框的两个基本块中patch跳转，因为后继真实块不是由它们决定的；但如果让第二层的基本块直接跳转到后继真实块，又会漏掉第一层基本块的一些指令，导致程序出错。
我没有想到更好的解决办法，只能牺牲掉一些准确性保全大局，如果你有更好的主意欢迎交流讨论。
再看到第三层基本块，都跳转到了第二层基本块中的三个之一：

第四层的情况也差不多：

这里还有两个以call exit结尾的基本块，很容易看出来，这两个基本块我们待会也要作为特殊情况考虑进去：

因为关键寄存器变成了ecx，所以这里要改为：

另外虽然关键寄存器变成了ecx，实际上是预分发块中有一条指令mov eax, ecx，子分发块还是根据eax来跳转的：

所以处理一下序言块到第一个真实块的特殊情况：

然后来处理一下这种情况，mov ecx, xxx和mov eax, xxx以及cmovxx ecx, eax不在同一个基本块中：

那么我们需要在修复控制流时加上一种情况，如果在当前基本块发现了mov ecx, xxx和mov eax, xxx但是没有发现cmovxx ecx, eax指令，就往它的直接后继基本块继续搜索：

接下来处理两个以call exit结尾的基本块：

手动记录一下两条call exit指令的地址，在分析SuperBlock时把这两个地址也考虑进去：

本来我以为这样就搞定了，但接下来我又发现了新的问题，在输出的日志中我发现有些应该有后继真实块的基本块却找不到后继真实块，例如：

很明显loc_403C20的后继真实块应该是326BF726h和1594BB6Ah对应的基本块，而我们在恢复跳转关系的时候却找不到后继块，这是因为我们根本没有找到0x326BF726对应的真实块，真是奇了怪了：

如果在主分发块处将eax设为claripy.BVV(0x326BF726, 32)开始符号执行，会发现它在返回预分发块之前到达了0x403230基本块：


这个基本块跟其它子分发块有点相似，但是有不完全相同，体现在它多出了一些指令，这些指令实际上本来应该是0x326BF726对应的真实块，貌似又是编译器神奇优化的锅：

除了0x403230之外，后续还发现了一些这样的基本块，总共有三个，分别对应326BF726h、3311C734h和703837C4h：


把这三个“小霸王”也考虑进去：

这时修复控制流的结果就正常了。

运行爆炸了，在意料之中：

IDA打开看看，控制流恢复得还是挺不错的：

Binary Ninja查看代码可读性还是很高的，就是漏了一些地方：

与源代码对比：

这题的加密逻辑有点复杂，是一个父进程调试子进程的模式，还有其他ELF释放，所以我也没继续分析下去了，感兴趣的可以看看上面贴的WP或者题目的源代码。
至于剩下几个被混淆的函数就比较简单了，跟main函数类似，用v1版本的去混淆脚本能够通杀，所以这里不再赘述。v2版本的代码相当于是在v1的基础上缝缝补补了一些东西，很不优雅，如果大家有更巧妙的思路欢迎交流讨论。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！