分析病毒的時候，常常遇到一種很奇怪的現象，使用查殼工具查看一個樣本明明沒有加殼，但是反編譯或調試時，卻不能直觀地看到樣本的惡意操作，這是為什么呢？很簡單，這是因為攻擊者采用了自定義的加密方法，在樣本運行時實現自解密并執行真正的惡意操作，所以看到的只是樣本還沒解密的樣子，自然分析不出惡意代碼的邏輯。

下面就通過實例來窺探下惡意代碼自解密的技術吧，如下是一個Ammyy病毒的下載器（MD5：28EAE907EA38B050CBDCC82BB623C00A），使用DIE查殼發現，該樣本并沒有加任何的殼。

然而當查找字符串時，卻未能發現一些可疑的字符串（如下載器常有的惡意url），看到的只是一堆亂碼，看來，該樣本很有可能就是使用了自解密的技術。

反編譯該樣本，也難以看出它的代碼邏輯，很多動態地址的call。

對于這種樣本，反編譯器很難看到一些重要的操作，因為大部分都是解密操作，所以只能通過調試器單步調了。單步調試沒啥好技巧，遇到跑飛的call下斷點然后重新調試。調試的時候，要注意VirtualAlloc、GlobalAlloc、HeapCreate這些函數，因為惡意代碼通常使用這些函數來申請一段內存空間，來存放解密出來的惡意代碼。如下圖，該樣本調用的是HeapCreate創建了0×230000這段內存。

接著惡意代碼用了je + retn的方式循環解密0×230000處的數據。

解密完畢后，惡意代碼調用call esi將執行流從0x40XXXX轉到0×230000。

然而，0×230000處的代碼并不執行核心的惡意操作，目的在于修改0x40XXXX處的原始代碼。如下，它會調用VirtualProtect將0×400000的內存屬性改為RW（讀寫），進而修改原來的代碼。

修改后的0×400000內存段的屬性如下。

修改完代碼，調用jmp esi跳回到0x40XXXX進行執行，此時，這段內存的代碼已經被修改過了，終于開始執行核心的惡意操作了。

將內存dump下來發現，現在的代碼已經是解密后的惡意代碼了，程序邏輯清晰可見，通過字符串查找可以找到待下載的病毒的url。

至此，該下載器的功能已經分析完畢，主要功能為從http://thespecsupportservice.com/load.png下載Ammyy病毒并運行。

由此，可以總結得出，惡意代碼自解密的步驟一般為以下5步：申請內存 -> 復制數據 -> 解密數據 -> 跳轉到堆中執行惡意代碼 -> 修改原始代碼并跳回執行。不過，我們可能會有個疑惑，病毒為什么不直接在堆中執行核心的惡意操作呢，還要通過修改原始代碼來在0×400000空間解密執行核心的惡意代碼。這是因為，一些比較高級的沙箱、殺軟會監控病毒創建大片內存空間的操作，這時一旦釋放出解密代碼，便會立刻被沙箱、殺軟檢測到，所以在堆中的代碼一般不會只會直接進行核心的惡意操作。

了解了惡意代碼自解密技術后，來看看最近流行的GandCrab勒索病毒（MD5：48A673157DA3940244CE0DFB3ECB58E9），使用的也是這種自解密技術，來實現免殺。使用DIE對樣本進行檢測，顯示并未加殼。

自解密的手法跟上述提到的相似，在0×1280000處申請了一段內存空間。

堆中的代碼負責修改原始代碼并跳轉回去執行。

跳轉回來后，0×403016處的代碼就是解密后的核心惡意代碼，接下來就可以調試GandCrab的惡意代碼了。

將內存Dump下來，也可以分析出加密文件的代碼邏輯。

在VT上查詢該病毒的報毒情況，只有大概半數的引擎報毒，而且報出的病毒類型大多不能定位到Ransom，看來，GandCrab使用這種自解密的方式還是起到了一定的免殺效果。