1. 惡意軟體混淆簡介

惡意軟體混淆是資安領域的重大挑戰，旨在隱藏 malicious code 以規避安全軟體和逆向工程師的檢測。透過在保留功能的情況下轉換程式碼，混淆技術使程式邏輯難以理解、識別 malicious functionality 並建立有效的簽章式偵測。本報告深入探討 SLOW#TEMPEST 惡意軟體中觀察到的特定進階混淆技術，強調這些方法如何複雜化分析，以及如何有效應對。

2. 控制流程圖 (CFG) 混淆

控制流程圖 (CFG) 混淆是一種改變程序指令執行順序的技術，使靜態和動態分析更加困難 [1]。其核心理念是增加程序邏輯流的複雜性，從而阻礙逆向工程工作。這種複雜性可表現為多種形式，包括添加冗餘或無關的控制結構、轉換條件分支，以及用間接跳轉取代直接跳轉 [2]。

在 SLOW#TEMPEST 惡意軟體的環境中，CFG 混淆特別透過動態跳轉至 loader DLL 的主函數來實現。圖 1 展示了該函數在混淆與未混淆狀態下的 CFG。混淆後的 CFG 顯得極其複雜，幾乎無法追蹤程序的真實執行路徑。一旦移除混淆，連續且邏輯清晰的程式碼流即顯現出來，通常以綠色和紅色線條分別表示真假分支 [1]。

SLOW#TEMPEST 的 loader DLL 主函數極其龐大，包含超過 17,000 行組合語言指令。這種龐大的程式碼量結合混淆技術，對傳統分析工具構成重大挑戰。例如，Hex-Rays 除錯器，一款將組合語言轉為 pseudocode 的強大工具，僅能為此函數生成僅 10 行的 pseudocode，如圖 2 所示 [1]。這一限制突顯了 CFG 混淆在阻礙自動化解編譯和靜態分析方面的有效性。

Hex-Rays 除錯器失敗的主要原因在於惡意軟體廣泛使用動態跳轉指令。與跳轉至固定位址的直接跳轉不同，動態跳轉在執行時計算其目標位址。這種動態計算使得除錯器無法在不實際執行程序的情況下準確確定執行流程，從而導致解編譯結果不完整或不準確 [1]。

3. 動態跳轉：詳細分析

動態跳轉是一種複雜的控制流混淆形式，其跳轉指令的目標位址並非固定，而是在程序執行期間計算得出。此技術在規避靜態分析方面極為有效，因為不執行程式碼無法確定跳轉目標。在 SLOW#TEMPEST 中，這一點透過 JMP RAX 指令體現， RAX 暫存器儲存動態計算的目標位址 [1]。

圖 3 展示了在 loader DLL 主函數入口點附近使用 JMP RAX 指令的動態跳轉範例。目標位址由一系列前置指令（統稱為「dispatcher」）決定，位於每個 JMP RAX 指令之前 [1]。這些 dispatcher 雖然結構相似，但各自使用不同的指令集來計算跳轉目標，有效隱藏程序的控制流 [1]。

SLOW#TEMPEST 中的每個 dispatcher 實現了雙向分支機制，程式碼路徑取決於特定 CPU 旗標的狀態：Zero Flag (ZF) 或 Carry Flag (CF) [1]。這些旗標由先前指令設定，指示運算結果（例如零或溢位），從而決定採取哪個分支 [1]。

dispatcher 通常包含一對條件移動 ( CMOVNZ ) 或設定 ( SETNL ) 指令以及間接跳轉 ( JMP RAX ) [1]。這種組合創造了高度依賴執行時條件和記憶體內容的動態控制流，使得靜態分析極其困難 [1]。

• JMP RAX ： 此指令將程序控制轉移至 RAX 暫存器中儲存的位址。 RAX 中的值是動態計算的，使得跳轉目標在不執行程序的情況下無法預測 [3]。
• CMOVNZ (條件移動若非零)： 此指令在 Zero Flag (ZF) 未設定 (ZF = 0) 時條件性地移動資料。若 ZF 為 1，則不執行移動，允許在無顯式跳轉指令的情況下進行條件分支 [4]。
• SETNL (設定位元若不小於)： 此指令在滿足「不小於」條件時將位元組運算元設為 1，否則設為 0。通常與比較或算術運算結合使用，根據 CPU 旗標影響控制流 [5]。
• Zero Flag (ZF)： 若算術或邏輯運算的結果為零，則設定 ZF (ZF = 1)；否則清除 (ZF = 0)。對於條件運算至關重要，可根據先前計算結果進行決策 [6]。
• Carry Flag (CF)： 若算術運算從最高有效位元產生進位（加法）或借位（減法），則設定 CF (CF = 1)。主要用於無符號算術運算，檢測溢位或鏈接多精度運算 [7]。

