《hid-mouse-inject》核心驅動程式下載 滑鼠輸入注入技術整理、反作弊繞過原理、驅動安裝教學

快速閱讀精華

🎯 **hid-mouse-inject** 是一款革命性的核心驅動程式，專門設計用於在 Windows 系統中注入滑鼠移動、按鍵和滾輪輸入，讓系統誤以為輸入來自真實硬體。

🔒 **隱形注入機制**：與傳統方法不同，此驅動程式在傳遞堆疊中完全不可見，無需掛鉤（Hooking），無需自行完成 IRP，真正實現無痕跡操作。

⚙️ **核心技術原理**：巧妙利用 HID 堆疊自身的元件（hidclass）來完成注入，通過操作 mouhid 的讀取 IRP，利用 hidclass 自己的完成工作者（AynchronousReadCompletionWorker）來派送資料。

🎮 **主要應用場景**：專為反作弊繞過（Anti-Cheat Bypass）設計，適用於需要隱藏輸入來源的高階技術應用，如遊戲自動化測試或輔助工具開發。

📥 **完整資源提供**：提供完整原始碼下載（38.6 KB），包含詳細技術文件、使用者模式範例客戶端，以及驅動程式安裝指南。

本文章目錄

• 快速閱讀精華
  
• 背景知識與系統架構
  
• 核心技術原理整理
  
• - 雙 IRP 機制與資料流
  
• - 定位 hidclass 的 Worker 函數
  
• - 滑鼠裝置驗證流程
  
• - 注入執行流程心得分享
  
• 驅動程式下載與安裝指南 🔽
  
• 常見問題Q&A

背景知識與系統架構

在 Windows 作業系統中，USB 滑鼠輸入並非直接傳遞到應用程式，而是經過一層層複雜的驅動程式堆疊處理。理解這個傳遞鏈結，是掌握 hid-mouse-inject 運作原理的關鍵。

USB 滑鼠輸入傳遞鏈結

當你移動滑鼠時，資料會依序通過以下驅動程式層級：

usbxhci -> hidusb -> hidclass -> mouhid -> mouclass -> win32k / RIM

• usbxhci：USB 主控制器驅動程式，負責硬體層級的 USB 通訊。
• hidusb：將 USB 封包轉換為 HID（Human Interface Device）格式。
• hidclass：HID 類別驅動程式，管理 HID 裝置的通用邏輯。
• mouhid：滑鼠功能驅動程式，專門處理滑鼠頂層集合（Top Level Collection）。
• mouclass：滑鼠類別驅動程式，將輸入傳遞給 Windows 核心。
• win32k / RIM：Windows 圖形子系統，最終將輸入傳遞給應用程式。

mouhid 的核心機制

mouhid 是整個注入技術的關鍵所在。它作為滑鼠的功能驅動程式，會開啟 hidclass 提供的集合，並且維持一個極其重要的狀態：永遠只有一個讀取 IRP（Read IRP）處於等待狀態。

這個 IRP 被永久地停放在 hidclass 的每個控制代碼軟體佇列（per-handle software queue）中，其 MDL（Memory Descriptor List）指向 mouhid 自己的報告緩衝區（report buffer）。你每次移動滑鼠時收到的真實資料，都是通過完成這個讀取 IRP 來傳遞的。

這就是 hid-mouse-inject 的設計基礎：傳遞完全由完成這個特定的 IRP 來驅動，而誰來完成它並不重要。關鍵在於完成時的堆疊框架（frame）屬於哪個模組。


👉 GM後台版 遊戲 推薦 ⬇️⬇️⬇️ 快速玩各種二次元動漫手遊app

核心技術原理整理

hid-mouse-inject 的精髓在於它「借力使力」的設計哲學。驅動程式本身不直接處理硬體通訊，也不修改關鍵系統函數，而是巧妙地讓 Windows 自己的 HID 堆疊元件「幫忙」完成注入。

雙 IRP 機制與資料流分離

整個架構中存在兩個關鍵的 IRP，而驅動程式只接觸其中一個：

• IRP-A（目標 IRP）：這是 mouhid 停放在 hidclass 軟體佇列中的讀取 IRP。它從未接觸過 USBXHCI 層，是真正的注入目標。
• IRP-B（硬體 IRP）：這是 hidclass 的 ping-pong IRP，被 hidusb 重新導向到 URB 中，實際坐在 USBXHCI 中等待真實硬體資料。這個 IRP 完全不被觸碰。

