不重置 Xiaomi AX3000T：從 Mesh 協定找回路由器管理權限¶

本文記錄對自有設備進行的安全研究。為避免形成可直接濫用的操作手冊，韌體內的固定金鑰、真實驗證值、封包內容、MAC、工作階段資訊與可直接執行的攻擊程式均已省略。請勿在未獲授權的網路或設備上測試。

摘要¶

一台 Xiaomi Router AX3000T（RD23、Global 1.0.42）仍在正常運作，也承擔家中 Mesh 主路由的角色，但管理密碼與綁定的小米帳號都已無法取回。恢復原廠設定雖然簡單，卻會清除現有網路與 Mesh 設定，因此不是理想答案。

研究結果顯示，路由器的 CAB Mesh 服務存在兩個可以串接的設計問題：節點驗證依賴韌體內共用的固定秘密，而設定同步訊息又會交付管理帳號的 SHA-1 與 SHA-256 驗證值。小米的登入與改密碼流程實際接受這些驗證值衍生出的證明，而不是非得取得原始明文密碼。

最終，我們在沒有重置、重開機、刷機、切換網路模式或破壞 Mesh 的情況下：

建立正常的管理員工作階段；
透過官方密碼修改介面設定新密碼；
以全新工作階段重新登入；
再以獨立的只讀流程驗證一次。

這不是破解出舊密碼。舊密碼的明文從未被取得、顯示或保存。

問題背景與限制¶

現場條件比一般的「忘記路由器密碼」更麻煩：

小米 Wi-Fi／米家帳號也無法登入；
原綁定的 Google 電子郵件帳號已停用；
Mac 當時連在既有 Mesh 網路上；
網路仍正常，不能為了管理頁面而中斷全家設備；
目標明確限定為不恢復原廠設定。

因此，研究一開始就設定了安全邊界：不重置、不重開機、不刷機、不更改 netmode、不發布 MQTT 訊息，也不確認或套用任何 Mesh 設定同步。優先順序是韌體靜態分析，其次才是對實機做可逆、只讀的驗證。

先排除看似簡單的入口¶

對主路由與 Mesh 子節點進行有限度的服務盤點後，沒有發現可直接使用的 SSH 或 Telnet。管理 API 會拒絕無效工作階段；MQTT 不允許匿名登入；幾個在舊款小米路由器研究中出現過的命令注入介面，也都需要先取得有效的 LuCI 工作階段。

這一步很重要，因為「某型號曾經有漏洞」不代表同一技巧能安全套用到另一個硬體版本與韌體分支。網路上流傳的部分 Mesh 重放方法還可能切換路由器模式，對正在運作的家庭網路風險過高，因此沒有採用。

韌體分析：真正的突破口在 Mesh 同步¶

能取得並完整拆解的最接近版本是 RD23 Global 1.0.49。雖然實機是 1.0.42，但 1.0.49 的 CAB Mesh 元件、Lua 控制器與前端加密流程，為理解實機封包提供了可靠地圖；所有關鍵結論最後仍以 1.0.42 實機驗證，而不是只靠近似版本推論。

分析顯示，CAB Mesh 服務在 TCP 19553 上處理節點加入與設定同步。問題出在兩個信任邊界同時失守：

節點身分驗證使用韌體內嵌、跨設備共用的 HMAC 秘密；
通過節點驗證後，主路由會在同步資料中送出管理帳號的兩種密碼驗證值。

同步欄位分別對應舊式 SHA-1 與新式 SHA-256 帳號資料。它們不是明文密碼，但在小米目前的網頁驗證設計中，已經足以扮演「可重放的等價憑證」。

只讀探針的行為刻意停在接收同步訊息：完成最小必要的雙向驗證、讀取第一份設定同步資料，然後直接斷線，不傳送最後的「同步成功／套用」確認。這讓我們能驗證資料外洩，同時不讓臨時節點加入 Mesh，也不改動現有設定。

為什麼雜湊值足以登入？¶

一般使用者在登入頁輸入密碼後，瀏覽器不是直接送出密碼，而是先計算帳號驗證值，再把它與一次性 nonce 組合：

login_proof = SHA256(nonce || stored_verifier_256)

伺服器端持有相同的 stored_verifier_256，因此可以重算並比對 login_proof。問題是，Mesh 同步已經把這個驗證值交給通過節點驗證的對方。取得它的人不需要反推出原始密碼，就能為新的 nonce 產生有效登入證明。

這也是為什麼本次成果應稱為「恢復管理權限」，而不是「找回原始密碼」。安全上，這類驗證值應視為與密碼同等敏感。

為什麼普通改密碼頁仍要求舊密碼？¶

登入成功後，管理頁面的「修改管理密碼」表單仍會要求原始密碼。表面上看來，事情又回到原點。

但追蹤前端 JavaScript 與後端 Lua 控制器後，可以看到原始密碼只在瀏覽器內用來導出三項資料：

