[Windows] 逆向工程 C++ 中入口函數參數 main(argc, argv) 與如何正確的進行參數劫持

-

前言

我在 Github 上三年前開源了精簡的以 C/C++ 撰寫的 Windows 執行程式裝載器：aaaddress1/RunPE-In-Memory 用以從記憶體執行以 C/C++ 開發的 *.exe 程式不必以 CreateProcess() 來叫起，算是一種概念性 PoC 啦畢竟這種手段在惡意程式和殼上經常使用，所以寫一寫就丟出來給大家玩 XD

不過有人在我的專案發起了 Issue：既然能從記憶體中執行 *.exe 那能否偽造 *.exe 取得的參數呢？嗯好問題XD 正逢去年蠻忙的所以一直懶得弄，這個月比較閒於是就決定在專案中新增 參數偽造 的功能，這邊簡單提一下 C++ 中 main() 入口所收的 argc 與 argv 來的。

[附註] 以下逆向工程內容以 MinGW 生產的程式為例，系統逆向工程為 Win10 企業版 1809版 

CRTStartup

在 Windows 下通常取得參數通常分為兩種狀況：
  1.  WINAPI GetCommandLineW() 系統函數返回字串指針指向當前完整應用程式參數
  2. 從 main(argc, argv) 拿回來的參數，那麼第二種狀況在編譯器是怎麼吐參數給開發者 main 入口的呢？

在編譯器吐出執行程式後，連結器會生產一段 CRTStartup 的函數用於做一些基礎的例如像是 Security Cookies、Control Flow Guard 保護的初始化，在一系列初始化之後 .data 段的全域變數 _argv、argc 紀錄著要傳入給開發者入口函數的 參數陣列 與 數量，就以參數形式呼叫 main() 函數

好問題，那這兩個全域變數是在哪裡被初始化的？

你會發現以 MinGW 為例的話，會去呼叫 msvcrt!__getmainargs() 來取得參數資訊保存到 .data 全域變數上，後續再傳遞給 main() 函數；如果是 VC++ 吐出來的則是直接呼叫 GetCommandLineW() 在做文字切割取出參數

MSVCRT


MSVCRT.dll 有導出一系列 C 函數是引用 #include <stdio.h> 時會用到的，例如 printf, sprintf, gets 等等。我們剛剛提到了其導出函數 __getmainargs() 負責解析。事實上這個函數內部實作也只是把它全域變數所記錄的參數指過去到我們的指針上面而已XD

那麼到底是什麼時候初始化的呢？

逆向工程入 MSVCRT.dll 初始化階段，你會發現上述三個參數指針也只是調用了 GetCommandLineW() 與 GetEnvironmentStringA() 後，將參數內容先拷貝一份到 MSVCRT.dll 全域變數中，等到有人調用 __getmainargs() 時，就會把 MSVCRT.dll 先前所記錄到的參數資訊指針傳遞給你

那麼 GetCommandLineW 內部實作呢？

KERNELBASE

在 KernelBase.dll 中其實也有跟 MSVCRT 做法一致，會先將當前應用程式參數以 RtlUnicodeString() 備份一份到全域變數中、當有人調用 GetCommandLineW() 時，就會把先前備份的參數內容吐給你。而 KernelBase.dll 中備份的參數內容是來自於 Loader 初始化階段的 PEB() 結構塊所記錄的參數資訊

參數劫持

好，上述所有資訊擺在一起，就可以回答很多人疑惑的「直接覆蓋 PEB→ProcessParmeters→CommandLine 無法劫持參數」的問題了

當有一個應用程式是 Console 程式取得 main() 參數時，基本上參數傳遞流程會是：
  1. Loader 生成 PEB!ProcessParemeters 紀錄了完整程式命令參數字串 
  2. KernelBase.dll 函數入口備份一份至 KernelBase.dll 全域變數
  3. GetCommandLineW() 函數被呼叫時將 KernelBase 全域變數紀錄的參數傳遞給 MSVCRT.dll
  4. MSVCRT.dll 函數入口將 GetCommandLineW() 取得的參數字串備份一份到 MSVCRT.dll 全域變數中紀錄
  5. __getmainargs() 被呼叫時，將 MSVCRT.dll 全域變數紀錄的參數內容下放給 CRTStartup
  6. main() 函數入口被呼叫時取得參數