由於 IRP-B 保持原狀，真實的 USB 傳輸狀態得以保留，當真實滑鼠移動時，資料會自然完成。並發的真實報告要麼落在重新準備好的讀取 IRP 上，要麼進入 hidclass 的報告 FIFO，在微秒級別後被排出。沒有資料遺失，沒有孤立的 TRB，沒有修改任何硬體擁有的物件。我們與自然路徑之間唯一的共享物件是受旋轉鎖保護的軟體佇列，雙方都已經遵守這個鎖。

定位 hidclass 的 Worker 函數

技術的關鍵在於找到 hidclass.sys 中的一個小型例程：AynchronousReadCompletionWorker（這個拼字錯誤是微軟的，出現在他們的符號表中）。這個函數的內容非常簡潔：

IoCompleteRequest([ctx+0x10], 0)   ; 完成 IRP，boost 0
IoFreeWorkItem([ctx+0x08])
ExFreePoolWitdTag(ctx, 0)

hidclass 本身在 DISPATCH 層級執行時，使用這個函數來延遲讀取完成。它只讀取第二個參數（RDX），這正是 DPC 派送器放置 DeferredContext 的位置，因此這個例程可以直接用作 KDPC 的 DeferredRoutine。這就是整個注入設計的關鍵。

為了避免硬編碼 RVA（相對虛擬位址）導致在不同系統建構上失效，驅動程式從已載入模組列表中整理 hidclass.sys，並使用遮罩位元組模式掃描映射映像：固定指令位元組加上對三個呼叫位移和對齊填充的萬用字元。總共 66 位元組，其中 30 個固定。它必須在映像中完全匹配一次，否則驅動程式拒絕載入。到目前為止，它在兩個不同的 hidclass 建構上成功整理，其中 worker 位於不同的 RVA。

滑鼠裝置驗證流程

驅動程式引用 \Driver\MouHid 並遍歷其裝置物件列表，每個滑鼠集合對應一個 FDO（功能裝置物件）。每個 FDO 在成為注入目標之前都會經過嚴格驗證：

• 必須存在有效的開啟檔案物件和 mouhid 擴充中的 HID 工作區塊
• 預先整理資料必須能夠通過 HidP_GetCaps 往返驗證，並且實際描述具有匹配輸入報告長度的通用桌面/滑鼠 TLC
• 讀取 IRP 的目前堆疊位置必須是 IRP_MJ_READ，這正是停放在 hidclass 中的 mouhid 讀取 IRP 的樣子
• 必須能夠取得 hidclass 類別集合物件，用於待處理讀取引用計數

任何驗證失敗的裝置都會被跳過，並記錄原因。錯誤的偏移會產生垃圾資料，而驗證會在跳入未知領域之前捕捉到這一點。

注入執行流程心得分享

實際的注入過程分為四個精確步驟：

1. 閘門檢查（Gate）
重新整理來自即時擴充的揮發性指標，檢查讀取 IRP 是否實際停放在檔案擴充的佇列中。如果先前的注入完成鏈仍在傳輸中（微秒級視窗），則在 YieldProcessor 上旋轉等待重新停放。DPC 搶佔被動層級執行緒，因此這通常在個位數微秒內解決。路徑上任何地方都沒有睡眠。

2. 出佇列（Dequeue）
在檔案擴充的佇列旋轉鎖下，精確複製 hidclass 自己的紀律：驗證 IRP 是否仍已連結，以原子方式將取消例程交換為 NULL（如果輸掉交換，取消路徑擁有 IRP，退後），在 IRP+0xA8 處取消連結項目，鎖定遞減集合的待處理讀取計數。誰贏得旋轉鎖就擁有 IRP。如果真實報告傳遞贏得比賽，你只是返回未就緒，客戶端重試，讀取循環自行重新停放。

3. 製作報告（Craft）
直接寫入 mouhid 的報告緩衝區，這正是 hidclass 自然傳遞會放置位元組的位置，使用 HidP setter 針對 mouhid 自己的預先整理資料。這與 mouhid 讀回報告使用的整理器相同，因此報告對該裝置的描述符來說是格式良好的。保留報告 ID 插槽，按鈕是完整的所需按下集合，因為 mouhid 針對先前的報告進行邊緣檢測。