圖 5 提供了其中一個 dispatcher 的 CPU 指令註釋圖，展示如何根據這些旗標和指令計算目標位址 [1]。

3.2. 解混淆動態跳轉

要對抗使用動態跳轉的 CFG 混淆，需採取多步驟方法。第一步是識別所有動態跳轉的實例。這可透過 IDAPython 腳本實現，如圖 4 所示 [1]。該腳本幫助定位如 JMP RAX 的指令，這些指令標示動態控制流。在分析的 loader DLL 中，主函數內識別出 10 個此類動態跳轉 [1]。

識別後，下一步是確定這些動態跳轉的實際目標位址。此處模擬扮演關鍵角色。使用如 Unicorn 的多平台、多架構 CPU 模擬器框架，可在控制環境下執行每個 JMP RAX 前面的九條指令（即 dispatcher） [1]。這允許精確確定每個 dispatcher 的跳轉位址，而無需運行整個 malicious binary。圖 6 展示了用於提取 dispatcher 位元組碼的程式碼，圖 7 展示了模擬過程以確定目標位址 [1]。由於每個 dispatcher 實現雙向分支機制，模擬過程需對每個 dispatcher 重複兩次，以確定兩個可能的目標位址 [1]。

計算出兩個目標位址後，可透過將 dispatcher 指令替換為直接跳轉至這些解析位址的指令來有效移除混淆。此修改使 IDA Pro 等工具能夠視覺化原始的連續程式碼流。圖 8 展示了用於在 IDA 資料庫中直接修補指令的程式碼 [1]。

最後，為確保 IDA Pro 根據解混淆的指令更新其控制流程圖，需強制重新分析修補後的函數，如圖 9 所示 [1]。此全面的解混淆過程使 Hex-Rays 除錯器能夠成功解編譯 loader DLL 中的主函數，如圖 10 所示的解編譯輸出 [1]。

4. 混淆函數呼叫

即使解決了動態跳轉，進一步的混淆仍常存在，特別是混淆函數呼叫的形式。在 SLOW#TEMPEST 中，大多數函數以動態方式呼叫，直接的 Windows API 呼叫並不顯而易見 [1]。這種間接函數呼叫方式，透過在執行時動態計算函數位址並透過指標呼叫（例如透過 CALL RAX ），顯著阻礙靜態分析 [1]。實際目標函數在程式碼中不易察覺，難以理解程序行為並識別 malicious actions [1]。圖 11 提供了此類混淆函數呼叫的範例 [1]。

4.1. 解析混淆函數呼叫

確定混淆函數呼叫目標位址的方法與動態跳轉類似，因為兩者都涉及執行時計算目標位址 [1]。雖然腳本成功計算出這些目標位址，但 IDA Pro 可能仍無法識別標準 Windows API 的參數，即使位址已正確解析，如圖 12 所示 [1]。此問題源於缺少將解析位址連結至已知 Windows API 的函數簽章資訊 [1]。

為使 IDA Pro 正確識別函數參數、重新命名本地變數並執行適當分析，需為每個混淆函數呼叫明確設定「callee」位址。這為 IDA Pro 提供了識別函數為已知 Windows API 的關鍵資訊。圖 13 展示了用於設定「callee」位址的程式碼 [1]。透過添加此程式碼，IDA Pro 會自動標記函數參數並為每個混淆函數呼叫重新命名本地變數，大幅提升程式碼可讀性和分析能力 [1]。圖 14 展示了此過程後的一些標記函數參數 [1]。

5. 結論

SLOW#TEMPEST 惡意軟體體現了對手用於規避檢測與分析的混淆技術的日益複雜化。其依賴透過動態跳轉和間接函數呼叫實現的控制流程圖混淆，為傳統靜態分析工具（如 Hex-Rays 除錯器）帶來重大挑戰。然而，透過結合動態模擬（如 Unicorn 引擎）與 IDA Pro（IDAPython）的腳本功能，可系統性地解混淆這些複雜機制。本報告概述的方法，包括識別與模擬 dispatcher，以及為混淆函數呼叫明確設定 callee 位址，展示了揭示此類進階惡意軟體真實功能的有效策略。本研究強調了動態分析和專用解混淆技術在對抗複雜網路威脅中的重要性。

參考文獻

1. Evolving Tactics of SLOW#TEMPEST: A Deep Dive Into Advanced Malware Techniques
2. Control Flow Obfuscation - Zimperium
3. JMP — Jump
4. CMOVcc — Conditional Move
5. SETcc: Set Byte on Condition (x86 Instruction Set Reference)
6. Understanding the Zero Flag in Assembly Language - Medium
7. The Ultimate Guide to Carry Flag - Number Analytics