文章

精選

[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 等等。我們剛剛提到了其導出函數 __getmainargs() 負責解析。事實上這個函數內部實作也只是把它全域變數所記…

Process Hidden In Just one line code (Windows)

圖片
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 as the new fi…

[Windows] [Debug] 記憶體無痕鉤子 - 硬體斷點 (C++) 實作 Ring3 進程防殺

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

對 Windows 10 UAC 保護實作細節逆向工程 (Windows 10 Enterprise 17763)

圖片
- 前言 啊啊,真的蠻久沒更新的,部落格荒廢一陣子。🥴 身為一個碩一升碩二,畢業即失業的我最近開始想動手玩一些有趣的東西(不然畢業後投履歷沒東西寫可能真的要餓死街頭了怕爆 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,這也代表著系統開機後會有一個 Process 施作 UAC 細節。
在 WinInit 服務叫起的 Services…

Linux ELF Loader Note

之前玩 ELF 一直不懂為啥 _start 走進去後居然是去呼叫:
__libc_start_main(main, __libc_csu_init, __libc_csu_fini)

然後莫名其妙的就走進去 main function 了;有別於 Windows PE _start 進去後就是初始化 CRT 接著呼叫 exit(main(argc, argv, envp))。

看完 [1], [2] 之後大概就可以知道:

1. __libc_start_main 在於 Process 中程式文件被 Mapping 到正確記憶體分配後,負責處理一些初始化的作業,比方說有用到第三方函數庫或全域變數初始化等等都會負責呼叫 __libc_csu_init 來協助完成這些初始化作業(實際初始化方式也僅是透過 ELF 自帶的 .init section 程式碼呼叫、其他第三方函數庫家載後 .init 也得呼叫)

2. __libc_start_main 完成初始化後透過 .plt 來呼叫系統函數來取得 argc, argv, envp 作為參數傳遞給開發者的 main 函數

3. 等待開發者 main 函數返回後,在跳至 .fini section 的程式碼做一些後續關閉 Process 必要的清理作業(比方說記憶體回收之類的)

感覺上大概就是把 Windows 編譯器產出的 CRTStartup 這件事情封裝在 glibc 內分成三塊來處理XD

[1]: https://blog.csdn.net/gary_ygl/article/details/8506007
[2]: https://stackoverflow.com/…/whats-going-on-in-libc-start-ma…
[3]: https://felixzhang00.github.io/2016/12/24/2016-12-24-ELF%E6%96%87%E4%BB%B6%E8%A3%85%E8%BD%BD%E9%93%BE%E6%8E%A5%E8%BF%87%E7%A8%8B%E5%8F%8Ahook%E5%8E%9F%E7%90%86/

[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!


實際擺攤的時候,對你工具有興趣想聽的會在你攤位開始的時間前面卡位等著,然後看…