就從劫持面來說，如果你想覆蓋掉的 參數文字變數 共計會有：
  1. PEB塊
  2. MSVCRT.dll 全域變數所紀錄的三組指針上保存的 MSVCRT 變數
  3. KERNELBASE.dll 全域變數所紀錄的三組指針上保存的 MSVCRT 變數

所以在看雪之類的地方通常大神會告訴你：直接去 IAT Hook 劫持 GetCommandLineW() 跟 __getmainargs() 比較快是有原因的 XD

當然還有另一種做法是可以採 RunPE 的手段，先創建 SUSPENDED 狀態的進程，這時候上述所有模組都沒被初始化的狀況下就先抹掉 PEB 上的參數紀錄，接著再恢復進程運作可以優雅地達成劫持，不過這種做法防毒 100% 會叫啦太敏感惹

留言

張貼留言

這個網誌中的熱門文章

[Black Asia Arsenal] puzzCode: 專注開發後門的編譯器, 自帶反逆向、對抗病毒特徵碼定位技術

-
圖片
前言 安安，這篇沒有講任何工具本身細節XD 純粹是個人一些 murmur 的廢文 簡報 專案 github.com/aaaddress1/puzzCode 吃我 Source 看細節啦（？） #murmur 其實事情是這樣 der，去年底忙完一堆工作的事情後發現好像有點閒，然後就收到了這樣的一封信躺在我的 gmail 裡面。 畢竟個人覺得自己沒那個屁股能投稿上 BlackHat 或者 DEFCON 這種一線等級的大 Conf。 這封信指出可以投稿你自己的駭客工具到 Black Hat Asia，若被接受，你可以獲得一個攤位和大約 2hr 時間可以讓你 present 你工具特別之處，最棒的是你可以獲得價值六萬塊新台票的入場券！（就是門票啦，那張 Badge）除此之外會贈送大會背包這樣，對一個沒去過 Black Hat 的屁孩如我來說超吸引的啊XD 之前的研究一直都差不多打轉在防毒軟體怎麼設計安全防護上，然後花了一點時間接了 MinGW 編譯器（GCC 在 Windows 分支版本的編譯器）用 C# 寫了一個簡單的 UI，來做到自動化將 C/C++ 原始碼透過編譯器產生 Assembly Script（其實理想狀況用編譯器的 IR Code 會比較恰當，畢竟如果要跨 CPU 架構，你的混淆 Patten 很容易吃大便）然後自幹了簡單的 Assembly 指令混淆邏輯單元、最後再透過組譯器產生出 Object File 與連結器封裝為 *.exe 的 Windows 程式這樣XD 這樣的工具當初構想是：很多基於 YARA 或者其他自定義的惡意程式特徵碼設計概念都是連續組合語言片段檢測 + Hash Check 來確認一隻文件是否具有惡意（正確來說應該是：是否已經被建檔為惡意文件）所以如果能設計一個編譯器自動化做到同份原始碼、每次編譯出的執行程式都會被混淆邏輯單元打散程式碼順序與穿插混淆程式碼，那其實可以做到很強程度的對抗現在一線的防毒軟體（看看那隻有點紅的小傘） 運氣不錯的是：以往 Black Hat 收錄的工具沒有這類型的工具，原本只有備取、最後成功被收錄到 Black Hat Asia 的軍火庫（Arsenal）啦，可參見至： PUZZCODE, MAKE BACKDOORS GREAT AGAIN! 實際擺攤的時候，對你工具有興
閱讀完整內容

