Skip to content

China firmware renews rrcheck via POST /f/c to hardcoded api-cn.roborock.com (not just /devices/{did}/sh) — capture + body format #228

Open

Description

@mark-schultz-wu

The finding

On a China-market P20 (roborock.vacuum.a184, factory 02.22.56,
blind-onboarded against local_roborock_server, never online), rrcheck
renews on two paths:

  1. GET /devices/{did}/sh on the token host, roughly daily — the
    path PR fix(routes): support /devices/{did}/sh endpoint for access renewal on newer firmware #199 answers.

  2. POST /f/c to https://api-cn.roborock.com/f/c at every
    startup. The host is hardcoded, not derived from token.r. Form
    body, signed like its other firmware-API calls (checkda,
    createca) with RSA-SHA1:

    cpuid=<32-hex>&did=&pid=&platform=RR&sn=&tz=Asia%2FShanghai&uid=&signature=

Packet capture shows the robot opening TLS 1.3 to
api-cn.roborock.com twice per boot. Until we fronted that host, the
handshake failed hostname validation and no HTTP request was ever
sent
— so this path never shows up in local server logs. An absent
/f/c (#161, #182) is not evidence the firmware doesn't call it.

Consequences:

What we could not do

Terminate that TLS honestly — no CA will issue for
api-cn.roborock.com. We front it with a certificate minted from the
publicly-compromised eMudhra intermediate keys
(emudhra.we-have-a-problem.com), which this firmware's frozen trust
store still accepts. Happy to expand on the method; the capture stands
without it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions