摘要

本報告提供對 GPUGate 惡意軟體的詳細技術分析，聚焦於其創新的硬體特定解密與反分析機制。此惡意軟體採用獨特的 GPU 限制解密 routine，利用 OpenCL 確保其 payload 在缺乏正版 GPU 驅動程式的系統上保持加密，從而規避在虛擬化和沙箱環境中的檢測。我們檢視了兩階段解密程序，分析負責條件式 key 生成的關鍵 OpenCL kernel 程式碼，並討論此類複雜規避技術在現代網路安全威脅中的影響。本研究旨在揭示 GPUGate 的技術細節，促進對進階惡意軟體規避策略的更好理解。

GPUGate 惡意軟體：Threat Actors 不想讓你知道的硬體攻擊 | 資訊安全新聞

1. 簡介

惡意軟體發展的環境持續演進，threat actors 採用日益複雜的技術來繞過安全措施並實現持續性。傳統惡意軟體通常優先考慮廣泛相容性以最大化感染率。然而，以 GPUGate 為代表的新型惡意軟體採取相反策略：故意排除那些不符合嚴格硬體要求的系統。這種方法直接回應了安全研究人員廣泛使用虛擬機器（Virtual Machines,VM）、沙箱和分析環境進行惡意軟體調查的趨勢 [1]。

GPUGate 通過以圖形處理單元（Graphics Processing Unit, GPU）功能為中心的獨特反分析機制脫穎而出。該惡意軟體的 128 MB Microsoft Software Installer (MSI) 設計進一步複雜化其分析，規避許多現有安全沙箱。其核心創新在於其 GPU 限制解密 routine，防止 payload 在沒有正版 GPU 和適當驅動程式的系統上被解密和執行。本報告深入探討此機制的技術細節，提供對 GPUGate 運作方式及其對網路安全防禦挑戰的深入分析。

2. 反分析技術

GPUGate 的主要反分析技術圍繞其對特定 GPU 硬體和驅動程式設定的依賴。與傳統惡意軟體追求最大相容性不同，GPUGate 故意在檢測到不適合其運作的環境（如虛擬機器或沙箱）時終止執行。這通過兩個主要檢查實現：

2.1. GPU 功能可用性

惡意軟體首先驗證 GPU 功能的可用性。如果系統缺乏適當的 GPU 驅動程式或功能性 GPU，程序將終止。這是過濾許多分析環境的關鍵步驟，因為這些環境通常使用最少或通用的顯示驅動程式，無法完全支援 GPU 加速。

2.2. GPU 設備名稱長度檢查

在 GPU 功能檢查之後，GPUGate 執行更細緻且有效的反分析技術：檢查 GPU 設備名稱的長度。如果裝置名稱少於 10 個字元，惡意軟體就會終止。此 threshold 經過策略性選擇，因為虛擬機器和分析環境通常使用簡化或通用的 GPU 設備名稱，這些名稱比真實硬體的名稱短。例如，正版遊戲 GPU 的名稱可能為 "NVIDIA GeForce RTX 4090"（25 個字元），而虛擬機器的 GPU 名稱可能是 "VMware SVGA"（正好 10 個字元）或更短。通過強制要求最少 10 個字元的長度，惡意軟體有效過濾掉大量分析設置，確保僅在真實用戶系統上執行 [1]。

此機制顯示出 threat actors 對惡意軟體分析環境配置的深刻理解，使其能夠規避安全研究人員的檢測，同時成功危害目標系統。

3. 解密機制

GPUGate 功能的核心在於其兩階段解密程序，該程序大量利用 OpenCL 進行基於 GPU 的計算。OpenCL（Open Computing Language）是一個開放、免版稅的標準，促進跨平台並行程式設計，涵蓋 GPU、CPU 和其他硬體加速器。此技術選擇突顯了惡意軟體利用硬體特定功能進行操作的意圖 [1]。

3.1. 加密組件

惡意軟體的 Resources 類別包含兩個關鍵加密組件：

  • Encrypted Payload： 位於相對虛擬位址 (Relative Virtual Address, RVA) 0x03C03C40 ，跨越 5648 位元組。
  • Encrypted OpenCL Kernel： 位於 RVA 0x03C05250 ，跨越 709 位元組。

這些組件在惡意軟體成功通過反分析檢查並可利用 GPU 進行解密之前保持加密。

3.2. 兩階段解密程序

3.2.1. 第一階段解密

初始解密階段涉及簡單的 XOR 運算。payload 的第一階段使用 0x5A 的 key 進行解密。成功解密後，此階段執行負責生成第二階段主 payload 解密所需 key 的程式碼 [1]。

3.2.2. 基於 OpenCL Kernel 的 Key 生成

