环境和工具

Windows7 7601
Ida7.5
Python3.8
qiling框架

简介

首先简单介绍一下数据流分析和活跃变量分析。活跃变量分析属于数据流分析的一种，编译器的许多优化都依赖于数据流分析。龙书的简介截图如下


活跃变量分析的用途有删除无用赋值和为基本块分配寄存器。vmp中的垃圾指令大部分都是些无用赋值，我们可以利用活跃变量分析来删除这些垃圾指令。

如上图所示。如果把test指令看作是对eflags寄存器的赋值，其中的test指令就属于无用赋值，因为eflags寄存器在当前指令被赋值之后没有被使用，在下一条指令又被重新赋值。0064D721处对ebp的赋值在0064D748之前也没有被使用，也是一个无用赋值。

记录基本块

此次活跃变量分析仅局限于合并直接跳转后的基本块内，不做全局的数据流分析，可以不用添加前驱和后继，相当于做局部优化。本次使用的样本是vmp3.5版本加的壳，只点了虚拟化，没有做其它的处理，这个样本的源码在vmprotect3.5安装目录下Example\Code Markers\MSVC。以去除vmp1段中的垃圾代码为例，也就是加壳后程序入口点处的那部分虚拟机代码。由于vmp3.5展开了dispatch结构，并且利用间接跳转干扰静态分析工具的控制流重建。比如vmp使用大量的jmp register和push register; ret;等指令。为了构建控制流，我使用qiling框架来模拟执行来记录这类指令的跳转目标。qiling实现了一个pe加载器且模拟了部分系统api。经过验证，是可以运行到原程序的入口点。有两个api需要自己添加模拟，GetProcessAffinityMask和SetThreadAffinityMask。模拟的代码如下：

然后利用qiling的hook_code的回调函数来跟踪指令的走向，记录所需的跳转信息。回调函数的部分代码如下：

由于qiling框架模拟执行的有点慢，所以模拟到入口点结束后就把获取到的信息通过json序列化保存到了文件中。代码和文件我都会上传，这里就不用一一展开了。获取到信息后，就要记录所有的基本块。大体思路是以入口点的代码为一个作为一个新的基本块的开始，然后不断的把后续指令加进去，直到碰到一个无条件跳转、条件跳转指令或其目的地址的指令为止。具体实现是从入口点开始扫描每一条指令，把push imm; call imm;当作直接跳转，不分析直接跳转后面的指令，继续从直接跳转的目的地址开始分析。需要注意的是push register;ret;和jmp register需要看成是含有多个分支的跳转。然后利用一个队列来保存待分析的基本块首地址，代码实现如下：

执行完后发现有7000多个这样的块，所以需要合并一下那些直接跳转的块，也方便之后做活跃变量分析。合并和添加前驱和后继的代码就不展示了，具体参考源码中的AddVMPBasicBlockPrevsAndSuccs和TryMergeBasicBlock两个函数。

活跃变量分析

合并基本块后就可以做活跃变量分析了，在和合并后基本块内做活跃变量分析可以把每一条指令看作是一个结点，寄存器看作一个变量，然后利用使用和定值信息计算进入结点和结点后的活跃信息。这里给出《现代编译原理-C语言描述》第10章活跃分析的一个例子，方便大家理解使用、定值和活跃性。

活跃性计算的方法如下：

按照上述方法计算后，会得到每一个结点的入口活跃信息和出口活跃信息。考虑到合并后的基本块有1700多个，如果按照上面的迭代方法计算的话会很慢，所以具体实现要优化一下，加快数据流分析。基本块内指令是线性执行的，不存在环和分支，活跃变量分析属于逆向数据流问题。如果能够安排每一个结点的计算都先于它的前驱，是可以通过对所有结点的一次遍历就能完成数据流分析，得到每一个结点的入口活跃和出口活跃信息。获取基本块内每一个指令的use和def信息的话，可以使用capstone CsInsn类的regs_access方法，这还可以获取到eflags寄存器。一开始是想使用ida的microcode API来实现的，但是我觉得ida提供的python接口不好用，没有提供针对一条指令的转换接口。
对合并后的基本块的分析思路如下：
1、首先利用capstone反汇编基本块内的指令，获取每一条指令的use和def信息。
2、从基本块的出口处的指令向入口计算每一条指令的出口活跃信息和入口活跃信息。
3、在获取到指令的活跃信息后，然后根据每一条指令的def信息，如果def中的所有变量都不属于出口活跃的，我们就可以删掉这条指令。
具体代码实现如下：

这里有几点需要说明一下，capstone的al，ah，ax等8位或16位的寄存器是单独定义的，需要转换到32位，因为vmp有8位或16位寄存器参与到下一个handle地址的运算。或者也可以把这些寄存器添加到In[Exit]中，添加In[Exit]是为了方便计算，作为整个基本块的出口活跃信息，不属于任意一条指令。把一些通用寄存器添加到基本块的出口活跃信息，也是为了保证不会nop掉有用的指令。那个IsRadical的判断主要是为了处理push imm；call target中target处的虚拟机入口。只添加ebp，esp，esi和edi作为整个基本块出口活跃信息是为了减少target处基本块没有nop掉的垃圾指令。在nop掉指令前，需要注意的是，编译器在删除死代码的优化中会考虑到当前被删除的指令是否有副作用，比如是否为访存指令、call指令等。本次样本中vmp的垃圾指令好像都没有副作用，不存在那些有副作用的指令，所以就没有考虑这些，nop完之后样本是可以正常运行的。最后在处理以下垃圾指令，直接遍历每一个基本块遇到这类指令直接nop掉。

这里展示一下入口处进入虚拟机那部分nop掉垃圾指令后的代码和部分x64dbg的trace截图

总结

根据实际运行效果，说明我的分析思路是大体正确的。这里没有根据基本块作为一个结点做全局的活跃变量分析是因为把通用寄存器作为活跃分析中的变量是不适合这么做的。因为通用寄存器的数量有限，是重复使用的资源，其活跃性很容易在下一个基本块被杀死。要做全局的活跃变量分析的话，应先把整个流图转换到SSA形式，这样应该可以干掉那些漏网之鱼了。考虑到工作量有点大，就没有这么做了。上传的源码中我也实现了一个获取合并后基本块的出口活跃和入口活跃信息的函数，不是SSA形式的。只是写来巩固一下自己所学知识点而已，对去除垃圾指令也没什么作用，大家有兴趣的话可以参考一下。也没有使用迭代的方法，而是做了一部分优化，通过工作表算法和对结点的深度优先搜索遍历序号进行计算的。代码实现在GlobalLiveness函数中。优化方法可以参考《现代编译原理-C语言描述》17章的加快数据流分析部分

[公告]名企招聘！