發表文章

目前顯示的是 2018的文章

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! 實際擺攤的時候,對你工具有興

Windows Shim (ACT) 在 Windows10 下禁止 Inject Dll 系統實作細節原因

圖片
前言 如果你對 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!LdrpUnloadShimEng

WoW64 架構閱讀心得

圖片
參考文獻 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

Garena 釣魚蠕蟲 Dropper 樣本分析(照片.zip)與如何清除病毒

圖片
前言 事情是這樣的,一如反常的我打開我的 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 惡意腳本拷貝一份到 Window

[C++] 優雅玩耍函數指標呼叫,把你同事玩弄得嫑嫑的。(離職前記得回顧這篇文)

圖片
前言 最近正好寫一些玩具想模組化,以前在處理 Function Pointer 都是強轉型 + typedef 然後 ^C^V 瘋狂複製貼上函數型別來做到 C/C++ 內對指標函數呼叫。最近正好摸到一些 C++11 有支援到的正規轉型別方式,發現乾...XD 不用在手殘複製貼上啦,原來 C++11 一堆關鍵字已經可以讓你快速定義型別 + 把函數模組化放到自己的樣板內了超ㄎㄧㄤ btw 這篇只是筆記文,最一開始我只是想查 C/C++ 內到底能不能編譯時期就取得函數的型別XDDDD (結果是:幹,居然真的可以咧XDDDDD) #murmur 如果看完這篇文還是不懂怎麼做,那就算惹,我也沒很認真想解釋細節,不要太認真XD(只是覺得分頁欄有點滿,寫到部落格來不要佔 Chrome 的分頁,反正我看了哪些參考文獻都附在底下了) 另外,這篇都在講 Windows 上的做法,不過理論上把 LoadLibrary 跟 GetProcAddress 替換為對應 macOS/Linux 的函數應該都可以 work(N 年前好像有玩一下 macOS 上是可以跑的) 考.考.考.考考古學家  可以先參考這篇  [C++] How to GetProcAddress() like a boss   裡面純 C 寫法的強轉型函數指標做法,這相信常玩函數指標的人都有用過這樣玩法: 原理就只是: 宣告一個新的函數型別 ShellAboutProc,型別、呼叫約制跟你想呼叫的系統函數必須一致(對啦,不然等等堆疊爛掉你就知道惹) 接著透過 LoadLibrary() 載入系統函數模組取得模組地址、透過 GetProcAddress() 取得該函數位於該函數庫上真正地址 以 ShellAboutProc 函數型別宣告一個變數 shellAbout 最後將該函數地址強轉型為我們定義好的 ShellAboutProc 型別覆寫入 shellAbout 變數內,大功告成 la,shellAbout 變數就可以被當原生函數呼叫了 這做法超簡單、也實用,不過看也知道一堆地方可以省略XD,比方說根本不需要額外開一個變數來暫存函數指標,可以直接用內聯函數型態的方式、取代宣告函數型別與變數(離題惹)

IDA 神器深色主題套用教學,快讓你的 IDA 潮到出水吧!

圖片
前言 IDA 原始介面超醜我知道,如果你的工作或者興趣得一整天盯著 IDA 分析,那麼這篇文章肯定超適合你的XD。之前看很多大大的 IDA 介面超級無敵漂亮一問之下才知道有特別的樣式可以改。而網路上已經有現成很漂亮的樣式可以套用,底下就介紹一組我還蠻喜歡的深色系 IDA 主題怎麼套用。 :) IDASkin 可以參考至 zyantific/IDASkins  這個開源專案,用法很簡單,直接到  https://github.com/zyantific/IDASkins/releases  將最新版載下來、解壓縮,接著你會在壓縮包內的 Plugins 資料夾看到 IDASkins.dll 與 IDASkins64.dll。 接著就是把這兩個 dll 拷貝到電腦裡 IDA 安裝根目錄中的 Plugins 資料夾內。 接著將壓縮包中的 Skin 資料夾中的檔案,拷貝到電腦裡 IDA 安裝根目錄中的 Skin 資料夾內。 到目前為止就完成安裝 IDASkin 啦!重啟 IDA 後到 Edit > Plugins > IDASkins::Setting 就可以看到下圖彈出的樣式選擇器,你可以自由選擇你想使用的樣式啦。 套用完後就可以看見 IDA 外框(QT 的視窗樣式部分)成功切換成深色主題啦! ida-consonance 我知道光用 IDASkin 還不夠爽啦,視覺上還是有一片白看起來 hen 討厭對吧?IDA 內部負責渲染出組合語言程式碼、流程圖的部分,必須靠改 IDA 顏色配置,這邊可以使用 ida-consonance  這個顏色配置檔案XD 先將  ida-consonance.clr  給抓下來,接著在 IDA 介面中的 Options > Color 可以找到 IDA 顏色配置的選取視窗: 接著按下 Import 按鈕後,選取到剛剛下載下來的 *.clr 配置檔案,然後按開啟。 就會發現你的 IDA 變得超級無敵炫炮啦!瞬間都覺得自己非常會逆向了呢!