Hao's Arsenal

Hi there! It was an interesting case I found accidentally when building a C program to do self-update. For a Windows Programmer, it's nature to consider about using Win32 API -- MoveFileA to rename or move a file: And the interesting thing is, this API allowed us to use in the dynamic state. In other words, Windows kernel allows you to change your *.exe file name even when your program runs, or moves your self to the other directories. So I got curiosity what whould happen if the *.exe file name was not matched static file name (stored in PEB) First, I tried to change current file name when the program ran, and the result is as follow: In process explorer, the program name was displayed as the name written into PEB when file mapping. It can be found that process explorer shows process name by the file name recorded by PEB. But how is it in task manager? Task manager lists all process name with Win32 API -- EnumProcesses (I guess so), so the process name will be shown

前言 其實三年前就土炮過調試器了，不過最近要做碩論（？）會用到動態路徑分析所以又重新回頭來玩一些以前寫外掛用到的技能，而翻了一下繁體中文的文獻好像對這部分沒什麼提及就寫了一篇做一個簡單整理（主要是方便我以後回頭拿來當工具用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 正在對某塊地址進行 讀/寫/執行 時「就必須拋錯」。那麼這四個地址就分別放在

- 前言 啊啊，真的蠻久沒更新的，部落格荒廢一陣子。🥴 身為一個碩一升碩二，畢業即失業的我最近開始想動手玩一些有趣的東西（不然畢業後投履歷沒東西寫可能真的要餓死街頭了怕爆 QQ） 年初看了這一篇挺有趣的文章由 David Wells 所發表的部落格文   UAC Bypass by Mocking Trusted Directories  裡面提及了在 Windows 10 Build 17134 版本中出現的  Path Normalization  在 WinNT 跟實際 DOS Path 絕對路徑產生的歧異所引發安全上的缺陷允許繞過 UAC 設計。 不過這一篇文章只講到了其中一個利用點、經過完整逆向後發現一些有趣的資訊有其他打法可以利用，身為只會刷水稿的我，運氣不錯今年刷刷水稿有丟上 HITCON (｡･ω･｡)ﾉ 喔拜託，如果有打算到現場的不要噓我 QQ 怕爆.jpg 而  整體 UAC（User Account Control）保護設計在網路上也未被多加著墨 （至少當前沒有太多逆向工程細節 XD）所以興致來了寫了一篇廢文解釋一下整體逆向工程完畢後對 Windows 10 當前最新企業版設計做出一些解釋。 // 附註 整體 UAC（User Account Control）實作其實相當精細，其中包含了本地端 RPC 消息傳遞、微軟官方未公布的一堆MACRO標記與結構體、Windows特權令牌分發細節 等。礙於本人逆向功力不足、與網路上可爬到的未公布資料實在太少，底下許多提到的數字細節都是我根據當下程式碼結構上臆測的結果而無法考證微軟內部程式碼，若有錯誤麻煩再回覆告知。 此外，本文所描述的逆向分析結果都在於認證機制層面上、但許多程式碼跳轉部分其實 RPC 消息傳遞影響的成分相當重、但本文為了簡化整體架構方便釐清、那些特殊影響邏輯跳轉的 RPC 消息邏輯暫且不提。 - Environment  截至今日  2019/07/27 目前分析環境為 Windows 10, 17763 企業版，更新補丁上到最新版本。 - SVCHOST UAC 保護設計在 Windows 中是以系統服務形式被安裝在作業系統之上，在這邊可以看到 UAC 服務名稱對應是 AppInfo，這也代表著系統開機後會有一個