Hao's Arsenal

背景介紹 我知道這是一個很奇怪的需求，但微軟不知道為什麼原生不允許用戶這麼幹、所以就寫了一篇介紹（？） 問題大概是這樣，如果有人跟我一樣習慣使用 Windows 熱鍵 [Win] 來喚起 Windows 10+ 開始選單來使用這些已釘選的應用程式，這樣會讓工作列顯的比較乾淨。但如果跟我一樣有這需求的人會發現一個問題：微軟只允許應用商城或者合法 MSI 安裝方式註冊到系統應用程序才可以釘選到開始選單中。 好的，所以如果你有自己慣用的小工具基本上就不能放上來對吧，微軟又在雷了（？） 解法 如果有興趣去挖一下開始選單這些快捷項目其實是保存在本地路徑 C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs 中 所以只要在這層目錄中，右鍵選單新增 → 建立捷徑，手動新增一個 LNK 捷徑指向到你要的 EXE 文件就可以讓檔案管理員認得這個沒被安裝的應用程序是一個合法的應用程序可以被釘選 接著就可以在開始選單找到你剛剛新增的快捷項目把它釘選到開始選單，舒服。

前言 因為演講需求要展示怎打穿 Virtualization 防護，洞都串好了結果發現 VMware 虛擬機 Windows 11 最新版下的 Defender 防毒惡意探索功能的 Hypervisor Code Integrity (HVCI) 怎樣都不給開。然後花了一段時間爬網路上文都沒人撰文解釋，這邊寫一篇文給有需要的人參考XD 有此需求在虛擬機內啟用 VBS 防護的朋友，應該都有嘗試過至配置中「Virtual Machine Settings → Processors → 勾選 Virtualize Intel VT-x/EPT or AMD-V/RVI」並且就能在「Options → Advanced → 勾選 Enable VBS (Virtualization Based Security) support」後，理論上啟動虛擬機後就能使用虛擬機中的 HVCI 防護... 然後這時候你一把 VMware 虛擬機開機，就會彈出一堆 Hyper-V 或 Virtualization 相關的不支援訊息（上圖）怎樣都不給你開機 Orz 好的那怎解決呢？有三大條件必須在 VMware Host 滿足缺一不可、即可讓 VMware Client 可以啟用 HVCI 囉。 關閉 Windows 原生 Hyper-V 虛擬機功能 首先是 Windows 功能（Windows Feature）相關 Hyper-V 與 Hypervisor 平台系列相關功能用於支援 Windows 原生虛擬機功能若啟用狀態下，都會導致 VMware Host 搶占走 Intel EPT 使用權限所致 Client 無法取用 Hypervisor 相關功能，囧。如上圖所示，將上述所有黃框處勾選起來。 系統配置中 Hyper-V / Hypervisor 功能 Intel CPU 所提供的 Hypervisor 系列指令集 HyperCall 被 Windows 重新封裝並以系統角色封裝成 Hyper-V 平台導出之系列 API，因此前面關掉 Windows 功能不代表系統自身的 Hyper-V 平台已經被註記為不得占用 Hypervisor 的狀態；所以需要按上圖所示，以系統管理員身分開啟 PowerShell 並輸入上述兩條指令用以關閉系統原生的 Hyper-V 平台。 Host ...

 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...

前言 我在 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 等等。...