Hao's Arsenal

前言 安安，這篇沒有講任何工具本身細節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 Shim (ACT) 不熟是什麼，建議你可以先參考這篇： 详解Windows Shim的攻防利用 ，這篇很不錯的介紹了 Windows Shim 相容性工具如何被惡意濫用進行攻擊。另外還有一篇俄羅斯的文章介紹的也不錯： shim handlers 。 前陣子在做一份玩具需要做到對單一 Process 每次開機重啟都能穩定 hook 住固定 API 作檢測，第一個想到最穩定的做法當然是 TMD 幫該執行程式打一層補丁 (Shim) 指定該 Process 每次開機重啟都會加載我的 *.dll，接著就可以做熱修復（Hot Patch）這做法很漂亮，一個簡單 *.sdb 就能簡單起到穩定的 *.dll 同一 Process 穩定注入，不過... 對，Windows 10 不給玩這招了，你在 Windows 10 下打上 Inject Dll 的補丁是會被無視的 QQ，最近時間比較充裕 並沒有，只是突然很想知道為什麼不給這樣搞  花了大概一小時的時間把 Windows 7 與 Windows 10 的 Loader 實作細節分析完畢，然後就大概摸出了問題點在哪...囧。 PE Loader (at ntdll.dll) on Windows 7 如果你跟我一樣吃飽太閒（不過其實打這篇文章的時候我好餓喔...好想吃滷肉飯）翻一下 ntdll.dll 的實作你應該可以看到一支 *.exe 被執行起來後，要開始做程式必備初始化的修復動作，這些步驟可以看到在 ntdll!LdrpInitializeProcess 內實作： 如果你有開 IDA Pro 的話上下捲捲捲就可以看到這個函數內在初始化 Process 時候，會按造順序分配堆疊必備的記憶體空間、分配各區段對應在虛擬地址上、修正重定向、最後修正了引入函數表（IAT, Import Address Table）而這幾大修正步驟過程中，根據 Shim 的需求可能會需要在載入 DLL 之前、期間、之後，各階段插入不同的行為來完成打補釘的行為。 每次要讓 Shim 機制介入打補釘時，就會呼叫 ntdll!LdrpLoadShimEngine 函數來載入 Shim 引擎，如果完成該階段的目標後，就會呼叫 ntdll!LdrpUnloadShi...

參考文獻 WoW64 and So Can You Bypassing EMET With a Single Instruction 心得 傳統上 x86 所有系統模組實作都是 ntdll.dll 的函數封裝，最後都會回到 ntdll.dll 的 ZW 函數以 kikifastcall 發送出去就切 Kernel Mode 中斷了。 不過當 WoW64 架構下，需要把 32 位元程式跑在 64 位元架構的 Process 裡，那麼 32 位元的函數資料丟 64 位元在查 SSDT（其實我不是很清楚 64 位元還有沒有 SSDT）就會因為數字存放的基本資料結構 size 不同導致函數呼叫整個爛掉，因此無法直接把 32 位元程式就直接丟在 64 Process 跑（即使 Thread 可以，但架構上 r0 進去會爛掉） 3. 所以在 Win7 架構下會在 TIB 的 fs:[0xc0] 用 uint32_t 欄位（WOW32Reserved）保存了一個 WoW32CPU.dll（32bit） 的函數地址 -- X86SwitchTo64BitMode，也就是 32 位元程式 kikifastcall 原本應該送什麼中斷請求出去，這邊改為用 call dword ptr fs:[0xc0] 就可以直接呼叫到 X86SwitchTo64BitMode API，這個 API 內部實作再幫你把 32 位元的中斷請求參數轉換為 64 位元送給 r0，然後再返還。（這也清楚解釋了為什麼 Win7 64bit 需要把 64 位元的 ntdll.dll 模組放在 4G 以下，不然這個 TIB 欄位保存不了XD） 4. 很多設計很爛的 AntiVirus（AV）甚至是早期版本的微軟防漏洞架構 EMET 的函數監測攔截都是放在 userland、然後 r0 的 hook 強制在每隻 Process 創建時把監測用的 dll 注入到 Process 內做檢測：WoW64 Process 就注入 32 位元的監測 dll 到記憶體裡、64 位元 Process 就把 64 位元監測 dll 注入到記憶體。 5. 所以 WoW64 架構怎麼被濫用？我故意設計一個 x86 PE 跑在 WoW64 架構下，但是 AV 所有監測都放在 userland 的 4G...

前言 事情是這樣的，一如反常的我打開我的 macbook、打開虛擬機、打開 Windows、打開 Garena 、打開 LoL 想發洩一下 這時候發現一堆人都在密我呢，好害羞啊，可是大家都密我一樣的東西，丟了一份 照片.zip 過來，這引起了我的好奇 註：這篇文章只分析 Dropper 部分，後面還有一支 *.exe 惡意程式有加殼，如果時間比較有空了我才會分析進去他在幹嘛XD，這篇文章主要是分享分析 *.vbe 加密後的 VBScript 的方法與解混淆的技巧。 我不會承認是因為我懶得開虛擬機，所以這篇文章都在真實工作電腦內純靜態分析哈哈哈哈哈哈 TL;DR：如何清除病毒？ 因為這隻惡意程式把路徑跟檔名都寫死的，所以檢查一下你 Windows 的「啟動」資料夾是否有 r.vbe，跟 C:\programdata\opopopk.exe 這個程式是否存在。把啟動資料夾內的 r.vbe 與 C:\programdata\opopopk.exe 刪除就完成清除病毒惹 惡意壓縮包附件 首先你拿到這份壓縮包後，會看到裡面只有一個「照片.vbe」檔案，類型可見是 VBScript 編碼後的腳本文件 打開這份 *.vbe 文件後，即可見內部是編碼過後的腳本，無法直接觀看到程式碼，你可以透過 VBS decrypter and encrypter  來完成這個解碼的部分 ，這個編碼解碼有一套固定算法沒有任何技術性，不要浪費人生在這種無意義的東西上 把解碼後的程式碼稍微重新排版後，可以看到他的混淆很簡單，就只是把 VBScript 程式碼以字串方式，把每個 ASCII 碼以數字與逗號做切割保存在 Str 變數內。執行時，再將每個數字轉回文字並組合存在 restorecode 內，回傳 ASCII 組合起來的字串，再透過內建的 Execute 函數將 VBScript 執行起來。所以只要把 Execute 換為 MsgBox 函數： 我們就可以很輕易的把程式碼攔截下來，接著進到下一步驟做分析。 Dropper 核心程式碼 上面是完整攔截下來的 VBScript 的 Dropper 程式碼。 一開始執行起來這一段很好理解，基本就是把自己目前這份混淆過後的 *.vbe 惡意腳本拷貝一份到 Wi...