Hao's Arsenal

本文靈感來自專拆OSX的大神發布的影片 不過我沒有用OTX那個工具也不想記Hex & Opcode的轉換XD 這邊我選擇使用Hopper Disassembler v3版本作為整個破解手法的核心工具 另外，影片中有用簽章工具去重簽，但我沒有XD，如果你很執著想讓破解完後的軟體可以跑在別人的OSX環境上（沒有開啟允許非Apple Store的選項狀況下）還是得做重新簽章的動作唷 已購買拔除驗證的程式 有跟那個大神要來了同樣的一支程式拔掉了Recept檔案（內紀錄了Mac碼、購買人資訊...等）。跟大神要回來的檔案開啟後會像這樣： 在影片中提及173（0xAD）就是當開發者使用Apple Store提供的Framework時發現驗證檔案有問題時會用173這個編號當作訊息回覆給系統然後call exit來結束程式，程式結束後OSX系統就會顯示如上圖的訊息來告知使用者這個程式不可使用。 分析過程 這邊我選用Hopper Disassembler v3來開啟這個軟體中的exec（核心執行文件） 接著Hopper就會幫你停在EP這邊囉。 那麼接下來怎麼找到程式在做檢測是否有問題來發送173並且退出的點？ 這邊我使用了Hopper內的搜尋（command+F）然後搜尋0xAD。 可以看到第一個找到的點在這裡0x100029db0，接著後面call了got__objc_msgSend 這就是第一個檢測點，而且應該是程式內開發者自己設計的檢測點 這邊使用Hopper內的反組譯功能可以看到這段回推obj-c程式碼如下： 反白處為我們找到的第一個173訊號設定點，這邊開發者使用了FileExistsAtPath的API做呼叫，如果返回值是0（購買權限檔案不存在）便會回傳173訊息給系統。 所以為了阻止這種惡劣的打小報告行為（？）我在0x100029da5上的test al,al這邊做的一個BYTE的檢測之後有個jne  0x100029dbe下一個強跳，就可以避免開發者設計的173回傳回去給系統了，使用Hopper內建的Assembler Instruction功能修改為jmp就可以了。 接著我們繼續搜索0xAD可以看到第二個點： 在0x1000f4aa6這個函...