舊密碼的 nonce 證明；
以目前 SHA-1 驗證值保護的新 SHA-1 驗證值；
以目前 SHA-256 驗證值保護的新 SHA-256 驗證值。

後端 set_name_password 流程會驗證 nonce 與舊密碼證明，解開兩份新驗證值，然後更新正式帳號設定。它並不要求後端看見原始明文密碼。

由於 Mesh 同步已提供目前的兩種驗證值，我們可以完全重現官方表單本來會產生的資料。這不是略過密碼檢查，而是使用已外洩的等價憑證通過同一套檢查。

為避免直接提供可濫用的實作，本文不列出固定秘密、AES 參數、封包格式或完整請求內容。

安全的復原流程¶

實作被拆成兩個階段。第一階段預設只讀，第二階段必須由設備擁有者在本機明確確認。

sequenceDiagram
    participant Owner as 設備擁有者
    participant Tool as 本機復原工具
    participant Mesh as CAB Mesh 服務
    participant LuCI as 管理介面

    Tool->>Mesh: 最小節點驗證
    Mesh-->>Tool: 初始設定同步
    Note over Tool,Mesh: 不回覆套用確認，直接斷線
    Tool->>LuCI: 以 nonce 與等價憑證登入
    LuCI-->>Tool: 正常管理工作階段
    Owner->>Tool: 隱藏輸入新密碼兩次
    Owner->>Tool: 最終確認 CHANGE
    Tool->>LuCI: 呼叫官方改密碼流程
    LuCI-->>Tool: 更新成功
    Tool->>LuCI: 建立全新工作階段
    LuCI-->>Tool: 受保護只讀端點成功

幾項刻意加入的保護：

預設執行只確認漏洞鏈與登入能力，不寫入；
新密碼使用終端隱藏輸入，不接受命令列參數；
必須輸入兩次相同新密碼；
檢查長度與字元種類；
最後必須輸入指定確認詞才送出；
不輸出驗證值、MAC、工作階段 token 或韌體加密參數；
更新後立即建立全新工作階段並讀取受保護端點；
最後再執行一次完全獨立的只讀驗證。

實機結果¶

復原在 AX3000T RD23、Global 1.0.42 上成功完成：

新管理密碼已設定；
新密碼可以建立全新的管理工作階段；
受保護的只讀 API 回應正常；
第二次獨立登入驗證成功；
Mesh、Wi-Fi 名稱、Wi-Fi 密碼與既有網路設定均未重建；
沒有恢復原廠設定、重開機、刷機或切換路由模式。

測試只證明這一台設備與這一個韌體版本的行為。其他地區版、硬體修訂或韌體版本是否相同，仍需個別確認。

安全影響¶

這條問題鏈的影響高於一般的資訊洩漏。只要攻擊者能從區域網路接觸 CAB Mesh 服務，並重現韌體內的節點驗證，就可能取得足以建立管理工作階段的等價憑證。原始密碼強度再高，也無法抵消伺服器主動交付驗證值的風險。

主要根因包括：

跨設備共用的韌體內嵌秘密；
將管理員驗證值放入 Mesh 設定同步；
登入協定允許持有驗證值的一方直接產生有效證明；
路由器管理平面與 Mesh 控制平面的信任邊界不足。

廠商可以如何修正¶

完整修復需要同時處理節點身分與帳號資料，而不是只封鎖單一端點：

每台設備使用獨立、可輪替的 Mesh 憑證，不在韌體中放置共用秘密；
使用具備前向安全性與雙向裝置身分的配對流程；
永遠不要同步可直接用於登入的管理員驗證值；
若節點需要取得管理能力，改用有期限、限定用途、可撤銷的授權；
將 Mesh 控制服務限制在專用 backhaul 介面，並加入來源與速率限制；
韌體更新後輪替既有 Mesh 與管理憑證，並失效舊工作階段；
提供不破壞網路設定的官方本機復原流程，例如實體按鍵加一次性代碼。

負責任研究與公開範圍¶

本文選擇公開根因、驗證方式與修復建議，但不公開可以立即複製到陌生網路的關鍵材料。對擁有受影響設備的人而言，最安全的短期措施是：更新至廠商已確認修復的韌體、限制不受信任用戶進入管理網路，並避免把路由器管理介面暴露到外網。

參考資料¶

結語¶

這次復原最有意思的地方，不是找到一個「不用密碼的管理頁」，而是沿著完整的信任鏈確認：Mesh 節點如何被驗證、同步資料包含什麼、網頁登入真正驗證什麼，以及官方改密碼流程如何保存新憑證。

結果是一條可驗證、低副作用且不需要原始明文密碼的復原路徑。更重要的是，它也再次說明：密碼雜湊不一定只是無害的資料庫內容。當協定允許它直接充當登入材料時，它就是密碼。