Recovering a Xiaomi AX3000T Without a Factory Reset: Following the Mesh Trust Chain¶

This article documents security research performed on personally owned hardware. To avoid turning it into a copy-and-run intrusion guide, the firmware-embedded secret, real credential material, packet contents, MAC addresses, session data, and weaponized code are intentionally omitted. Do not test systems or networks without authorization.

TL;DR¶

A Xiaomi Router AX3000T (RD23, Global firmware 1.0.42) was still running normally as the controller of a home Mesh network, but both its administrator password and the associated Xiaomi account had become unrecoverable. A factory reset would have restored access, but it would also have destroyed the working network and Mesh configuration.

The recovery came from chaining two design flaws in the router's CAB Mesh service. Mesh-node authentication depends on a shared secret embedded in the firmware, and the subsequent configuration-sync message contains the administrator account's SHA-1 and SHA-256 verifiers. Xiaomi's web login and password-change protocols accept proofs derived from those verifiers; they do not fundamentally require knowledge of the original plaintext password.

Without resetting, rebooting, flashing, changing network mode, or disrupting the Mesh, we were able to:

create a normal administrator session;
set a new password through the official password-change API;
create a fresh session using the new credential; and
repeat the login check in a separate read-only run.

The original password was never cracked, recovered, displayed, or stored.

The Situation and Safety Constraints¶

This was more complicated than the usual forgotten-router-password case:

neither the Xiaomi Wi-Fi nor Mi Home account was accessible;
the Google email account originally linked to the device was disabled;
the Mac was connected through the existing Mesh;
the network was healthy and could not be taken offline merely to recover the UI; and
preserving the full configuration was a hard requirement.

The research therefore began with explicit safety boundaries: no factory reset, reboot, firmware flash, netmode change, MQTT publication, or Mesh configuration acknowledgement. Static firmware analysis came first. Live testing was limited to reversible, read-only checks until the exact behavior was understood.

Eliminating the Obvious Paths¶

A bounded service inventory of the primary router and Mesh satellite found no usable SSH or Telnet service. Management APIs rejected invalid sessions, MQTT refused anonymous access, and several command-injection paths documented for older Xiaomi routers still required a valid LuCI session on this model.

That distinction matters. A vulnerability reported for one Xiaomi router family cannot safely be assumed to work on another hardware revision or firmware branch. Some public Mesh replay techniques can also change the router's operating mode, which was too risky for a live home network and was deliberately avoided.

Firmware Analysis: The Mesh Sync Boundary¶

The closest firmware image that could be obtained and fully unpacked was RD23 Global 1.0.49. The live router ran 1.0.42. The 1.0.49 CAB Mesh components, Lua controllers, and browser cryptography supplied a map for interpreting the live protocol, but every critical conclusion was ultimately tested against the 1.0.42 device rather than inferred from the newer image alone.

CAB Mesh listens on TCP 19553 for node admission and configuration synchronization. Two trust-boundary failures combine into the recovery path:

node authentication uses a firmware-embedded HMAC secret shared across devices; and
after authentication, the primary router sends both administrator password verifiers in the configuration-sync payload.

The fields correspond to the legacy SHA-1 and current SHA-256 account records. They are not plaintext passwords. In Xiaomi's authentication design, however, they are effectively replayable password equivalents.

The read-only probe intentionally stopped after receiving the initial sync message. It completed only the minimum mutual authentication, read the first configuration payload, and disconnected without sending the final “sync succeeded/apply” acknowledgement. That verified the disclosure without enrolling a temporary node or applying any configuration.

Why the Verifier Is Enough to Log In¶

When a user enters a password into the web interface, the browser does not transmit it directly. It first derives the account verifier, combines that value with a one-time nonce, and sends a proof:

login_proof = SHA256(nonce || stored_verifier_256)

The router stores the same stored_verifier_256, so it can reproduce and compare the proof. The problem is that Mesh configuration sync discloses that verifier to an authenticated peer. Anyone holding it can answer a fresh nonce without reversing the original password.

That is why this result is best described as administrator access recovery, not plaintext password recovery. From a security perspective, the disclosed verifier must be treated as password-equivalent material.

Why the Normal Password Page Still Asks for the Old Password¶

After login, Xiaomi's “Change administrator password” form still requires the original password. At first glance, that appears to end the recovery path.

Tracing the browser JavaScript into the Lua controller showed that the plaintext old password is used only on the client to derive three values:

