揭开病毒的面纱–恶意代码自解密技术

分析病毒的时候，常常遇到一种很奇怪的现象，使用查壳 工具 查看一个样本明明没有加壳，但是反编译或调试时，却不能直观地看到样本的恶意操作，这是为什么呢？很简单，这是因为攻击者采用了自定义的加密方法，在样本运行时实现自解密并执行真正的恶意操作，所以看到的只是样本还没解密的样子，自然分析不出恶意代码的逻辑。

下面就通过实例来窥探下恶意代码自解密的技术吧，如下是一个 Ammyy 病毒的下载器（ MD5 ： 28EAE907EA38B050CBDCC82BB623C00A ），使用 DIE 查壳发现，该样本并没有加任何的壳。

然而当查找字符串时，却未能发现一些可疑的字符串（如下载器常有的恶意 url ），看到的只是一堆乱码，看来，该样本很有可能就是使用了自解密的技术。

反编译该样本，也难以看出它的代码逻辑，很多动态地址的 call 。

对于这种样本，反编译器很难看到一些重要的操作，因为大部分都是解密操作，所以只能通过调试器单步调了。单步调试没啥好技巧，遇到跑飞的 call 下断点然后重新调试。调试的时候，要注意 VirtualAlloc 、 GlobalAlloc 、 HeapCreate 这些函数，因为恶意代码通常使用这些函数来申请一段内存空间，来存放解密出来的恶意代码。如下图，该样本调用的是 HeapCreate 创建了 0x230000 这段内存。

接着恶意代码用了 je + retn 的方式循环解密 0x230000 处的数据。

解密完毕后，恶意代码调用 call esi 将执行流从 0x40XXXX 转到 0x230000 。

然而， 0x230000 处的代码并不执行核心的恶意操作，目的在于修改 0x40XXXX 处的原始代码。如下，它会调用 VirtualProtect 将 0x400000 的内存属性改为 RW （读写），进而修改原来的代码。

修改后的 0x400000 内存段的属性如下。

修改完代码，调用 jmp esi 跳回到 0x40XXXX 进行执行，此时，这段内存的代码已经被修改过了，终于开始执行核心的恶意操作了。

将内存 dump 下来发现，现在的代码已经是解密后的恶意代码了，程序逻辑清晰可见，通过字符串查找可以找到待下载的病毒的 url 。

至此，该下载器的功能已经分析完毕，主要功能为从 http://thespecsupportservice.com/load.png 下载 Ammyy 病毒并运行。

由此，可以总结得出，恶意代码自解密的步骤一般为以下 5 步：申请内存 -> 复制数据 -> 解密数据 -> 跳转到堆中执行恶意代码 -> 修改原始代码并跳回执行。不过，我们可能会有个疑惑，病毒为什么不直接在堆中执行核心的恶意操作呢，还要通过修改原始代码来在 0x400000 空间解密执行核心的恶意代码。这是因为，一些比较高级的沙箱、杀软会监控病毒创建大片内存空间的操作，这时一旦释放出解密代码，便会立刻被沙箱、杀软检测到，所以在堆中的代码一般不会只会直接进行核心的恶意操作。

了解了恶意代码自解密技术后，来看看最近流行的 GandCrab 勒索病毒（ MD5 ： 48A673157DA3940244CE0DFB3ECB58E9 ），使用的也是这种自解密技术，来实现免杀。使用 DIE 对样本进行检测，显示并未加壳。

自解密的手法跟上述提到的相似，在 0x1280000 处申请了一段内存空间。

堆中的代码负责修改原始代码并跳转回去执行。

跳转回来后， 0x403016 处的代码就是解密后的核心恶意代码，接下来就可以调试 GandCrab 的恶意代码了。

将内存 Dump 下来，也可以分析出加密文件的代码逻辑。

在 VT 上查询该病毒的报毒情况，只有大概半数的引擎报毒，而且报出的病毒类型大多不能定位到 Ransom ，看来， GandCrab 使用这种自解密的方式还是起到了一定的免杀效果。