Win Steg GUI｜Windows C++ 研究原型

研究原型與工程實作

資安演練中的測試程式能否執行，往往受到防毒軟體（AV）與端點防護影響。檔案是否被攔截、執行時是否產生告警，以及測試端能否收到連線，都是需要記錄的結果。

Win Steg GUI 是碩士研究中開發的 Windows C++ 原型，結合影像藏密、AES 加解密與編譯階段混淆。介面使用 FLTK 顯示影像與載入狀態，測試則在虛擬機中進行，並保留 VirusTotal 與 Hybrid Analysis 的分析紀錄。

Windows 桌面程式 · C++ · 影像資料處理 · 研究原型

專案概覽

#

本專案原始碼：curtyuan/win-steg-gui。

設計與資料流程

#

程式分為桌面介面、影像處理與共用工具三部分。介面操作與資料處理的關係如下：

使用者操作 → 桌面介面 → 影像／資料處理 → 結果與狀態回饋

• 桌面介面 — 使用 FLTK 建立分頁與操作按鈕，顯示影像及載入狀態。
• 影像處理 — 使用 Blimp 操作 BMP 影像，整合影像藏密與資料轉換。
• 共用工具 — 集中管理影像、檔案與日誌相關工具，供各模組使用。

執行時序

#

本專案使用 APC（Asynchronous Procedure Call，非同步程序呼叫）讀取藏密影像、提取資料與解密，由 GUI 的載入錯誤觸發，後續執行則交由另一條執行緒處理。錯誤處理 callback 會同步等待 APC 工作完成，因此這段期間 GUI 事件循環會暫停。

「2th Examiner」分頁：以載入失敗觸發背景工作

#

介面的第二個分頁標示為 2th Examiner。啟動時，程式會刻意載入不存在的影像檔（assets/images/lena9.bmp），透過載入失敗呼叫已註冊的 error handler，讓先前建立並掛起的 APC 執行緒繼續工作。

因此，第二個分頁的載入錯誤是預先安排的觸發事件，並非測試中意外發生的故障。

技術考量

#

本專案使用的主要工具與方法如下：

• 影像處理： 使用 Blimp 操作 BMP 影像，藏密採用最基本的 2-bit LSB 直接替換；影像品質以 MSE、PSNR 與 SSIM 評估。
• 加解密： 使用 Tiny-AES-c 處理 AES 加解密。
• 工程實作： 以 C++14、FLTK 1.3.9 與 CMake 3.30.1 建立桌面原型；GUI 套件透過 vcpkg 安裝。

編譯階段混淆：Akira-Obfuscator

#

編譯階段使用基於 LLVM 的 Akira-Obfuscator，搭配相容的 Clang 17.0.6，對 C++ 程式進行程式碼層級混淆。影像藏密處理的是酬載的儲存方式，編譯混淆則改變程式結構與編譯後的二進位特徵。 Repo 連結: https://github.com/thomasxm/Akira-obfuscator

CMakePresets.json 的 Release preset 啟用了以下四項混淆功能：

• -mllvm -irobf：啟用 Akira 的指令替換／指令層級混淆 pass。
• -mllvm -irobf-indbr：啟用 indirect branch 混淆，將部分直接分支轉成間接分支，提高靜態分析控制流程的難度。
• -mllvm -irobf-icall：啟用 indirect call 混淆，將部分直接函式呼叫改寫成間接呼叫，降低呼叫目標的直觀性。
• -mllvm -irobf-indgv：啟用 indirect global variable 混淆，對全域變數存取做間接化處理，增加資料流分析難度。
• -mllvm -irobf-cff：啟用 control-flow flattening，將原本較清楚的控制流程攤平成 dispatcher 形式，增加還原程式流程的難度。

第三方函式庫與授權

#

用到的函式庫授權如下：

驗證方式與結果解讀

#

測試樣本的選擇

#

測試使用 msfvenom 產生的 Windows x64、非分階段（unstaged）的 TCP reverse shell。Shellcode 本身未再套用編碼器、額外混淆，也未改用其他混淆版本；儲存時仍經過本專案的 AES 加密與影像藏密。

選用這個樣本，是因為未經處理的版本具有明顯的已知特徵，適合作為對照。保留 shellcode 原本的內容，便能把測試重點放在加密、藏密、載入與編譯混淆等其他步驟整合後的效果。不過，這次沒有逐項移除各步驟做對照測試，因此只能觀察整套流程的結果，無法據此判定每個步驟各自的貢獻。

測試期間，在 win defender 下雖然可以回傳，可以你下完 cd 大概過沒 5 秒記憶體監控就把它殺了，還沒試 shikataganai (仕方がない ), 過，這就純粹懶😵

影像品質比較

#

藏密採用最簡單的 2-bit LSB 直接替換法，將 RGB 各色彩通道的最低兩個位元替換為待藏入的資料。測試使用的 512 × 512 BMP 影像，對本次 msfvenom shellcode 及加密後的資料而言，容量已相當足夠，只需修改影像中的一小部分。

這個方法沒有抗干擾設計；加入雜訊、有損壓縮、縮放或其他會改變像素值的處理，都可能破壞藏入的資料。本專案將它用作 AV 測試中的簡化藏密流程，測試時保留原始 BMP，不以壓縮或影像處理後仍可還原資料為目標。

影像差異使用 DiffImg 檢視，並以 MSE、PSNR 與 SSIM 量測相似度。下圖中的黃色部分是比較工具標示的差異，非原圖本身的顏色。

本次測試影像的品質量測

用 2 bit 的 LSB 對一張512x512 的照片來說藏密量是很小，雖然有藏的地方差異很大，但一般沒事也不會有軟體特別去檢查圖片。 這個數字比較像是用來自嗨的😂 bmp 格式的圖片也不太可能用在任何行動中，做這個的時候想到 duqu 2.0 https://en.wikipedia.org/wiki/Duqu_2.0 的事情就覺得很扯。

虛擬機測試架構與動態紀錄

#

測試環境由基本就是往vm 一台 win 一台 kali 在 192.168.0.0/16 下完成。

防護工具觀察

#

記錄一下測試結果

我沒有信心有開雲端在熵爆炸高的狀況下可以得到什麼很好的效果。 MVP 是 akira obfuscator ，自動化的做源始碼級的混淆，多好。