《SMM Mapper》CE繁體中文化腳本下載 UEFI SMM熱重載開發工具

修改器使用教學、ACPI WMI通訊機制、Payload注入

《SMM Mapper》UEFI SMM熱重載開發工具 快速閱讀精華

• 🔑 核心突破：這套工具讓你在不重新刷寫BIOS的情況下，直接載入、重載SMM層級的Payload程式碼
• 💡 技術亮點：透過ACPI WMI門鈴機制，一般使用者模式程式就能觸發SMM中斷，完全不需要核心驅動程式
• 🚀 開發效率：硬體開發時再也不用反覆關機重刷韌體，Windows執行SmmClient.exe即可即時熱重載
• ⚠️ 重要提醒：SMM是x86處理器的「Ring -2」特權層級，操作有風險，請確保瞭解底層機制後再使用

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

前言介紹

對於底層韌體開發者來說，最痛苦的事情莫過於每次測試都要關機、拆機、重刷BIOS，然後再開機驗證。這個循環可能花掉數十分鐘，一天下來開發進度慘不忍睹。

SMM Mapper 正是為瞭解決這個痛點而生。它是一套 UEFI SMM Payload 映射工具，核心價值在於 hot reload（熱重載）——讓你在作業系統運行期間，直接載入新的 SMM 層級程式碼，完全不需要重新開機或重刷韌體。

這篇文章會完整拆解這套工具的運作原理、安裝步驟，以及為什麼它的 ACPI WMI 通訊設計堪稱一絕。

SMM 基礎概念

什麼是 SMM？

SMM（System Management Mode，系統管理模式）是 x86 處理器的一種特殊執行模式。當系統管理中斷（SMI，System Management Interrupt）發生時：

• 處理器暫停目前所有工作，儲存當前狀態
• 切換到韌體專屬的保護記憶體區域（SMRAM）
• 執行 SMI 處理常式（SMI handler）
• 完成後透過 RSM 指令恢復先前狀態

業界常把 SMM 稱為「Ring -2」——這個說法雖然有點濫用「環狀保護層級」的概念，但能幫助理解：SMM 的執行權限 低於作業系統、低於標準核心、甚至低於虛擬機器監視器（hypervisor）。

SMM 驅動程式的特殊性

這裡有個關鍵認知：SMM 驅動程式跟 Windows 驅動程式完全是兩回事。

• ❌ 不在 ntoskrnl 的模組列表中
• ✅ 是韌體模組，載入到 SMM 環境執行
• ✅ 為各種 SMI 來源註冊處理常式（硬體事件、軟體 SMI、電源管理事件等）

SMM Mapper 架構整理

SMM Mapper 本質上是一個 一次性的韌體補丁。裝好之後，你就能隨時載入、重載、觸發新程式碼，不用關機。

整個專案由兩個韌體元件組成：

元件名稱	執行階段	核心職責
DxeBridge	UEFI 開機期間（DXE 階段）	分配共享信箱、讀取 Payload 檔案、設定 ACPI WMI 門鈴、傳遞首個 Payload 給 SMM
SmmHost	SMM 環境內	接收 Payload 位元組、手動映射 PE32+ 映像、處理重載邏輯、呼叫 Payload 進入點

為什麼需要自製映射器？

這個問題的答案是整個設計的精髓：

熱重載發生在 作業系統已經開機完成之後。此時：

• DXE 載入服務（LoadImage、StartImage）已經無法使用
• SMRAM 從外部被鎖定，無法直接寫入
• 只有已經安裝的 SmmHost 能接受原始 PE 位元組，並映射到 SMM 記憶體中

因此必須自製映射器，不能依賴 UEFI 的標準服務。

Payload 的 ABI 介面

SmmHost 呼叫 Payload 進入點時，使用以下簡化 ABI：

EFI_STATUS PayloadEntry(PAYLOAD_CONTEXT *Context);

Context 結構包含 SMM Payload 所需的各項元素：

• SMST（SMM 系統表格）
• 序列埠記錄輔助函式
• 記憶體分配輔助函式
• 處理常式註冊包裝函式
• Payload 世代編號
• reason 值（載入原因）