a nonce-bound proof of the current password;
a new legacy verifier protected using the current SHA-1 verifier; and
a new SHA-256 verifier protected using the current SHA-256 verifier.

The backend set_name_password flow validates the nonce and current-password proof, decrypts the two new verifier records, and saves them to the normal account configuration. The backend never needs to see the old plaintext password.

Because Mesh sync had already provided both current verifiers, the recovery tool could reproduce exactly what the official form would have generated. This did not skip the password check; it passed the existing check with credentials that the Mesh service had improperly disclosed.

The shared secret, AES parameters, packet layout, and complete request format are intentionally excluded from this article.

Designing a Safe Recovery Flow¶

The implementation was split into a read-only preparation stage and an explicitly authorized write stage.

sequenceDiagram
    participant Owner as Device owner
    participant Tool as Local recovery tool
    participant Mesh as CAB Mesh service
    participant LuCI as Management interface

    Tool->>Mesh: Minimal node authentication
    Mesh-->>Tool: Initial configuration sync
    Note over Tool,Mesh: Disconnect without apply acknowledgement
    Tool->>LuCI: Login with nonce and verifier proof
    LuCI-->>Tool: Normal administrator session
    Owner->>Tool: Enter new password twice, hidden
    Owner->>Tool: Final confirmation: CHANGE
    Tool->>LuCI: Official password-change flow
    LuCI-->>Tool: Update accepted
    Tool->>LuCI: Create a fresh session
    LuCI-->>Tool: Protected read-only endpoint succeeds

Several safeguards were deliberate:

default execution verifies the chain and login only; it does not write;
the new password is collected through hidden terminal input, never a command-line argument;
the password must be entered twice and satisfy the firmware's policy;
a separate final confirmation word is required before submission;
verifiers, MAC addresses, session tokens, and runtime cryptographic parameters are never printed;
success is followed immediately by a fresh login and protected read-only request; and
a completely separate read-only run repeats the authentication check.

Result on the Live Router¶

The recovery succeeded on the AX3000T RD23 running Global firmware 1.0.42:

a new administrator password was saved;
the new credential created a fresh administrator session;
a protected read-only API returned successfully;
a second independent login verification also passed;
the existing Mesh, SSIDs, Wi-Fi passwords, and network configuration remained intact; and
there was no factory reset, reboot, firmware flash, or router-mode change.

This result establishes the behavior of one tested device and firmware version. Other regional images, hardware revisions, and releases require separate verification.

Security Impact¶

This chain has greater impact than an ordinary information leak. An attacker who can reach the CAB Mesh service from the local network and reproduce firmware-based node authentication may obtain password-equivalent material sufficient to create an administrator session. Password complexity does not mitigate a protocol that voluntarily releases the verifier used to prove knowledge of that password.

The main root causes are:

a shared firmware-embedded secret across devices;
administrator verifiers included in Mesh configuration sync;
an authentication protocol in which possession of the verifier is sufficient to construct a valid proof; and
insufficient separation between the Mesh control plane and router management plane.

How the Vendor Should Fix It¶

A complete fix must address both node identity and account data rather than blocking a single endpoint:

Provision a unique, rotatable Mesh identity for every device instead of a shared firmware secret.
Use a mutually authenticated pairing protocol with forward secrecy.
Never synchronize administrator password verifiers to Mesh peers.
If a node needs management authority, issue short-lived, scope-limited, revocable credentials.
Bind the Mesh control service to a dedicated backhaul interface and enforce source and rate limits.
Rotate existing Mesh and administrator credentials during the security update and invalidate old sessions.
Provide an official local recovery path that preserves configuration, such as a physical-button gesture combined with a one-time code.

Responsible Publication Scope¶

This article discloses the root cause, validation strategy, and remediation guidance while withholding the material needed for immediate reproduction against an unfamiliar network. Owners of potentially affected hardware should install a vendor-confirmed fixed release, keep untrusted clients off the management network, and never expose the router's administration services to the public Internet.

References¶

Closing Thoughts¶

The interesting part of this recovery was not finding a hidden “no-password” administration page. It was following the complete trust chain: how a Mesh node is authenticated, what the router synchronizes, what the web login actually proves, and how the official password-change flow stores new credentials.

The result was a testable, low-impact recovery path that never needed the original plaintext password. More importantly, it reinforces a broader security lesson: a password hash is not automatically harmless database residue. If a protocol allows the hash to act directly as authentication material, the hash is the password.