《Roblox》外掛執行器技術整理 快速閱讀精華
- 核心架構：External Broker（外部代理）運行於遊戲程序外，透過手動映射（Manual Map）將 DLL 注入 RobloxPlayerBeta.exe
- 注入成功關鍵：繞過 Hyperion 防護的 CreateRemoteThread 封鎖（錯誤碼 0xC000071C），改用執行緒劫持（Thread Hijack）搭配私有 RX 還原 Stub
- 卡關瓶頸：TaskScheduler 掛鉤無法穩定運作，Luau 腳本執行與 print 輸出被阻斷
- 技術難點：執行緒挑選策略（RIP 必須落在主程式模組 0x7FF6 範圍內）、排程器鉤子安裝時機、VEH（向量化例外處理）與計時器的協調
前言：為什麼 External Broker 架構成為主流？
近年來 Roblox 外掛（Roblox Executor）的開發面臨前所未有的挑戰。隨著 Hyperion 防作弊系統的持續升級，傳統的 DLL 注入方式幾乎全數失效。這篇文章要帶你深入理解一種進階架構——External Broker + Manual Map——這正是許多 2025 年仍在運作的 Roblox 腳本執行器 所採用的核心技術。
這個架構的最大特點是：「外部指揮，內部執行」。Broker 程序完全獨立於遊戲程序之外，僅透過精心設計的注入機制將最小化的 Payload DLL 送進 Roblox 程序空間。這種設計大幅降低了被偵測的機率，但同時也帶來了複雜的技術難題——特別是當你需要在注入後「接管」遊戲的腳本排程系統時。
👉 GM後台版 遊戲 推薦 ⬇️⬇️⬇️ 快速玩各種二次元動漫手遊app
![]()
External Broker 架構拆解：從外部到內部的完整流程
整個執行器的運作可以分為兩個主要階段：注入階段與執行階段。理解這個分界點，是解決後續問題的關鍵。
階段一：Manual Map 手動映射注入
- Broker 程序啟動：C++ 編寫的外部代理獨立運行，不依附於 RobloxPlayerBeta.exe
- 手動映射 DLL：將 Payload DLL 的 PE 結構手動載入目標程序空間，完成後抹除 PE 標頭痕跡
- 導出函數驗證：遠端驗證映射後的導出表，確認 Payload 可正常尋址
- 執行緒啟動嘗試：首選 CreateRemoteThread 直接呼叫映射後的入口點
然而，這裡第一個關卡就出現了。在目前的 Hyperion 版本（測試環境為 version-9377ee10133e4be3）上，CreateRemoteThread 會穩定回傳 NTSTATUS 0xC000071C——這代表防護系統已經封鎖了從手動映射映像啟動執行緒或 CRT 初始化的路徑。
階段二：執行緒劫持（Thread Hijack）繞道方案
當直球行不通，就得靠曲球。這裡採用的替代方案是：
- 暫停目標執行緒：遍歷 Roblox 程序的所有執行緒（約 150 個）
- RIP 範圍篩選：檢查暫停時的指令指標（RIP），只選擇落在 RobloxPlayerBeta.exe 主模組（約 0x7FF6xxxx 範圍）的執行緒
- 跳過 ntdll 等待執行緒：RIP 在 ntdll（0x7FFDxxxx）的執行緒一律忽略，劫持這些執行緒會導致崩潰或凍結
- 私有 RX 還原 Stub：在劫持執行緒上執行自製的還原代碼——儲存 GPRs 與 XMM0-5、呼叫 ExecutorPayloadEntry、還原暫存器、跳回原 RIP
這個策略的脆弱點很明確：執行緒挑選。你需要在對的時間點找到一個「剛好在主程式模組內執行」的執行緒。遊戲選單、載入畫面、角色移動期間，都可能讓所有執行緒卡在 ntdll 等待狀態，導致注入逾時。
TaskScheduler 掛鉤：從「能跑」到「能改」的鴻溝
注入成功只是起點。真正的 Roblox 外掛 需要接管遊戲的腳本排程系統，才能執行 Luau 腳本。這裡是本文作者目前卡關的核心區域。
理論上的標準流程
- 注入 Payload 後，掛鉤 TaskScheduler（目標路徑：WaitingHybridScripts / tick）
- 透過掛鉤點攔截腳本執行時機
- 注入並執行自訂 Luau 腳本
- 攔截 print 輸出並回傳至外部 Broker
實際遭遇的封鎖
目前的測試結果顯示，排程器掛鉤從未成功穩定運作。具體嘗試過的策略包括：
| 策略 | 結果 | 錯誤碼/現象 | | Payload 內建 VEH + 一次性計時器（約 5 秒後觸發） | VEH 主要命中入口/劫持執行緒（被跳過），install_attempted 常保持為 0 | 掛鉤未安裝 | | Broker 發起第二次私有劫持，目標 InstallSchedulerHook | 混合結果：瞬間 0xC0000005、或存活約 60 秒後 0xC0000409、或凍結 | 存取違規 / 堆疊緩衝區溢位 / 無回應 | | 移除 Payload 內的排程器 VEH，改由 Broker 在入口完成後設旗標，再劫持另一執行緒的 ArmSchedulerInstall | 仍在測試中 | 待確認 | | APC 入口回退方案 | 通常無法提升階段，失敗後啟動相同 0xC000071C | 與 CreateRemoteThread 相同封鎖 |
錯誤碼解碼：當數字會說話
開發 Roblox 注入器 時，NTSTATUS 錯誤碼是你最好的朋友。以下是本文作者整理的高頻錯誤：
- 0xC000071C (STATUS_INVALID_THREAD)：執行緒啟動或 CRT 初始化被阻擋。這是 Hyperion 對手動映射映像的直接封鎖。
- 0xC0000005 (STATUS_ACCESS_VIOLATION)：劫持失敗，通常是因為暫停時 RIP 不在主程式模組內，或還原 Stub 有問題。
- 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN)：排程器相關執行緒運作約 60-65 秒後觸發，有時伴隨斷線。暗示掛鉤安裝後的穩定性問題。
- 注入逾時：數秒內找不到任何主程式模組內的 RIP 執行緒，常見於遊戲選單、載入或角色移動期間。
常見問題Q&A
Q：什麼是 External Broker 架構？為什麼不用傳統 DLL 注入？
A：External Broker 讓核心邏輯運行在獨立程序，只送最小化 Payload 進遊戲。傳統 LoadLibrary 注入會在 PEB 留下明顯痕跡，Hyperion 很容易偵測並封鎖。Manual Map 配合 PE 標頭抹除是目前的低偵測方案。
Q：CreateRemoteThread 回傳 0xC000071C 怎麼辦？
A：這代表 Hyperion 已封鎖該路徑。必須改用執行緒劫持、APC 注入、或尋找簽章模組內的代碼洞穴（Code Cave）等替代方案。
Q：為什麼劫持 ntdll 內的執行緒會崩潰？
A：ntdll 的等待執行緒通常處於特殊狀態，暫存器內容和堆疊佈局不適合被強制轉向執行 Payload 代碼。必須篩選出已進入主程式模組的執行緒。
Q：TaskScheduler 掛鉤有什麼替代方案？
A：社羣討論過的方向包括：簽章模組內的代碼洞穴、排程器 Job Vtable 掛鉤、延遲載入的 Luau 狀態操作、以及尋找 Hyperion 未保護的腳本執行路徑。
Q：version-9377 版本的偏移量（Offset）從哪裡取得？
A：公開的偏移轉儲（public offset dump）可取得 TaskScheduler 指標，驗證時應呈現有效的堆積指標外觀。實際位址會隨版本更新變動。
Q：這篇文章提到的技術可以用來開發作弊程式嗎？
A：本文純粹從逆向工程與系統安全研究角度整理技術討論內容。實際應用於線上遊戲違反服務條款，可能導致帳號永久停權。技術知識應用於合法的安全研究、遊戲模組開發（單機環境）或反作弊系統設計。
所有站內附件皆會附上安全掃描報告
請會員查看純淨度百分比後判斷使用
相關檔案須知：
取得檔案前，請先詳細閱讀文章內容
避免不必要錯誤與誤會發生。
也可多參考文章討論樓層內容
了解附件檔案相關討論資訊。
參考資料
| 
威望
藍鑽
GP
狗仔卡
收藏
分享
提升卡
變色卡
千斤頂