[C#] Lambda花式應用噁爛寫法（跨UI委派秒幹、多線程處理...etc）

-
為啥會有這篇呢...因為最近寫太多C# 突然發現Lambda對程式碼減化太有幫助了=...= 為了怕哪天老人癡呆忘了這些噁心的花式寫法，就開一篇Blog文紀錄了 以前在寫多線程,可能得這麼寫： void Func() {/*多線程要做的事情*/} //接著呼叫： Thread nThread = new Thread(Func); nThread.Start(); 但今天用Lambda可以改寫： Thread nThread = new Thread(() => {/*多線程要做的事情*/}); nThread.Start(); 甚至在噁心點寫的寫法： new Thread(() => {/*多線程要做的事情*/}).Start(); 簡單來說Lambda的形式可拆解成： ()是指你的函數參數列、然後可用=>代表你要接的Lambda陳述句/塊，最後用{}把事情包起來。 在來就是比較討厭的C#內要做跨UI線程操控UI上物件，會有跨UI安全性線程問題， 所以一般會額外寫個委派函數，然後請求UI Thread去處理這個委派函數請求，才能控制 這樣往往可能只用一兩次的委派函數，卻要占用一個篇幅去寫委派函數 先看看正常的跨UI委派寫法： private delegate void nCallback(string ContentText); public void n(string ContentText) { if (this.InvokeRequired) { nCallback obj = new nCallback(n); this.Invoke(obj, new object[] { ContentText }); return; } this.Text = ContentText; } //調用時呼叫n("str") 就可以改寫成： this.Invoke(new Action(() => { this.Text = "Str"; })); 又因為=>後面可接陳述塊或者陳述句，所
閱讀完整內容

重建天堂之門：從 32 位元地獄一路打回天堂聖地（上）深度逆向工程 WOW64 設計

-
圖片
前言 這份研究是從去年底開始摸的，主因是一直對 Windows 如何實作 WOW64 兼容架構覺得有意思，並且坊間蠻多開源的天堂之門專案都死掉了 QQ 所以才打算自己完全重新逆向工程分析過一次。 逆向整個 WOW64 架構可以發現很多蠻有意思的問題，比方說 Intel 晶片指令集模式切換、記憶體模擬分配、WOW64 偽造的原生 32-bit 環境，例如 System32 在 32-bit 下會被重導向至 SysWOW64 到底在哪一層實作重導向的呢 ;)  此研究也運氣不錯分別被國內研討會 CYBERSEC 收錄為 《重建天堂之門：從 32bit 地獄一路打回天堂聖地》 與 HITB（Hack In The Box Security Conference）收錄為  《WoW Hell: Rebuilding Heavens Gate》 若對線上演講內容有興趣可以參考 Youtube 上 HITB 的直撥串流  HITB2021AMS D1T2 - WoW Hell: Rebuilding Heavens Gate - ShengHao Ma   不過我英文很破能不看就不看啦 由於整份演講內容想提的細節太多了，所以本部落格文拆成上下兩集。 當前本文是上集，會講述完整逆向工程整套微軟設計的 WOW64 架構怎麼設計的 。而下集《 重建天堂之門：從 32 位元地獄一路打回天堂聖地（下）攻擊篇：x96 Shellcode、天堂聖杯 ＆ 天堂注入器 》會著重在我今年發表出來的幾個有趣的攻擊點 :) 如果對天堂之門技術已經很熟的大佬，可以跳過本文看下一集了 <(_ _)> ＊注意＊ 本份研究在 2021/06/11 是基於 Windows 10 Enterprise 最新版本逆向工程結果所紀錄， 可能與讀者電腦中反編譯出來的結果有所出入是正常的 。筆者實測了同樣是 Windows 10 但不同組建版本在組合語言層級皆有些許差異，不過各個函數設計用途是固定且規律的、不會因版本而有所差異。 而整份研究不限但至少涉及了以下已知文獻，蠻值得一看的 2011 -  Mixing x86 with x64 code by ReWolf 2012 -  Knockin’ on Heaven’s Gate by george_nicolaou 2012 -  KERNEL: Cr
閱讀完整內容