正在下载：goopdate_idb.zip 白利用木马分析记录
如下图所示，测验样本一共有三个，它们是从某个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文件有关的代码：
测验记录就先到这吧，毕竟只是简单的面试，一般已经足够看出新人的逆向水平了。样本这里就不贴了。