Hao's Arsenal

前言 其實三年前就土炮過調試器了，不過最近要做碩論（？）會用到動態路徑分析所以又重新回頭來玩一些以前寫外掛用到的技能，而翻了一下繁體中文的文獻好像對這部分沒什麼提及就寫了一篇做一個簡單整理（主要是方便我以後回頭拿來當工具用XD） 本文實作做一個標準調試器自動下硬體斷點、然後修改暫存器內容再恢復執行緒運作，藉此來達成記憶體程式碼不破損情況下做到修改程式邏輯，完成自我進程防殺（防止工作管理員殺除） Debugger 在 Windows 進程權級分割下如果想除錯其他進程要先用  AdjustTokenPrivileges 拿取 SE_DEBUG 令牌，有了這張令牌就可以除錯其他進程（不過拿這張令牌要先過 UAC 就是）接著可以用 DebugActiveProcess 函數 attach 上對應你想動態除錯的進程、接著你除錯的進程就會被掛起成 DEBUG_MODE 接著執行緒會被排程跳到 DbgBreakPoint 上踩到 \xCC 然後就拋出一個異常可以讓 Debugger 接收負責接下來對應處理。 （所以一些殼在處理 anti-attach 主要就是在 DbgBreakPoint 上一個 hotpatch 去自殺） 而接下來 Debugger 負責做的處理就是一個無限迴圈：以  WaitForDebugEvent 向系統拿取當前被掛載進程的異常事件（這個概念有點像 Win32 視窗程式的 GetMessage 架構拿消息）當被掛載進程拋錯時候， WaitForDebugEvent 就可以拿到異常事件、Debugger 負責接手接下來的事情。 所以講到這邊原理就很淺而易見可以知道：如果外掛要修改邏輯（以除錯器模式實作）就會有很基礎的三種方式去讓程式執行到想攔截的函數時，就必須拋錯，主流方法就三種： int 3 讓 CPU 踩上去時候自動拋出異常 記憶體改成不可執行的分頁區讓 DEP 防護拋出異常 或者本文要講的硬體斷點手段 硬體斷點（DR0 → DR4） 可以查閱 wiki 知道： wiki/X86_debug_register ，總之 x86 CPU 提供了每個 Thread 有四個「當前正在除錯的地址」可以指示當 CPU 正在對某塊地址進行 讀/寫/執行 時「就必須拋錯」。那麼這四...

此篇內容接續著前幾篇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...

在Windows版上的LINE開啟後,如果使用Cheat Engine做進程掛接上去,會看到LINE直接崩潰掉. 先單看Windows提供的一組WinAPI怎麼建立Debugger機制: Win32 Debug API 原理 使用VS调试时，被调试进程如何被断下来的。 【原创】反OD调试的一些想法与实践 看完之後會知道Debugger的核心機制是: 1.創建進程(CreateProcess)使用 DEBUG_PROCESS這個Flag,此時該進程內的PEB中的 BeingDebugged Flag會被設為True ,呼叫完後,進成被創建完就會先是被凍結主線程(UI Thread)的進程了. 2.接著激活主線程後,WinNT消息機制發現了 BeingDebugged為True,就會主動調用 DbgBreakPoint API,在組語上遇到了int 3(0xCC)線程又會被凍結,然後會反彈一個 Create_PROCESS_DEBUG_EVENT訊息回去給父進程,給Debugger做事情. 3.如果Debugger想下新的Ring3層斷點,會先用CreateThread在指定進程中創線程,使此線程Call DbgUiRemoteBreakin,那麼指定進程內所有線程就會被Debugger掛起.那麼Debugger便可以對需要的指定記憶體段下int 3異常點. DbgUiRemoteBreakin內可以看到所有線程主動去Call  DbgBreakPoint來把當前線程控制權交給Debugger. 4.如果是進程已經被運行,Debugger才去Attach,則用到DebugActiveProcess去Attach指定進程,接著 BeingDebugged又會被設為True,然後做異常機制的掛起線程. 最後我比較好奇的是 DbgUserBreakPoint函數內寫法跟DbgBreakPoint其實一模一樣,我不太懂微軟幹嘛把同個功能寫成兩個不同的API? 接著總結一下 所以一般Ring3層需要防Debugger可能會防止 1.自身 DbgBreakPoint被呼叫.(只要此函數呼叫了便把控制權交出去了) 2. 自身 DbgUserBreakPoint 被呼叫...