最近团队准备招新人，刚好碰到个样本比较简单，于是就充当面试题考验一下新人的逆向基础功底{没等到考验新人，那家伙竟然直接在第一面就被刷掉了，略失望}，特此记录。

如下图所示，测验样本一共有三个，它们是从某个rtf漏洞文档释放出来的payload。启动程序googleupdate. exe是一个具有正常数字签名的谷歌官方程序，当然不会是恶意程序。看同目录下的dll文件名很容易猜到其将被googleupdate. exe加载进行白利用，之后可能会加载第三个xml文件进一步干活。这样做的目的主要就是为了对抗杀软，而且恶意dll文件的静态特征很少(见下文主函数便知)，主要代码都被加密了，能够比较容易地躲避杀软查杀。本文主要考验新人对该dll在内存中解密恶意代码的理解和调试能力。

既然dll会被加载，那就先试试用最土的办法来调试它——修改入口点下断。首先，需要设置一下实时调试器选项，以让系统能够检测程序运行过程中的异常并调用调试器进行接管：

然后，先定位dll的程序入口点，准备修改其入口点代码。这里使用IDA查看其入口点特征：

然后在十六进制编辑器中搜索入口点的十六进制特征，并修改第三个字节"55"，也就是对应入口点第二条指令"push ebp"，改成"CC"，即"int 3"断点：

保存修改后的dll文件，然后点击googleupdate. exe运行，发现程序并没有发生预想中的崩溃调试窗口。猜测原因是被googleupdate. exe里设置的异常处理函数给接收了，这样就不会直接把断点异常抛给系统处理。于是采用另一种办法，直接在调试器里载入googleupdate. exe，然后F9直接运行起来，由于默认设置会捕获"int 3"异常断点，所以调试器成功在dll入口点处中断：

这里，我们就可以查看栈区，观察函数调用，找到最近一次googleupdate. exe调用dll的方式和地址：

验证一下上面找到的地址，重载程序运行，发现程序确实在该地址调用了"LoadLibraryExW"来加载同目录下的goopdate.dll文件：

所以我们对于这类场景的调试，我们也可以一开始就直接下断点"bp LoadLibraryExW"，或者加上"A"版断点，这样基本就可以捕获大部分正常的dll加载过程：

然后进行四次"Ctrl+F9"执行到返回操作：

此时查看内存模块，发现dll刚刚被加载到进程空间，而且还没有执行入口点代码，于是"F2"对dll映像的代码段进行一次性下断：

接着就"F9"让程序继续运行，等到其开始执行dll代码时，便会中断在其入口点：

之后就可以方便对该dll进行各种调试跟踪了，分析其程序流程。这里，切换IDA先进行快速的静态分析，发现dll主函数比较简单，主要就是在其刚加载到进程时先执行一个子函数"sub_30001000"，接着就进行一个远调用到"loc_30006250"，该地址不属于代码段，实际上是第二个段".idata"的地址范围(见上文内存映射图)：

于是判断真正的恶意代码可能保存在".idata"段，而子函数"sub_30001000"的功能是为该跳转做准备：

不难看出，该函数拼接了字符串".idata"，并遍历了节表以定位目标".idata"节的相关信息，接着对该节的数据进行解密，解密算法即简单的对0x17大小的每个数据块进行循环的异或和取反操作：

异或操作的"key"如下：

解密".idata"段代码后跳转到该段入口点：

最后，大概看一下解密后的代码，不难找到与加载xml文件有关的代码：

测验记录就先到这吧，毕竟只是简单的面试，一般已经足够看出新人的逆向水平了。样本这里就不贴了。