4. 派送（Dispatch）
像自然路徑一樣暫存 IOStatus（STATUS_SUCCESS 加上報告長度，SL_PENDING_RETURNED），分配一個工作者上下文，使用 hidclass 自己的大小和池標記（0x40 位元組，'HidC'），在 hidclass 集合 PDO 上建立工作項目，然後 KeInitializeDpc 使用 hidclass 的 worker 作為 DeferredRoutine，上下文作為 DeferredContext，並 KeInsertQueueDPC。立即返回使用者模式。

DPC 觸發，派送器本身呼叫 hidclass 的 worker，worker 完成 IRP，mouhid 整理報告，mouclass 執行服務回呼，mouhid 重新準備讀取。傳遞堆疊是：

nt!KiRetireDpcList
  -> hidclass!AynchronousReadCompletionWorker
     -> nt!IofCompleteRequest
        -> mouhid!MouHid_ReadComplete
           -> mouclass!MouseClassServiceCallback   (DISPATCH_LEVEL)
              -> win32k / RIM

注入器框架出現在這個堆疊的任何地方。而且每個底層都保持一致的狀態，因為每個層都真實處理了報告。mouhid 的整理器在真實報告上執行，按鈕針對真實的先前報告進行邊緣檢測，佇列和引用計數帳目是平衡的，IRP 生命週期是正常的出佇列/完成/重新準備/重新停放。

關於真實性（What is honest about it）

必須坦誠說明這項技術留下的痕跡，因為假裝沒有是愚蠢的：

• 注入的報告底下沒有 USB 傳輸。如果有人監控 hidusb/usbxhci 層級並將報告與傳輸關聯，可能會注意到異常。
• 並發的真實報告可以與注入的報告交換順序。對於相對滑鼠資料來說，這是無害的。
• 工作項目由 worker 分配和釋放，但實際上從未進入佇列，DPC 取代了佇列。
• 顯而易見，驅動程式模組本身是像其他任何驅動程式一樣載入的核心驅動程式，這個問題是正交的。

還值得說明的是：傳遞形狀（delivery shape）不是硬體中斷鏈形狀（那個會攜帶 hidusb/usbxhci 框架在 hidclass 之下）。它是 hidclass 本身在 DISPATCH 層級讀取備份時產生的非同步完成形狀，只有一個框架不同，KiRetireDpcList 取代了 worker 執行緒之上的派送器。一個完全普通的「DPC 完成讀取 IRP」堆疊，這是核心中最常見的完成形狀之一。

核心技術原理整理

雙 IRP 機制與資料流分離

整個 hid-mouse-inject 架構建立在對兩個關鍵 IRP 的精確區分上。驅動程式設計的巧妙之處在於，它只接觸其中一個 IRP，而讓另一個保持完全自然的硬體通訊狀態。

• IRP-A（目標 IRP）：這是 mouhid 停放在 hidclass 軟體佇列中的讀取 IRP。它從未接近過 USBXHCI 層，是我們的注入目標。
• IRP-B（硬體 IRP）：這是 hidclass 的 ping-pong IRP，被 hidusb 重新導向到 URB 中，實際坐在 USBXHCI 中等待真實硬體資料。這個 IRP 完全不被觸碰。

由於 IRP-B 保持原狀，真實的 USB 傳輸狀態得以保留，當真實滑鼠移動時，資料會自然完成。並發的真實報告要麼落在重新準備的讀取 IRP 上，要麼進入 hidclass 的報告 FIFO，在微秒級別後被排出。沒有資料遺失，沒有孤立的 TRB，沒有修改任何硬體擁有的物件。我們與自然路徑之間唯一的共享物件是受旋轉鎖保護的軟體佇列，雙方都已經遵守這個鎖。

定位 hidclass 的 Worker 函數

技術的關鍵在於找到 hidclass.sys 中的一個小型例程：AynchronousReadCompletionWorker（這個拼字錯誤「Aynchronous」是微軟的，出現在他們的符號表中）。這個函數的內容非常簡潔，正是我們可以利用的完成機制。

該函數的主體僅包含以下操作：

IoCompleteRequest([ctx+0x10], 0)   ; 完成 IRP，boost 0
IoFreeWorkItem([ctx+0x08])
ExFreePoolWitdTag(ctx, 0)

hidclass 本身在 DISPATCH 層級執行時，使用這個例程來延遲讀取完成。它只讀取第二個參數（RDX），這正是 DPC 派送器放置 DeferredContext 的位置，因此這個例程可以直接用作 KDPC 的 DeferredRoutine。這就是整個注入設計的關鍵所在。