第二階段解密較為複雜，依賴於 GPU 通過 OpenCL kernel 生成的 key。惡意軟體中的 GpuKeyGenerator 類別負責協調此程序。解密的 OpenCL kernel 揭示了一個名為 generate_key 的函數，該函數是條件式 key 生成的核心。 XCtx 類別進一步提供客制化的 AssemblyLoadContext ，用於動態載入最終解密的 .NET 組件。

3.3. OpenCL Kernel 程式碼分析

generate_key OpenCL kernel 是一個關鍵組件，決定惡意軟體是否繼續其 malicious 活動或終止。以下是該 kernel 的程式碼片段： 

  1. kernel void generate_key(global uchar* output, __global const char* device_name)
  2. {
  3.     int id = get_global_id(0);
  4.     int suspicious_flag = 0;
  5.     // Check device name length
  6.     int length = 0;
  7.     for (int i = 0; i < 32; i++) {
  8.         if (device_name[i] == '\0') break;
  9.         length++;
  10.     }
  11.     if (length < 10)
  12.         suspicious_flag = 1;
  13.     uchar good_key[16] = { 0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xF0, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88 };
  14.     uchar fake_key[16] = { 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA };
  15.     if (id < 16)
  16.         output[id] = suspicious_flag ? fake_key[id] : good_key[id];
  17. }

函數參數： * output ：一個全域無符號字元陣列，用於儲存生成的 key（ good_key 或 fake_key ）。 * device_name ：一個全域常數字元陣列，包含 GPU 設備的名稱。

關鍵邏輯： 1. 設備名稱長度檢查： kernel 計算 device_name 字串的長度。此迴圈重覆最多 32 個字元或直到遇到 null terminator ( \0 )。 2. 可疑標誌： 如果計算出的 device_name 的 length 小於 10，則將 suspicious_flag 設為 1 。此標誌表示環境可能是分析沙箱或虛擬機器。 3. Key 定義： 定義兩個 16 位元組陣列： * good_key ：包含特定的十六進位值序列（ 0x12, 0x34, ..., 0x88 ）。這是合法的解密 key。 * fake_key ：全部填充 0xAA 值。此 key 設計為導致解密失敗。 4. 條件式 Key 分配： 根據 suspicious_flag ，填充 output 陣列。如果 suspicious_flag 為 1 （表示設備名稱過短），則使用 fake_key 。否則使用 good_key 。此條件分配確保僅在具有足夠長 GPU 設備名稱的系統上生成正確的解密 key，有效繞過分析環境 [1]。

3.4. AES-CBC 解密

主 payload 使用 AES-CBC（Advanced Encryption Standard in Cipher Block Chaining mode,進階加密標準在密碼區塊鏈結模式）加密，初始化向量 (IV) 為零。此 AES 解密的 key 正是由 generate_key OpenCL kernel 生成的 16 位元組輸出。如果因反分析檢查生成 fake_key ，AES 解密將失敗，使惡意軟體 payload 無效並阻止其執行 [1]。

4. 解密流程圖

以下圖表說明 GPUGate 採用的兩階段解密程序及條件邏輯： 


    graph TD
        A[Malware Execution] --> B{GPU Driver Check & Device Name Length < 10?}
        B -- Yes --> C[Terminate]
        B -- No --> D[First Stage Decryption XOR with 0x5A]
        D --> E[Launch OpenCL Kernel: generate_key]
        E --> F{Device Name Length < 10 in Kernel?}
        F -- Yes --> G[Generate Fake Key 0xAA...]
        F -- No --> H[Generate Good Key 0x12...]
        G --> I[AES-CBC Decryption with Fake Key]
        H --> J[AES-CBC Decryption with Good Key]
        I --> K[Malware Fails to Decrypt/Execute]
        J --> L[Malware Decrypts & Executes]

圖 1：GPUGate 解密流程

5. 結論

GPUGate 代表了惡意軟體規避技術的重大進展，超越簡單的混淆，融入複雜的硬體特定反分析機制。通過利用 OpenCL 並利用真實系統與虛擬化環境之間 GPU 設備命名慣例的差異，該惡意軟體有效過濾安全分析嘗試。兩階段解密程序，特別是 OpenCL kernel 中的條件式 key 生成，顯示出對防禦策略及其規避方式的深刻理解。

此技術分析強調了惡意軟體開發者與網路安全專業人員之間的持續軍備競賽。GPU 限制惡意軟體的出現促使重新評估當前分析方法，敦促研究人員開發更動態且具硬體感知能力的沙箱解決方案。理解此類威脅的細節對於開發能夠應對不斷演變的網路攻擊環境的強大檢測與預防機制至關重要。

參考資料

  1. GPUGate Malware: Malicious GitHub Desktop Implants Use Hardware-Specific Decryption, Abuse Google Ads to Target Western Europe