reason 值告訴 Payload 為何被呼叫：

REASON_LOAD    → 首次載入或熱重載
REASON_UNLOAD  → 卸載前清理
REASON_DOORBELL → 門鈴觸發，處理命令

同一個模組可以在開機時初始化、卸載時清理、門鈴執行時處理命令。

熱重載運作機制

開機階段載入

DxeBridge 在開機時尋找：

\EFI\SMM\PAYLOAD.EFI

如果找到，就傳送給 SmmHost。如果檔案系統還沒準備好（USB 或 EFI 分割區尚未就緒），會使用協定通知與重試計時器——這在真實硬體上很重要，因為儲存裝置的可用時間點並不固定。

Windows 執行期的熱重載

從 Windows 觸發熱重載的流程完全不同：

• Windows 客戶端讀取新的 Payload 檔案
• 分割成多個片段
• 透過 ACPI WMI 傳送這些片段
• SmmHost 將片段放入內部 Payload 緩衝區
• 驗證雜湊值
• 卸載舊 Payload
• 映射新 Payload
• 以 REASON_LOAD 再次呼叫

整個過程無需重開機，開發效率大幅提升。

ACPI WMI 門鈴通訊設計

這是整個專案最具巧思的部分——如何讓使用者模式程式與 SMM 通訊？

最初的困境

最直覺的解法是寫一個核心驅動程式。驅動程式可以直接觸發軟體 SMI，也能存取共享信箱。這確實可行，但作者拒絕了這個方案：

• 「如果還需要核心驅動才能跟 SMM 溝通，那這個專案的核心價值就喪失了」

ACPI WMI 解決方案

取而代之的是 ACPI WMI（Windows Management Instrumentation）設計：

開機期間，DxeBridge 注入一個小型 SSDT（Secondary System Description Table），建立 ACPI WMI 裝置：

ACPI 路徑：\_SB_.SMMW
_HID：     PNP0C14
_UID：     SmmMapper

Windows 中顯示為：ACPI\PNP0C14\SmmMapper_0

SSDT 提供一個 WMI 方法，關聯此 GUID：

9B6F1A20-31D5-44DF-9A9C-157F4307914B

方法名稱為 WMBD，內部執行三個動作：

• 將使用者模式的請求緩衝區複製到映射器的信箱
• 向 SMI 命令埠寫入 0xD5
• 將 SMM 回應緩衝區傳回 Windows

SMI 命令埠取自 ACPI FADT 表格，若無法取得則使用 0xB2 作為後備。作者測試主機板使用的軟體 SMI 值為：

#define SW_SMI_VALUE 0xD5

Windows 客戶端實作

SmmClient.exe 是一個標準的使用者模式程式：

• 載入 Advapi32.dll 函式庫
• 使用 WmiOpenBlock 開啟 WMI 工作階段
• 使用 WmiExecuteMetdodW 呼叫 ACPI WMI 方法

最終的通訊路徑：

使用者模式 → WMI → ACPI → SMI 命令埠 → SMM 中斷 → SmmHost → Payload

整個流程沒有任何 .sys 驅動程式參與。

為什麼需要「門鈴」機制？

這個設計細節很容易被忽略：SMM 程式碼不會「在背景執行」。

SMM 只有在處理器進入 SMM 模式時才會執行，而這通常需要 SMI 觸發。因此，如果使用者模式只是寫入命令到某個記憶體位置，什麼事都不會發生——SMM 不會神奇地偵測到它。

必須有東西觸發 SMI，那個「東西」就是「門鈴」。

作者曾考慮直接輪詢（讓 SMM 驅動程式不斷讀取同一個記憶體位置來取得命令），但輪詢不適合這個場景：

• 需要週期性 SMI，意味著不斷打斷整臺機器
• 平臺相依性高
• 嚴重影響效能
• 產生過多韌體特定行為

理想的門鈴流程：

寫入請求 → 觸發單一 SMI → 處理請求 → 寫入回應 → 返回使用者模式

