[OSX][ASM]初探Mac OSX軟件爆破（GDB遠程調試＋反匯編＋打補丁）

-
為什麼會有這篇文產生呢，
純粹因為一直很想摸OSX的App逆向
不過又沒有入門
對岸跟台灣基本上根本沒有文章可以參考...變得入門很難
去找了幾篇國外原文然後花一兩個小時摸摸～這篇算是簡略心得文（？）

是說破完之後發現其實OSX幾乎呈現0保護狀態耶XD
OSX的軟體都還蠻好破解的...
不像MicroSoft被一堆大牛們破解到怕了XD所以Windows超多防護機制
（也很多廠商推出混淆、虛擬機...等手法來反破解這樣）

本身有Windows逆向工程底子的人來摸其實還蠻快就上手惹
會覺得OSX之後會不會像多多鳥一樣很可愛、然後變成下一個Windows的命運XD?
＿＿＿＿＿＿＿＿＿＿＿＿我是分割線＿＿＿＿＿＿＿＿＿＿＿＿
所以這算是筆記吧（？）
在逆向之前總得有個可憐的孩子被逆向，
不過因為我很菜...不會醜到爆的Obj-C、噁爛的Swift（它真的看起來超像Shift的）
所以我這邊是用C++Builder的跨平台FireMonkey專案開發了一支小App做測試

首先我在VM內寫Code
設計超級他媽簡單...就只有一個按鈕
按鈕內響應的事件：
整個做的事情非常簡單。把a的值設為1，b的值設為2
假設a跟b相等則彈出“Happy”的視窗；若不相等則彈出“Angry"的視窗。
不過因為a跟b本來就永遠都不可能相等所以永遠都只會彈出angryangryangryangryangryangryangryangryangryangryangryangryangryangry

接著用Xcode跟VM的C++Builder遠程連機然後編譯：
長出了一個野生的視窗，上面的按鈕按下去，視窗永遠看起來很生氣的樣子

接著就是調適的部分了
我這邊用的是Hopper Dissasmbler付(ㄆㄛˋ)費(ㄐㄧㄝˇ)版
不要跟我要，網路上找一下就有惹XD
接著載入今天主角...翻了一下它的外導函數很快就可以找到Button_Click的事件惹
（不要問我為啥外導函數這麼醜，去問問CBuilder官方T__T，CBuilder生產出來的東西外導函數都很ㄐㄅ醜）

接著可以看到Button_Click的asm Code怎麼跑的
不過Hopper的反匯編能力還不錯，可以幫你把asm逆推回C++ Code看邏輯怎麼跑
如果你的asm功力頗菜可以參考一下XD
可以從反匯編上看到雖然我們C++ Builder的Source寫得很簡單
不過在程式被編譯完後asm是這麼跑的：
先把var_m12賦予值 = 1 （變數a）、var_m16賦予值 = 2 （變數b）
接著比對如果var_m12跟var_m16相等，則把暫存器EDX設為0x2bd32
若兩者不相等則設為0x2bd38（這兩者其實就是"Angry"跟"Happy"的文字記憶體位置）
最後再透過@System@UnicodeString API（我猜是CBuilder官方自己搞出來的函數）把var_m20的文字從EDX位置上Copy進去，最後才透過Fmx@Dialogs@ShowMessage API把文字給彈出來

然後在Button_Click事件上下斷點（F9）
這邊比較特別的是
例如說Cheat Engine下斷點是F5 單步F7 躍過F8 執行F9
OD是斷點F2 單步F7 躍過F8 執行F9
不過Hopper是斷點F9 單步F7 躍過F8 執行F5

然後使用GDB遠程CreateProcess
是說這邊蠻哭爸的事情是...GDB一開始初始化好像不會幫你在Entry下一個暫停
所以UI會直接彈出來，沒有讓你去跟蹤Entry怎麼跑的
然後我們去按那個超大粒的按鈕，就會觸發Debugger訊息傳回GDB然後暫停
（而且速度超慢der...不知道他們怎麼通訊的，Windows底下OD、CE在調適都超快）

然後GDB Catch到Debugger Event之後，就可以用F7F7F7F7F7F7跟蹤啦～
接著跟蹤到底下很快就可以看到asm code這邊對兩個記憶體變數做比對
不相等就跳到0x14b5f做"Angry"文字記憶體位置導到EDX內，否則就繼續跑到0x14b57做導入"Happy"文字記憶體位置到EDX內

接著底下繼續跑就會處理ShowMessage()函數的呼叫了
我們可以看一下GDB跑到JNE上的時候的EIP
這時候如果我們幫它把即將閱讀的0x14b55改為0x14b57
在GDB上把EIP改為0x14b57之後可以看到Hopper同步讀取點跳到了0x14b57
成功繞掉了JNE那行了～按F5跑跑看

看見視窗很開心的說Happy惹
所以很明顯今天要幹的事情就是把跳入0x14b5f給取消掉
幫它補上兩個nop（原本JNE是短跳所以佔用兩個BYTE）

最後測試一下，ＯＫ，沒問題
把Patch好的執行擋用Hopper生出來，然後塞回去原本的程式裡面

留言

張貼留言

這個網誌中的熱門文章

[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 等等。我們剛剛提到了其導出函數 _
閱讀完整內容