先从一个简单的函数开始

直接正常编译，ida cfg如下

如果用ollvm加上fla（这里为了简单说明问题，只加fla，加了其他混淆并不改变反混淆的原理）

可以看到，加入了很多小块，而原来真正跟原程序相关的块，这里已经用浅蓝色标出，先来看看这样子直接F5的结果。

可以看到原来非常直接的顺序执行逻辑，现在变成非常不直观的平坦化逻辑，每一个真实逻辑执行完，无法直观地知道下一个真正要执行的地方是哪里。造成这种效果的罪魁祸首就是加上去的小块.

观察一下一个真实块的逻辑

这个块对应的是原程序a变量与5比较的逻辑，只不过做完a跟5的比较判断之后，将一个很大的数字mov到R0寄存器.

继续看看这个块的目的地loc_738所做的事情。

这个块做的事情只有一个，根据之前的真实块（loc_70E）mov到R0的结果，决定需要跳转到哪个块。中间可能经过其他白色块的中转，但是最终的结果肯定是另外一个真实块。 这类混淆的基本运行逻辑逻辑是[真实块]->[控制块(0到n个)]->[下一个真实块]->[控制块(0到n个)]->[下一个真实块].....

再去认真观察蓝色的真实块的特征，可以发现，所有真实块的输入，都与那些ollvm加入的分发控制块无关，比如，loc_70E的输入是var_20这个变量，与所有白色控制块所读写的寄存器无关。

基于上述观察可得，fla加入的所有白色控制块，与原程序的真实逻辑并没有任何关系，在混淆中只充当一个决定下一个真实块的分发控制作用，如果我们知道真实块的前后关系，可以把他们直接连接起来，跳过所有白色的控制块，我们的程序依然是正确的,程序的逻辑也变得直观多了。

于是我们反混淆需要解决以下几个问题

观察白色的块，其实特征非常明显，非常短(只有几条指令)，仅仅只有寄存器的操作，而没有内存操作，最后都是cmp+跳转等等，这个不同厂商的混淆有细微的差别，但多数都特征非常明显，可以直接静态分析出来，在反混淆程序设计上，为了隔离这种差别引起的复杂性，可以用多态隔离掉就可以了。确定所有控制块后，直接用0清除这些块里面所有指令，免得干扰ida分析，因为修复成功后，所有真实块都不会经过这些控制块了。

单从静态分析去确定真实块的关系非常浪费时间，这里可以采取两种方法

这种方法优点是借用成熟的调试工具，无需模拟环境，上手简单，缺点是如果程序有反调试，需要先将反调试干掉。这里需要借助一下idapython脚本。链接

脚本的原理非常简单，在待trace函数每一条指令都下一个断点，并将断点属性改为BPT_TRACE,这样断点不会停下来，但会触发原先设置好的回调函数，在回调函数中，可以将运行指令的地址等所有信息记录下来。最后得出含有这种内容一个trace文件。

利用模拟执行直接执行目标函数，也可以达到每条指令都记录下来的效果，优点是无视反调试(但也有可能遇到对抗)，缺点是需要准备好模拟环境，实现一些系统调用以及java函数等等，操作比较麻烦，对于android环境的模拟，开源界已经存在一些优秀项目如AndroidNativeEmu,但由于该项目存在一些bug和一些未实现的系统调用，我拿来做了些改进参见这里

无论用那种方式,我们都可以得出一个记录所有执行指令的trace文件，有了这个文件我们就可以知道真实块的前后顺序了，方法如下

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课