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!LdrpUnloadShimEngine 來卸載 Shim 引擎，而 LdrpLoadShimEngine 內部實作是這樣子的：

你可以看到大致上透過  LdrpLoadDll 呼叫 C:\Windows\System32\shimeng.dll（事實上如果你的 Windows 有打過 Patch，你應該可以在 C:\Windows\ 下找到其他 shimeng.dll，那才是真正你現在電腦正在運行的版本，微軟爸爸的安全更新幫你做熱修復升級強制替換的新版 shimeng.dll）。接著呼叫了 LdrpGetShimEngineInterface()，然後確定當前系統是否有開啟 Shim 補釘機制。

LdrpGetShimEngineInterface() 內部實作，即嘗試動態初始化各個 Shim 各階段執行需要的必備函數，並且將查 shimeng.dll 取得外導函數表幾個會用到的 API 地址，透過 EncodeSystemPointer 函數保存在全域變數中。

所以這邊就可以大概知道實作部分接著就是在 ntdll!LdrpInitializeProcess 內完成各階段步驟時，甚至是 Process 被通知得「被自殺」時，呼叫對應的 Shim Engine API 來完成動態補丁實作。

ShimEng.dll on Windows 7

接著你可以翻一下 ShimEng.dll 的外導函數表，你會發現所有 API 根本都是他媽的 appHelp.dll 的實作，ShimEng.dll 內部根本不參與任何實作！幹，超級拖台錢

AppHelp.dll on Windows 7


安安，所以會發現始作俑者都是 AppHelp.dll 啦。Shim 整個機制的函數實作都放在 AppHelp.dll 內，並且你想要「自己以 C/C++ 製造一個 *.sdb 補丁文件」也是可以透過 AppHelp.dll 開放的 Sdb 系列函數來快速生產 *.sdb 補丁文件。

好，所以重點是什麼？重點在 AppHelp!SE_InstallBeforeInit 實作上：


這邊在 AppHelp!SE_InstallBeforeInit 實作內呼叫了 AppHelp!SeiInit：
然後 AppHelp!SeiInit 內部實作有一個超他媽巨大迴圈負責跑完整個目前已註冊的 *.sdb 中這支 Process 需要注入哪些 Dll。

AppHelp.dll on Windows 10
沒有錯啦！Windows 10 上面整個邏輯大改，負責加載 *.sdb 注入函數的那個迴圈邏輯通通不見了啦！！！！就跟你的腹肌一樣不曾存在過啦！！！！！看到這邊整個氣到彈出來，可以看到 Windows 10 上面 AppHelp.dll 只實作了呼叫 LdrLoadDll 函數 + API 定位來做 Shim 裡面的函數劫持功能而已，原本負責注入的邏輯整個被拔掉了 RRRRRR

留言

  1. Unknown2020年4月29日 凌晨4:31

    那咋办呢...

    回覆刪除
    回覆
    1. Unknown2020年4月29日 凌晨4:42

      火眼的报告有提到可以执行shellcode，但是我没有找到相关的详情，不知道是否还通用
      https://www.fireeye.com/blog/threat-research/2017/05/fin7-shim-databases-persistence.html

      刪除

張貼留言

這個網誌中的熱門文章

[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"; })); 又因為=>後面可接陳述塊或者陳述句，所...
閱讀完整內容

[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 等等。...
閱讀完整內容

重建天堂之門：從 32 位元地獄一路打回天堂聖地（上）深度逆向工程 WOW64 設計

-
圖片
前言 這份研究是從去年底開始摸的，主因是一直對 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...
閱讀完整內容