為了避免硬編碼 RVA（相對虛擬位址）導致在不同系統建構上失效，驅動程式從已載入模組列表中整理 hidclass.sys，並使用遮罩位元組模式掃描映射映像：固定指令位元組加上對三個呼叫位移和對齊填充的萬用字元。總共 66 位元組，其中 30 個固定。它必須在映像中完全匹配一次，否則驅動程式拒絕載入。到目前為止，它在兩個不同的 hidclass 建構上成功整理，其中 worker 位於不同的 RVA。

滑鼠裝置驗證流程

驅動程式引用 \Driver\MouHid 並遍歷其裝置物件列表，每個滑鼠集合對應一個 FDO（功能裝置物件）。每個 FDO 在成為注入目標之前都會經過嚴格驗證，確保結構正確性：

• 必須存在有效的開啟檔案物件和 mouhid 擴充中的 HID 工作區塊
• 預先整理資料必須能夠通過 HidP_GetCaps 往返驗證，並且實際描述具有匹配輸入報告長度的通用桌面/滑鼠 TLC
• 讀取 IRP 的目前堆疊位置必須是 IRP_MJ_READ，這正是停放在 hidclass 中的 mouhid 讀取 IRP 的樣子
• 必須能夠取得 hidclass 類別集合物件，用於待處理讀取引用計數

任何驗證失敗的裝置都會被跳過，並記錄原因。錯誤的偏移會產生垃圾資料，而驗證會在跳入未知領域之前捕捉到這一點。

注入執行流程心得分享

實際的注入過程分為四個精確步驟，每一步都經過精心設計以確保系統穩定性：

1. 閘門檢查（Gate）
重新整理來自即時擴充的揮發性指標，檢查讀取 IRP 是否實際停放在檔案擴充的佇列中。如果先前的注入完成鏈仍在傳輸中（微秒級視窗），則在 YieldProcessor 上旋轉等待重新停放。DPC 搶佔被動層級執行緒，因此這通常在個位數微秒內解決。路徑上任何地方都沒有睡眠。

2. 出佇列（Dequeue）
在檔案擴充的佇列旋轉鎖下，精確複製 hidclass 自己的紀律：驗證 IRP 是否仍已連結，以原子方式將取消例程交換為 NULL（如果輸掉交換，取消路徑擁有 IRP，退後），在 IRP+0xA8 處取消連結項目，鎖定遞減集合的待處理讀取計數。誰贏得旋轉鎖就擁有 IRP。如果真實報告傳遞贏得比賽，你只是返回未就緒，客戶端重試，讀取循環自行重新停放。

3. 製作報告（Craft）
直接寫入 mouhid 的報告緩衝區，這正是 hidclass 自然傳遞會放置位元組的位置，使用 HidP setter 針對 mouhid 自己的預先整理資料。這與 mouhid 讀回報告使用的整理器相同，因此報告對該裝置的描述符來說是格式良好的。保留報告 ID 插槽，按鈕是完整的所需按下集合，因為 mouhid 針對先前的報告進行邊緣檢測。

4. 派送（Dispatch）
像自然路徑一樣暫存 IoStatus（STATUS_SUCCESS 加上報告長度，SL_PENDING_RETURNED），分配一個工作者上下文，使用 hidclass 自己的大小和池標記（0x40 位元組，'HidC'），在 hidclass 集合 PDO 上建立工作項目，然後 KeInitializeDpc 使用 hidclass 的 worker 作為 DeferredRoutine，上下文作為 DeferredContext，並 KeInsertQueueDPC。立即返回使用者模式。

DPC 觸發，派送器本身呼叫 hidclass 的 worker，worker 完成 IRP，mouhid 整理報告，mouclass 執行服務回呼，mouhid 重新準備讀取。傳遞堆疊中完全沒有出現注入器框架。而且每個底層都保持一致的狀態，因為每個層都真實處理了報告。

驅動程式下載與安裝指南

重要提醒
此驅動程式涉及核心層級操作，載入時需要啟用測試簽章模式（Test Signing Mode）。不當使用可能導致系統不穩定或觸發反作弊系統的防護機制。請僅在受控環境中使用，並自行承擔風險。

系統需求

• Windows 10/11（x64 架構，已在 Windows 25H2 Build 26200.9168 測試）
• 啟用測試簽章模式（bcdedit /set testsigning on）
• 管理員權限

原始碼與下載
以下是 hid-mouse-inject 驅動程式的完整原始碼壓縮檔（38.6 KB），包含核心驅動程式原始碼、使用者模式範例客戶端，以及建構所需的 WDK 專案檔案。



