一種新型惡意軟體混淆技術的逆向分析

常見的逆向工程工具往往都是針對基本假設而開發的，例如：二進位制檔案通常符合編譯器生成的標準模式、指令不會跳轉到其他指令、一些情況下符號是可用的等等。逆向工程師可能都知道，如果這些假設不符合實際，那麼逆向的工作量將會大大增加。這將造成逆向工具出現問題，甚至完全不可用。本文主要講述了這樣的一個場景，並提出了一個效率較高的解決方案。

我正在分析的二進位制檔案，特別是其中的一個函式，沒有使用常見的惡意軟體偽裝技術，這種技術違反了關於函式大小的常規假設。並且，惡意軟體的作者經常會以動態方式構建他們需要的資料（最常見的就是字串），以便使用諸如“字串”或十六進位制編輯器之類的工具來模糊分析的資料。其實，惡意軟體通常也會以某種方式對其字串進行加密，但這並不是我們在本文中關注的功能。因此，我們在相關函式中看到了很多形如下面的函式。

這個二進位制檔案所使用技術的與眾不同之處，在於它應用的規模。通常，這種技術用於模糊字串，也不會超過幾十個位元組。然而，這個二進位制檔案使用該技術構建兩個嵌入式的可執行檔案，總共大約16KB的資料，因此，大約有16000位元組的內容使用了這種技術，如上圖所示，每一部分都由7個位元組的指令實現。上圖所示的函式中，包含大約118KB的程式碼，這佔據了整個二進位制檔案的25%以上。即使沒有使用這種技術，該函式也會很大，因為它除了上面的指令之外，還有大約7KB的變異程式碼。

該函式的Hex-Rays反編譯大約是32500航。其中，大部分都來自兩個位置。第一，每個寫入棧位元組都會宣告一個棧區域性變數：

第二，每次寫入棧變數時，都有一個賦值語句：

藉助IDA的幫助，我們可以成功對這個函式進行處理。使用IDA來分析這一函式並沒有出現明顯的速度差異。但是，如果使用Hex-Rays來處理，將會出現明顯的問題。其實，這並不能說明Hex-Rays的效能較差，畢竟這個函式有118KB之大，Hex-Rays將會進行比IDA更多的處理。首先，我必須修改Hex-Rays反編譯選項，從而可以反編譯這一函式：

在進行這一更改後，Hex-Rays處理函式的速度非常慢，我每次對其進行反編譯時，我的CPU核心大約會耗盡大約5分鐘的時間。基於以下幾個原因，我們認為這是次優的方案：

1、在對特定二進位制檔案進行逆向工程時，我經常多次使用File -> Produce file -> Create .c file…選單命令。該函式會在遇到每個命令時出現短暫的中斷。

2、某些外掛，例如Referee，最好與上述提到的命令一起使用。

3、當以互動方式（例如通過重新命名變數或添加註釋）在此函式上使用反編譯器時，UI會變得非常緩慢，且可能會無響應。

4、隨機檢視指定函式的交叉引用，或者來自特定函式的交叉引用的過程將非常緩慢。對於反編譯錯誤的函式，我們必須要等待反編譯器完成。

基於上述原因，我們決定採用更加有效的方案：

1、通過相應的112KB編譯程式碼，提取寫入棧中的兩個.bin檔案；

2、將這些.bin檔案修補到資料庫之中；

3、使用一個補丁，呼叫memcpy()替換112KB的指令；

4、修補函式的程式碼，分支出超過112KB的棧寫入。

我要做的第一件事，就是將棧寫入的Hex-Rays反編譯結果複製貼上到自己的文字檔案中。然後，我們迅速地進行一些健全性檢查，以確保所有寫入操作能夠按順序進行，我使用了一些正則表示式的搜尋和替換操作，並且採用了手動編輯，來將資料清理成我可以在Python中使用的格式。

接下來，我還寫了幾行Python程式碼，將資料儲存為二進位制檔案：

在這一位置，我使用IDA的Edit -> Patch Program -> Assemble…命令，將一個較小的補丁寫入相應的函式：

經過一些調整，並且使用十六進位制編輯其結果後，我的補丁被成功安裝：

然後，我使用兩行IDC指令碼，將二進位制檔案作為資料，載入到正確的位置：

之後，導航欄顯示，大約31%的文字部分已經轉換為資料。

現在問題已經解決了。該函式的反編譯過程大約需要2秒左右的時間，這更加符合我們認為7KB函式所需的時間。非常好，這次沒有出現更多無休止的等待，完成了這部分函式的反編譯過程。

通過本文中的案例，可以看出，如果我們足夠了解所使用的工具，就能找出導致問題的原因，從而可以進一步解決這一問題。始終保持好奇心，並積極進行實驗，並且不要只想到次優的逆向工程方案而不再去積極探索是否有更加簡單的解決方案。