初探手工脫UPX殼（IAT修復Dump＋ESP定律找OEP），學學如何幫程式脫殼裸奔

-
這是個人練習UPX脫殼的筆記文XD
本來就對脫殼技術蠻有興趣der，直到最近才開始練T___T

後繼心得：
自己手脫過一次殼過後才能體會為啥問過某些大佬能不能脫Themida那種殼帶肉的殼
會被以一種“你沒見過世面膩”的眼神翻白眼XDDDDDDDDDD



本次欠脫殼的程式載點在這
內有一個UnPackedApp.exe是原始exe
還有一個PackedApp.exe是加過UPX殼的exe

首先用CBuilder寫了個只有窗體的exe
不過因為是第一次玩脫殼
所以用了最好脫的殼做練習 UPX壓縮殼

ok，本日主角就這樣誕生惹
首先先看看原本剛編譯好的exe的入口（OEP）：
是很標準的C++ Builder的入口 :)

接著看看UPX加殼過後的入口：
會先做一個pushad保護堆疊，然後進入UPX的解壓縮資源步驟
接著往下翻一下很快就會看到很多UPX解壓縮的過程，最後來到這裡有個popad
去把剛剛pushad推入的東西做一個推出，恢復堆疊
然後jmp PackedAp.004021B8這邊就是回到原本C++ Builder的標準OEP了

既然找到OEP，那該怎麼把UPX脫掉？
剛剛在執行步驟中可以很明顯看到，UPX會先做一個pushad
保護當前ESP資源不受破壞，接著做一系列的解壓縮資源到內存中，
解壓縮完畢後會再做一個popad把ESP做還原，然後jmp入C++ Builder的OEP

所以，執行到004021B8這邊開始就是進入C++ Builder的標準程序了
從這邊開始，使用OllyDump開始做dump內存
這邊設定一下入口地址OEP從0x3CD1F0（也就是0x7CD1F0一開始看到的pushad）
修正為：0x21B8（也就現在看到的0x4021B8）

接著這邊有件神奇的事情要說，一般VC++之類的exe勾選重建輸入表然後按下脫殼好像就可以全自動修復IAT了，不過...C++ Builder套殼後不管是ollyDump或者是大名鼎鼎的ImportREC 1.6版本、1.7版本，通通沒辦法修IAT，這些主流工具通通無法辨識C++ Builder的IAT (　ﾟдﾟ)

所以接下來因為要介紹另套工具修IAT，所以這邊OllyDump在做Dump的時候請記得把重建輸入表的選項給勾勾取消，然後按下脫殼，並且找好地方做儲存

接下來要介紹的工具是這套，Layz大大介紹的神器 Scylla 海妖<(_ _)>
在GitHub上是開源的修IAT的工具，猛猛der...可以修C++ Builder的IAT

它的核心概念是把正在執行的Process的IAT表分析完之後，
再轉存入Dump內做修復Dump的工作
所以我們得先鎖定正在執行的Process，然後填入我們找到的原始OEP，按下IAT AutoSearch它會自動搜索出整個IAT導入表的資料，如果成功就會回應一個上圖的訊息

接著按Get Imports就可以針對IAT再做細部的每個API搜索Offset算出來整個IAT所有結構體跟Offset的關係，最後按下Fix Dump按鈕去選擇我們剛剛用OllyDump出來的東西就可以替我們修復惹

最後，這是成功效果圖ㄧ覽
123.exe是用OllyDump做轉存出來的，沒有修正IAT不能執行
然後123.exe經由Scylla修正後會產生一個123_scy.exe的檔案，這個雙擊兩下就可以正確執行惹！用PEID查一下的確已經沒有UPX殼了，成功去殼啦～～

接下來是比較有疑問的地方是：

那如果我不知道popad在哪不就找不到原始OEP了嗎
這就要提學脫殼必學的ESP定律找OEP惹
首先我們都知道的是正常程式被Windows開啟時是這樣的：
[Windows創建進程]->[給予一個合法可用的ESP地址]->[接著從OEP開始跑]

不過如果套殼之後，會是：
[Windows創建進程]->[給予一個合法可用的ESP地址]
->[做一次pushad避免殼在解壓縮時破壞Stack的內容]->[先跑殼的解壓縮流程]
->[最後還原原本的ESP內容到當前的ESP+0上的內容]
->[popad恢復Stack]->[從原始OEP開始跑]

所以我們知道一定在殼解壓縮過程中會需要使用到那個空白地址[ESP+0]來做恢復Stack還原ESP現場的動作，那就可以很快的找到原始ESP地址

以下拿剛剛同一隻UPX加殼後的程式做操作
首先一樣從殼的入口開始看，先用F8單步過pushad，會看到原始ESP是0x12FF8C（Windows給的）經過了pushad後，Stack上會多了8個WORD大小的資料（也就是偏移了8x4 = 32的地址）

所以我們可以確定最後0x12FF6C就會是還原現場時的ESP+0必須做還原
所以這邊我們先跳到0x12FF6C下一個硬斷
（或者你也可以挑0x12FFA8、AC、B0...etc只要介於ESP+0～原始ESP就可以惹）
下好硬斷後就可以按F9 Let it go～
很快就可以看到OD跟蹤到了popad這個點
主要是popad釋放掉了ESP上的8個DWORD觸發了我們下的硬斷存取的事件
接著單步跟蹤下去
於是很快就可以跟蹤到原始OEP囉

留言

張貼留言

這個網誌中的熱門文章

[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"; })); 又因為=>後面可接陳述塊或者陳述句，所
閱讀完整內容

[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! 實際擺攤的時候，對你工具有興
閱讀完整內容

[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 下通常取得參數通常分為兩種狀況：  WINAPI GetCommandLineW() 系統函數返回字串指針指向當前完整應用程式參數 從 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 等等。我們剛剛提到了其導出函數 _
閱讀完整內容