所有站內附件皆會附上安全掃描報告
請會員查看純淨度百分比後判斷使用



相關檔案須知：
取得檔案前，請先詳細閱讀文章內容
避免不必要錯誤與誤會發生。
也可多參考文章討論樓層內容
了解附件檔案相關討論資訊。

【此文章部分內容隱藏中】    解除隱藏說明教學點擊下方 繼續閱讀文章 後
請仔細觀看文章內容 並依照指示進行下一步
最後完成解除隱藏後
系統會回到此文章自動顯示隱藏內容~

繼續閱讀

安裝步驟

• 啟用測試模式
  以系統管理員身分開啟命令提示字元，輸入：
  

  bcdedit /set testsigning on

  
  完成後重新啟動電腦。桌面右下角應該會出現「測試模式」浮水印。
  
• 載入驅動程式
  使用服務控制管理員（SCM）或 OSR Driver Loader 等工具載入 hid-mouse-inject.sys。驅動程式會自動列舉系統中的滑鼠裝置並進行驗證。
  
• 執行範例客戶端
  倉庫中包含一個小型的使用者模式範例客戶端，示範如何列舉裝置、選擇目標，以及執行圓形移動/點擊/滾輪示範。

偵錯與日誌
除錯建置（Debug Build）會透過 DbgPrint 記錄每個步驟，這對於查看裝置為何被跳過的原因非常有用。建議使用 DebugView 或核心除錯工具來檢視這些日誌。

常見問題 Q&A

Q：這個驅動程式會被反作弊系統（如 Vanguard、EAC、BattlEye）偵測到嗎？
A：hid-mouse-inject 的設計確實是為了繞過某些層級的反作弊偵測，因為它不會出現在傳遞堆疊中，也沒有修改系統呼叫表或安裝鉤子。然而，現代反作弊系統會監控多種系統行為，包括驅動程式載入、記憶體異常和時序分析。此驅動程式仍會以載入的驅動程式形式存在，這是一個可被偵測的攻擊面。建議僅在離線或授權的測試環境中使用。

Q：安裝時出現「數位簽章錯誤」或「驅動程式未簽章」怎麼辦？
A：這是正常現象，因為 hid-mouse-inject 使用測試簽章而非正式的微軟 WHQL 簽章。你必須以系統管理員身分執行命令提示字元，輸入 bcdedit /set testsigning on，然後重新啟動電腦。桌面右下角出現「測試模式」浮水印後，即可載入驅動程式。請注意，某些線上遊戲的防作弊系統會檢測測試模式並阻止遊戲啟動。

Q：這個驅動程式支援哪些 Windows 版本？
A：目前僅支援 x64 架構的 Windows 10 和 Windows 11。已在 Windows 25H2（OS build 26200.9168）上完成測試。由於驅動程式使用了結構體偏移推導和位元組模式掃描來定位 hidclass 內部函數，在不同系統建構（Build）上可能需要重新推導 mouhid/hidclass 的結構體偏移。Worker 掃描本身不依賴 RVA，但結構體偏移是建構特定的。

Q：如何確認驅動程式是否成功載入並找到目標滑鼠？
A：建議使用 DbgView（DebugView）工具即時監看核心輸出。hid-mouse-inject 的除錯建置會透過 DbgPrint 記錄每個步驟，包括列舉到的裝置數量、每個裝置的驗證結果（為何被接受或跳過）、以及注入事件的時間戳。如果驅動程式成功載入但沒有找到有效滑鼠，日誌中會顯示具體的驗證失敗原因（例如「無有效的 HID 工作區塊」或「預先整理資料不符」）。

Q：使用時系統當機或出現藍屏（BSOD）如何排查？
A：藍屏通常由以下原因造成：結構體偏移錯誤（在不同 Windows 建構上使用了錯誤的 mouhid/hidclass 內部結構偏移）、競態條件（極高頻率注入導致的競態），或 記憶體損毀（驅動程式與其他安全軟體衝突）。排查步驟：

• 啟用核心偵錯工具（WinDbg）捕捉當機時的記憶體傾印（Memory Dump）。
• 檢查 WinDbg 輸出中提及的錯誤模組，如果是 hid-mouse-inject.sys，檢查具體的偏移位址。
• 確認你的 Windows 版本是否在測試支援列表中（目前僅確認 25H2 Build 26200.9168）。
• 嘗試降低注入頻率，或在單一滑鼠裝置上測試，排除多裝置競態。