Hao's Arsenal

 WOW64逆向工程 在前一篇部落格文  重建天堂之門：從 32 位元地獄一路打回天堂聖地（上）深度逆向工程 WOW64 設計  筆者已經以逆向工程角度完整解釋了微軟這套幫助 32-bit 在原生 64-bit Windows 執行之架構的設計 若讀者尚未有研究過天堂之門相關基礎、建議先回到上一篇文通讀後再回來本文閱讀。而接下來我們會把焦點圍繞在接續著如何將上一篇的背景知識組合出一些有趣的利用手法 :) x96 Shellcode 這是我覺得最有趣的一個玩法XD 通過逆向工程 WOW64 架構後，發現了通過 cs segment 區段暫存器值 23h 或 33h、得以確認當下 Intel 晶片正在將 program counter 上的程式碼以 32-bit 或 64-bit 指令集解析。 因此藉由此區段暫存器值，我們也能創建出一個 x96 shellcode、亦即同時可當作 32-bit 也可當作 64-bit 的 shellcode！設計概念相當簡單，便是在 shellcode 開頭處 設計一個彈頭 ：判斷當前 cs segment 值若為 23h 則跳去 32-bit shellcode 執行、反之是 33h 則跳去 64-bit shellcode 接續著執行。 講得簡單，設計起來實務麻煩點其實是確保 x96 彈頭 payload 在 32/64-bit 下解析起來的邏輯是一致的，比方 shellcode 相對偏移定址問題、32/64-bit 的指令 alignment 不對稱，或者連 branch jump 指令 offset 在兩指令集上算法超過 2 bytes 也會有問題 等。 所以在上面 PoC 中可以看到，彈頭中所有的指令 opcode 都特別挑選過是在兩種架構上皆相同的、才可確保在兩指令集上邏輯按照預期執行，舉例： call $+5 同樣是 \xE8\x00\x00\x00\x00 其在 64-bit 下會以 8 bytes 長度推入 return address 上堆疊，而在 32-bit 下僅推入 4 bytes 長度上堆疊 \x81\x04\x24 其在 32-bit 下被視作 add ds: [esp], xxxx。而在 64-bit 下會被自動擴展為 add ds: [rsp], xxxx 而挑選使...

前言 這份研究是從去年底開始摸的，主因是一直對 Windows 如何實作 WOW64 兼容架構覺得有意思，並且坊間蠻多開源的天堂之門專案都死掉了 QQ 所以才打算自己完全重新逆向工程分析過一次。 逆向整個 WOW64 架構可以發現很多蠻有意思的問題，比方說 Intel 晶片指令集模式切換、記憶體模擬分配、WOW64 偽造的原生 32-bit 環境，例如 System32 在 32-bit 下會被重導向至 SysWOW64 到底在哪一層實作重導向的呢 ;)  此研究也運氣不錯分別被國內研討會 CYBERSEC 收錄為 《重建天堂之門：從 32bit 地獄一路打回天堂聖地》 與 HITB（Hack In The Box Security Conference）收錄為  《WoW Hell: Rebuilding Heavens Gate》 若對線上演講內容有興趣可以參考 Youtube 上 HITB 的直撥串流  HITB2021AMS D1T2 - WoW Hell: Rebuilding Heavens Gate - ShengHao Ma   不過我英文很破能不看就不看啦 由於整份演講內容想提的細節太多了，所以本部落格文拆成上下兩集。 當前本文是上集，會講述完整逆向工程整套微軟設計的 WOW64 架構怎麼設計的 。而下集《 重建天堂之門：從 32 位元地獄一路打回天堂聖地（下）攻擊篇：x96 Shellcode、天堂聖杯 ＆ 天堂注入器 》會著重在我今年發表出來的幾個有趣的攻擊點 :) 如果對天堂之門技術已經很熟的大佬，可以跳過本文看下一集了 <(_ _)> ＊注意＊ 本份研究在 2021/06/11 是基於 Windows 10 Enterprise 最新版本逆向工程結果所紀錄， 可能與讀者電腦中反編譯出來的結果有所出入是正常的 。筆者實測了同樣是 Windows 10 但不同組建版本在組合語言層級皆有些許差異，不過各個函數設計用途是固定且規律的、不會因版本而有所差異。 而整份研究不限但至少涉及了以下已知文獻，蠻值得一看的 2011 -  Mixing x86 with x64 code by ReWolf 2012 -  Knockin’ on Heaven’s Gate by georg...

 前言 這篇技巧是我在校稿最近剛出版的書 《Windows APT Warfare：惡意程式前線戰術指南》 正好看到  github.com/L3cr0f/DccwBypassUAC  這份 PoC 提及的 WinSxS 配置錯誤允許駭客劫持達成 UAC 特權提升看到比較有意思的事情所以寫一篇作為筆記。 不過這篇技巧目前在 Windows 10 上除非出現了配置錯誤的 DACL 可被寫入、否則新型的作業系統利用的可能性比較小XD 如果對 UAC 特權提升有興趣的讀者可以參考對岸這篇 BypassUAC原理及方法汇总  我覺得寫得還不錯、或者是看看我的書（？）  WinSxS  Windows 為了原生支援 WinSxS 多重系統模組功能——即同一個系統中可能會有 新舊程式使用到同個系統模組但不同版本號 的狀況。因此可以見到 C:\Windows\WinSxS\ 下有很多不同版本的資源包： 開發者能在編譯時期在純文字的資訊清單 *.manifest 記錄特定系統模組要從特定系統路徑、版本來裝載使用。而這邊引自上述對岸文章一段描述，其中提及了在資訊清單中還有一個特性可以使用： 在Windows中有些可执行程序没有内置的manifest，假设这个程序叫test.exe，如果攻击者在该可执行程序目录下新建一个test.exe.manifest并在manifest文件中指定file元素，则test.exe执行时会加载file元素中loadFrom属性指定的DLL（loadFrom的dll不能在KnownDlls中） 這是一個我覺得蠻有趣的特性，可以解釋為什麼系統槽下會有那麼多純文字保存的資訊清單 *.manifest 文件（我以前一直誤以為是開發者編譯完忘記刪掉XD）這描述說明了兩點： 除了開發者相當熟悉的嵌入式資訊清單，還有導出式資訊清單——在 同層資料夾中保存與程式名同名的 *.manifest 文件 即可被程式裝載器正確識別 無論嵌入或導出式資訊清單：使用 loadFrom  標籤可以指示程式裝載器在「裝載特定 DLL 模組」時便會被 redirect 去裝載另一個特定的 DLL 模組 總而言之當程式裝載器正在初始化一支靜態程式文件、發現其不具嵌入式資訊清單時，那麼就會同層目錄確認是否有同名的 *.ma...