SMM 只在真正有工作要做時才被觸發。

這正是 WMI 方案的價值：WMI 允許一般使用者模式程式要求 ACPI 執行韌體方法，而這個 ACPI 方法可以向 SMI 命令埠寫入資料。於是，我們從使用者模式獲得了 SMI 觸發能力，無需 Windows 核心驅動程式。

安裝與使用教學

- 建置專案

開啟 x64 Visual Studio 開發人員命令提示字元，執行：

src\build.cmd

- 整合至韌體

將 DxeBridge.efi 與 SmmHost.efi 加入你的韌體並刷入主機板。最簡單的方式是直接替換現有的 DXE 與 SMM 模組（可使用 UEFI Tools 等工具）。

- 放置 Payload

將你的 Payload 檔案放在 UEFI 可讀取的位置：

\EFI\SMM\PAYLOAD.EFI

例如 EFI 系統分割區或 FAT32 格式的 USB 隨身碟。

- 開機驗證

啟動目標機器，觀察序列埠輸出，確認看到：

• DXE 初始化訊息
• SMM 初始化訊息
• Payload 載入訊息

你需要將 COM 埠讀取器連接到主機板的序列埠接頭。

- Windows 客戶端操作

在 Windows 中使用 SmmClient.exe 執行以下操作：

• reload（重載 Payload）
• unload（卸載 Payload）
• ping（測試連線）
• status（檢查狀態）
• doorbell（觸發門鈴）

透過 ACPI WMI 完成，無需核心驅動程式。

⚠️ Payload 開發注意事項

SmmHost 自行處理映射，不使用 UEFI 映像載入器。這代表：

• 完全避免使用匯入（imports）——它們不會被整理
• 如果 Payload 有任何絕對位址，務必使用重定位（relocations）

支援平臺與需求

項目	需求規格
韌體	x64 UEFI，支援 AMI Aptio V 風格的 PI SMM
作業系統	Windows 10 或 Windows 11（供 Windows 客戶端使用）
通訊機制	ACPI WMI 命令，支援從使用者模式觸發與重載映射的 Payload
測試平臺	ASUS TUF X870 + AMD AM5（Intel 平臺理論上也可運作）

常見問題Q&A

Q：這個工具可以用來做什麼？
主要應用場景是底層韌體開發與研究，例如 SMM 層級的安全研究、硬體除錯、或需要 Ring -2 權限的特殊操作。一般遊戲玩家或一般使用者不太需要接觸這個層級。

Q：操作 SMM 有什麼風險？
SMM 是處理器的最高特權層級之一。錯誤的 SMM 程式碼可能導致系統完全鎖死、無法開機、甚至需要重新燒錄 BIOS 晶片。建議在備用機或開發板上測試，不要在主要工作機上操作。

Q：為什麼強調「不需要核心驅動程式」？
現代 Windows 對驅動程式簽章要求嚴格，載入未簽章的核心驅動越來越困難。透過 ACPI WMI，一般使用者模式程式就能觸發 SMM，大幅降低了使用門檻與被偵測的風險。

Q：Payload 檔案有什麼限制？
不能使用標準的 DLL 匯入機制，所有外部函式都必須透過 Context 結構提供的輔助函式來呼叫。建議使用靜態連結或完全自包含的程式碼。

Q：Intel 平臺能用嗎？
作者在 AMD AM5 平臺測試，但專案設計遵循標準 PI SMM 規範，理論上 Intel 平臺也應該可以運作。實際相容性需要自行測試驗證。

Q：如何取得序列埠輸出？
需要主機板上有序列埠接頭（通常標示為 COM 或 UART），並使用 USB-to-Serial 轉接器連接。這是觀察 SMM Mapper 運作狀態的主要方式。

Q：這跟遊戲修改有關係嗎？
SMM Mapper 本身並非遊戲修改工具，但它提供的 Ring -2 層級存取能力，理論上可以用來實作極底層的反偵測機制。這也是它出現在 Anti-Cheat Bypass 討論區的原因。



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



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

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

繼續閱讀