此篇內容接續著前幾篇Blog文： 從PE架構淺談純組語撈出當前進程的映像路徑  從PE架構到模組架構到暴力列舉模組找模組位置（如Kernel32.dll）  純組語手幹Dll Header解析外導函數表撈出函數地址（如LoadLibraryA動態地址）  你知道聽歌也會中毒嗎？初探BOF攻擊、KMPlayer MP3漏洞利用 參考文獻 緩衝區溢位攻擊：第四章 - 真槍實彈  緩衝區溢位攻擊：第五章 - 攻擊的變化 最近時間很緊湊啊...還是慢慢看這本電子書內容，挑出一點細節還有大概的精華整理成自己的筆記了XD，因為這部分技術很繁瑣又很多細項，所以筆記都是整理給自己看怕自己老人癡呆忘記用的（？），如果是大牛們請飄過吧(´･_･`) ＊PS：此篇文章實做測試於Windows XP SP3版本上，若使用Vista或者更高版本將可能遇到DEP防護導致Shellcode屬性不可被執行而無法成功攻擊唷XD 首先，SEH是什麼？ SEH全名為Structured Exception Handling，在MSDN上可以查到微軟官方提供的資訊在此： Structured Exception Handling (Windows) - MSDN - Microsoft ，當你正在使用的程式遇到異外情形是不合乎邏輯或者違法處置的時候，程式無法自己處理，一般來說會先給try處理（而try的註冊資訊也會註冊於SEH鏈結內）當try內也無法處理掉時會交由Debugger處理，若Debugger也無法處理時（或者當下沒有被Debugger Attach時），最後就會把處理權交由系統來做處理（如下圖所示） 系統就會根據當下環境整理出記憶體傾印資訊，然後問你要不要回傳給開發者，或者要選擇手動處理這個問題（不過我沒用過上面任何一個功能就是了XD） 那麼SEH在Windows上是怎麼運作的呢？ 可以之前我寫的本系列文章的第一篇 從PE架構淺談純組語撈出當前進程的映像路徑  ，當初在介紹每個線程中都有個TEB結構體（Thread Environment Block），而線程會根據被分配的ASM Script一直做一個個Opcode解析並且執行的動作。 但如果哪天解析Opcod...

小小的紀錄一下MPRESS殼的手脫過程 前情提要： 因為朋友正在分析一支電腦裡野生長出來的軟體，但是看它筋骨奇特，深深覺得絕非善類，肯定是會咬人的壞東西，丟到IDA，IDA也胃口不好。用PEID照妖鏡一看原來外面有戴套，是層MPRESS的殼還蠻冷門的，於是朋友就把這奇形怪貌的東西丟給我脫殼惹 .___. 但是因為我先前根本沒有脫殼過，有的話...我之前脫過UPX算嗎（？） 初探手工脫UPX殼（IAT修復Dump＋ESP定律找OEP），學學如何幫程式脫殼裸奔 (不過這篇也只是練習脫UPX殼而已啦XD） 後來Google了一下MPRESS有找到國外相關資料： Unpacking mpress’ed PE+ DLLs with the Bochs plugin ，於是可以得知一些資訊來做脫殼惹 首先，用OD載入這鬼東西， OD會問要不要解壓縮資料請選擇是， 然後讓OD幫我們斷在入口點上： 再來就是一連串繁瑣無聊的把資源解壓縮出來的演算法 一路F8越過，直到遇到底下這裡： 花點時間跟蹤到這邊會發現資源就解壓縮得差不多了，都釋放到記憶體了 繼續單步跟蹤進去： Jmp進去的第一層跑到這裡眼尖的人會發現Stack上Heap區多了關於原始程序模塊的基址 不過其實這跟脫殼要的資訊沒太大關係啦...順帶提一下XD 然後繼續越過跟蹤下去： 到這個特徵會看到一個call，如果你用越過（F8）會發現在那邊卡很久 這邊我們用F7單步跟蹤進去： 江江江江～原來call進來的地方第一句就是call GetModuleHandleA 聽起來超熟悉的啊，配合底下GetProcAddress雙函數迴圈處理， 原來這邊就是開始還原IAT的處理 應該是對應到國外那篇文章裡面的UnPack函數 接著我們花點時間往下翻翻翻可以翻到： 這邊做popad恢復了stack環境，然後做了一個大跳躍回到OEP了 單步跟蹤進去，如下圖： 漂亮的OEP裸體在我們眼前了，紀錄一下OEP位置0x0041F070 然後用內建的OllyDump設置OEP為0x0041F070，修一下IAT就脫殼完成囉！

此篇內容接續著前幾篇Blog文： 從PE架構淺談純組語撈出當前進程的映像路徑  從PE架構到模組架構到暴力列舉模組找模組位置（如Kernel32.dll）  純組語手幹Dll Header解析外導函數表撈出函數地址（如LoadLibraryA動態地址） 參考文獻 緩衝區溢位攻擊：第四章 - 真槍實彈  我知道這個標題有點聳動，其實沒到那麼可怕啦XD 呼...我終於看到第四章節了T^T，一樣是雷雷的筆記文章，另外，這篇文章特別感謝Orange大神在我找不到BUG在哪的時候伸出援手替我解圍啊啊啊啊啊 這邊要寫的筆記是 緩衝區溢位攻擊：第四章 - 真槍實彈 文中提及的KMPlayer 1440版中關於MP3的漏洞，在KMPlayer 1440版中針對MP3音樂檔案文件做解析時會有存在Buffer Overflow（BOF）的問題，以下紀錄我自己在探究這個漏洞利用、練習時的逐步思路跟概念，到最後寫出一個可以利用漏洞來引發攻擊者想做的惡意事情，卻是透過MP3音樂文件做觸發。 如果正在看文章的你還沒有下載KMPlayer 1440有漏洞的版本，可以在這裡下載： KMPlayer 3.0.0.1440 萬能影音播放器 綠色免安裝 中文版&110套面板 （我是下載免安裝版，我也是在這裡下載的XD） 首先，得知MP3文件在解析時會有存在BOF問題，可以先用mona引擎替我們生產一組Pattern來做測試，看看實際在哪個點引發出錯進而分析如何做攻擊，開啟Immunity Debugger下命令：!mona pattern_create 10000 它會替我們生產一個10000個字長度的Pattern，另外， 特別記得在VISTA、WIN7除錯器記得要以工作管理員運行...XD，剛剛被雷過  接著可以在Immunity Debugger底下發現一個Pattern.txt文件：  接著可以看到mona替我們生產出一組Pattern長度為10000長度的文字，將ASCII段內的文字複製起來，另外以記事本開新檔案將ASCII段內的所有文字複製後保存進去新的文字檔，命名為adr.mp3  接著如果你把adr.mp3丟給KMPlayer.exe執行，會發現狀況如下： ...

此篇內容接續著前幾篇Blog文： 從PE架構淺談純組語撈出當前進程的映像路徑  從PE架構到模組架構到暴力列舉模組找模組位置（如Kernel32.dll） 參考文獻 緩衝區溢位攻擊：第三章 - 改變程式執行的行為 今天如果已經能找出進程中模組內容、列舉模組，但是模組並不是我們需要的直接呼叫的目標（應該說我們想找出模組資料、細節，就是為了內部的函數來做呼叫），所以今天我們的目標是用組語透過模組的資料結構來分析一個動態記憶體中的DLL Library的模組陣列結構、進一步來做篩選出我們要的函數地址在哪裡（如LoadLibraryA在進程中的哪個位置上） 首先可以去翻翻DLL在Windows從DLL頭開始會有DOS Header、NT Header、各區段節..等 可以參考 緩衝區溢位攻擊：第三章 - 改變程式執行的行為 中的圖： 而我們要找一個DLL中有哪些函數可以給我們引用，例如說：Kernel32中的OpenProcess、GetCurrentThreadId、LoadLibraryA...等。這些函數都被稱之為導出函數（Export Function），也就是該DLL願意分享出去給其他使用者去調用其中的函數。 在這張圖上我們清楚看到整個DLL中第一個區段（也就是在Offset = 0的時候）為DOS Header，也就是說，整個DLL架構中我唯一能確定的資料結構就是DOS Header，所以可以先看一下DOS Header的結構如下： typedef struct _IMAGE_DOS_HEADER { // DOS .EXE header WORD e_magic; // Magic number WORD e_cblp; // Bytes on last page of file WORD e_cp; // Pages in file WORD e_crlc; // Relocations WORD e_cparhdr; // Size of h...