[Windows][PE][ASM][CE]從PE架構淺談純組語撈出當前進程的映像路徑

-
近日很少發發廢文啊XD，大學生各種忙碌期中考
最近觀書有感，來發發拆拆手札廢文

參考文獻
  1. 緩衝區溢位攻擊：第三章 - 改變程式執行的行為
  2. MSDN - PEB structure
  3. MSDN -  RTL_USER_PROCESS_PARAMETERS structure
  4. MSDN - UNICODE_STRING structure
懶人包：
每個Process中都會存在一個TEB結構體
偷偷引用一下文章中的結構：
typedef struct _TEB
{
        NT_TIB                  Tib;// Offset = 0x00
        PVOID                   EnvironmentPointer;
        CLIENT_ID               Cid;
        PVOID                   ActiveRpcInfo;
        PVOID                   ThreadLocalStoragePointer;
        PPEB                    Peb;
        ULONG                   LastErrorValue;
        ULONG                   CountOfOwnedCriticalSections;
        PVOID                   CsrClientThread;
        PVOID                   Win32ThreadInfo;
        ULONG                   Win32ClientInfo[0x1F];
        PVOID                   WOW32Reserved;
        ULONG                   CurrentLocale;
        ULONG                   FpSoftwareStatusRegister;
        PVOID                   SystemReserved1[0x36];
        PVOID                   Spare1;
        ULONG                   ExceptionCode;
        ULONG                   SpareBytes1[0x28];
        PVOID                   SystemReserved2[0xA];
        ULONG                   GdiRgn;
        ULONG                   GdiPen;
        ULONG                   GdiBrush;
        CLIENT_ID               RealClientId;
        PVOID                   GdiCachedProcessHandle;
        ULONG                   GdiClientPID;
        ULONG                   GdiClientTID;
        PVOID                   GdiThreadLocaleInfo;
        PVOID                   UserReserved[5];
        PVOID                   GlDispatchTable[0x118];
        ULONG                   GlReserved1[0x1A];
        PVOID                   GlReserved2;
        PVOID                   GlSectionInfo;
        PVOID                   GlSection;
        PVOID                   GlTable;
        PVOID                   GlCurrentRC;
        PVOID                   GlContext;
        NTSTATUS                LastStatusValue;
        UNICODE_STRING          StaticUnicodeString;
        WCHAR                   StaticUnicodeBuffer[0x105];
        PVOID                   DeallocationStack;
        PVOID                   TlsSlots[0x40];
        LIST_ENTRY              TlsLinks;
        PVOID                   Vdm;
        PVOID                   ReservedForNtRpc;
        PVOID                   DbgSsReserved[0x2];
        ULONG                   HardErrorDisabled;
        PVOID                   Instrumentation[0x10];
        PVOID                   WinSockData;
        ULONG                   GdiBatchCount;
        ULONG                   Spare2;
        ULONG                   Spare3;
        ULONG                   Spare4;
        PVOID                   ReservedForOle;
        ULONG                   WaitingOnLoaderLock;
        PVOID                   StackCommit;
        PVOID                   StackCommitMax;
        PVOID                   StackReserved;
} TEB, *PTEB;

每個Process中的TEB會存放這支Process中運行的環境、Process的屬性、或者大家Coding會用的Try的偵錯機制處理...等，不過今天我要先講的是映像路徑（ImagePath）的擷取，所以現在著重的重點放在Offset = 0x30上的PEB（Process Environment Block）上，裡面會存放許多關於當前進程的屬性資料；而如果是研究BufferOverflow則對Offset = 0x00上的NT_TIB很熟悉了（內含WIN處理錯誤機制屬性處理的資料）

那麼今天我們要取的映像路徑會放在哪？查了一下資料會得知放在PEB內的ProcessParameters結構體內的ImagePathName指標（以UnicodeString做存放）

參考了一下MSDN上微軟官方對PEB的定義如下：
typedef struct _PEB {
  BYTE                          Reserved1[2];//0x00
  BYTE                          BeingDebugged;//0x00 + 1 *2 = 0x02
  BYTE                          Reserved2[1];//0x02 + 1 = 0x03
  PVOID                         Reserved3[2];//0x03 + 1 = 0x04
  PPEB_LDR_DATA                 Ldr;//0x04 + 4 *2 = 0x0C
  PRTL_USER_PROCESS_PARAMETERS  ProcessParameters;//0x0C + 4 = 0x10
  BYTE                          Reserved4[104];
  PVOID                         Reserved5[52];
  PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine;
  BYTE                          Reserved6[128];
  PVOID                         Reserved7[1];
  ULONG                         SessionId;
} PEB, *PPEB;
可以參考一下我補上的Offset，要從PEB結構體爬到ProcessParameters的指標Offset算法會是：BYTE*2 + BYTE + BYTE + PVOID*2 + PPEB_LDA_DATA = 0x10

接著可以在參考一下MSDN上的ProcessParameters（在Windows的.h頭文件內定義是_RTL_USER_PROCESS_PARAMETERS）結構體定義：
typedef struct _RTL_USER_PROCESS_PARAMETERS {
  BYTE           Reserved1[16];//0x00
  PVOID          Reserved2[10];//0x00 + 1 * 16 = 0x10
  UNICODE_STRING ImagePathName;//0x10 + 4 * 10 = 0x38
  UNICODE_STRING CommandLine;
} RTL_USER_PROCESS_PARAMETERS, *PRTL_USER_PROCESS_PARAMETERS;
接著看到這個結構體上我補上的Offset，一路從ProcessParameters結構體爬到ImagePathName指針的Offset就會是 BYTE*16 + PVOID*10 = 0x38

所以這邊我用了Cheat Engine的AutoASM寫了一個簡單的彙編腳本：
alloc(Func,128)
alloc(GetPtr,4)
createthread(Func)
registersymbol(GetPtr)

Func:
mov eax, fs:[30]//eax = fs[30] = PEB_address.
mov eax,[eax+10]//eax = fs[30] + ProcessParameters_offset.
add eax,38      //eax = ProcessParametersAddress + ImagePath_offset.
mov [GetPtr],eax
ret
跑起來像這樣；
 這邊我在Win7 x32bit下對記事本(notepad.exe)的進程做鎖定，執行了我寫的腳本後，可以去看到GetPtr取到地址為0x00231A90，這是什麼呢？這就會是UnicodeString的結構了（存放ImagePath文字）

可以查一下MSDN上的UNICODE_STRING結構體如下：
typedef struct _LSA_UNICODE_STRING {
  USHORT Length;//0x00
  USHORT MaximumLength;//0x00 + 2 = 0x02
  PWSTR  Buffer;//0x02 + 2 = 0x04
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;
這邊可以得知我們的UncodeString上有兩個Buffer（以Short為單位，意味著其實UncodeString在Windows上最大只能到16*16 = 256單位長）才會是指向文字內容的指針

所以我們就可以得知找到文字的指針加上0x04的Offset就可以成功指向文字了
操作如下：
在Cheat Engine介面下新增Pointer，地址填寫GetPtr（或者填寫0x00231A90）然後Offset填寫0x04：
 嘿嘿，成功找到ImagePath的結構體上指向的Buffer指針囉，指針地址為0x0023271A
接著就可以看到進程的ImagePath存放的路徑囉，如下：
 Got It！

留言

張貼留言

這個網誌中的熱門文章

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