Unclouding the Ecovacs O500

Root access, TLS interception, and the path to local control

Philipp A. Baer

October 26, 2026

About

Computer Science · Security · DevSecOps · Robotics

• Research: Dr.-Ing. Kassel University; distributed systems and cooperative robotics.
• Robotics: RoboCup in Ulm and Kassel; Robotics at DFKI RIC Bremen.
• Today: Software architecture, security, and infra/DevSecOps at GE HealthCare.

baer.one

• Core question: can this mower work without Ecovacs services?
• Brief background: computer science, security, DevSecOps, robotics; Kassel, RoboCup, DFKI.
• Today: software architecture, security, infrastructure/DevSecOps at GE HealthCare.
• Open-source projects: WallDisplay and WaterRower Local BLE.
• Motivation: keep useful devices under local control. It is still work in progress.

Keep things local

I try to keep things off the cloud as much as possible.

• Local services: Home Assistant, ESPHome, Frigate for video, Forgejo for Git.
• Unclouded devices: Dreame vacuum with Valetudo; Sonoff NSPanel with NSPanelEasy.
• Open-source projects: WallDisplay · WaterRower Local BLE.

One device remains to uncloud: the Ecovacs O500 Panorama.

• Goal: keep as much of the home setup as possible off vendor clouds.
• Local services: Home Assistant, ESPHome, Frigate, Forgejo.
• Open-source projects: WallDisplay and WaterRower Local BLE.
• Remaining target: Ecovacs O500 Panorama.

The Ecovacs O500 Panorama

What would it take to make an owner-controlled mower work without Ecovacs services?

• Primary goal: control the robot locally (start, stop, and status).
• Secondary goal: local map storage and retrieval, add a Bumper-like service [2].
• Maybe future: local video streaming (it has a separate Kinesis / STUN / ICE path).

Understand the TLS and MQTT paths, authentication / topic semantics, firmware and boot chain. Get a root shell on the device first.

Broke the debug interface in the process. Mower is still functional, UART echo prevents reliable command execution.

IMAGE SLOT · Ecovacs O500 Panorama in the yard; landscape photo

• Priority: local start/stop/status; then maps and a Bumper-like service.
• Video is a later goal (separate Kinesis/STUN/ICE path).
• MQTT 3.1.1 framing observed over TLS; auth, topics, and command loop remain open.
• Debug interface is broken; mower still works. Local control is not solved.

Cloud control: what we observed

Android · Frida observed

• POST /api/iot/endpoint/control [1]
• Android · 0.0.22 · start/stop · auto
• Auth and response not captured.

Home Assistant · working

• GOAT O500 (300lc5) via Ecovacs MQTT [1, 3].
• GOAT command topic: iot/p2p/clean [3].

Inferred: Android API-to-MQTT handoff.

• Frida on rooted LineageOS / ECOVACS HOME 3.14.0 observed the app constructing an HTTPS POST to /api/iot/endpoint/control.
• Observed envelope constants: request, Android, 0.0.22; start/stop selectors shown. No HTTP header names at hooks. No query values, auth values, or response captured.
• Home Assistant control works for class 300lc5. Read-only HA inspection showed an O-series mower entity and telemetry; no action was sent during this inspection.
• Public GOAT integration documents iot/p2p/clean as the firmware command topic, while the built-in path uses iot/p2p/clean_V2; it also handles pushed charge/schedule state.
• This demonstrates a working HA/MQTT route, not that Android publishes MQTT. The API-to-MQTT handoff remains inferred.
• Separate probe observed MQTT 3.1.1 CONNECT framing and subscriptions. jmq-ngiot- is a hostname label, not protocol evidence.

Cloud control: connection overview

Path	Endpoint type	Route	Finding
App control	HTTPS API	Android → NG-IoT	Frida observed POST Response not captured
HA control	MQTT over TLS	Home Assistant → Ecovacs MQTT → O500 (300lc5)	Control works through Ecovacs cloud
Video	Kinesis + STUN/ICE	O500 → video services	Separate cloud path

Still inferred: app API → MQTT handoff [1].

Untested: control with Ecovacs services unavailable.

• Android request method/route/selectors observed inside the app; no response/authentication captured.
• HA control works for class 300lc5; read-only API inspection showed the mower entity and telemetry.
• HA control uses Ecovacs MQTT, so a locally hosted controller does not imply cloud-independent control.
• Android API-to-MQTT backend handoff remains inferred. Our separate MQTT framing probe does not by itself prove accepted credentials or commands.
• Video uses Kinesis/STUN/ICE; access uses the robot PIN.

The mobile app

Test setup: Rooted Android (LineageOS) · ECOVACS HOME 3.14.0 · Frida [1]

Control API: POST api-ngiot.dc-eu.ww.ecouser.net/api/iot/endpoint/control [1]

Observed envelope: header.m=request · header.channel=Android · header.ver=0.0.22

Probe:

• TLS 1.3, Let’s Encrypt certificate.
• App trust remains untested (pinned or not). No client certificate or private key found.
• Body-level authentication unknown (no header names visible at OkHttp hooks)

• Rooted LineageOS · ECOVACS HOME 3.14.0; Frida inspected OkHttp metadata before HTTPS. No credentials or bodies collected.
• Control API: /api/iot/endpoint/control; constants: request, Android, 0.0.22. No header names at inspected hooks; body auth unknown. No Android MQTT calls documented.
• Direct API-host TLS probe: TLS 1.3; Let’s Encrypt chain and hostname validated by system trust. Handshake only; app proxy trust/pinning remains unknown.
• Setup aside: 192.168.0.1:8888/req.do (GetDevInfo, SetApConfig) is for initial Wi-Fi provisioning via the temporary AP—not LAN control.

The mobile app: Start/Stop request shape

POST /api/iot/endpoint/control

body.data.act              start | stop
body.data.content.type     auto

Frida observed the app constructing this request shape. The API itself was not tested, and no response was captured.

Other observed body.data keys: name, schedAct, sid, subsets, using (values withheld).

Analysis paused

• Home Assistant as well as the robot itself interact only via MQTT.
• Is the IoT API worth being inspected at all?

• Frida finding only: the OkHttp hook captured the app constructing these selectors.
• No independent API test or response capture; server acceptance and mower action are unknown.
• Analysis is ongoing, but no rooted phone is currently available for more app-side inspection.
• Other fields, identifiers, headers, and response bodies were excluded. Body-level auth/signatures remain possible.

The mobile app: What public research adds

• Working O500 path: Home Assistant controls the GOAT O500 via MQTT, class 300lc5 [1, 3].
• GOAT-specific Home Assistant integration [3]
  • Send control to iot/p2p/clean, not iot/p2p/clean_V2
  • Handles pushed charge and schedule state.
• 2025 community capture: same /api/iot/endpoint/control, clean_V2 request family [4].
• It records start, pause, resume, stop, and go (iOS, China-region).

The Android app’s HTTPS endpoint remains a Frida request-shape finding [1]. Ecovacs’ Open Platform documents a separate API [5].

• Home Assistant API inspection found an O-series mower entity in docked state and telemetry. Class 300lc5 control works; no control action was invoked during inspection.
• Public ha-ecovacs-mower documents the upstream iot/p2p/clean_V2 vs GOAT iot/p2p/clean mismatch, plus handling for pushed onChargeInfo / onScheduleTaskInfo. Community fix, not official protocol documentation.
• This establishes a working MQTT control route, not Android MQTT actions or the private app API’s authentication.
• MatterXiaomi’s June 2025 X5 Pro / China-region iOS capture independently shows api-ngiot.../api/iot/endpoint/control?si=<redacted>&apn=clean_V2&fmt=j.
• Same start/auto selectors; also pause, resume, stop and go. This is a vacuum and iOS capture; don’t transfer undocumented semantics to O500.
• si is redacted and unexplained. It suggests query metadata merits inspection but is not evidence of its meaning or authentication role.
• Ecovacs Open Platform docs describe a separate public API, not this private app endpoint.

Find the console

Debug Head (Robot) UART adapter (PC)

10-pin header

Pin	Function
1	3.3 V rail
2	X5 UART TX
3	GND
4	X5 UART RX
7	Baize UART TX
8–9	Unassigned
10	1.8 V rail

X5 console [1]

Horizon X5 ASIC BootROM
U-Boot 2022.10 · Linux 6.1
Ubuntu 22.04 LTS · systemd
console=ttyS0,115200n8

• Pins 2 TX / 4 RX · 115200 8N1
• Interrupting autoboot reaches Hobot>.

Serial link

• 3.3 V · 115200 8N1 · common GND
• X5 TX: pin 2 · X5 RX: pin 4

• Baize TX: pin 7 carries boot/OTA logs; G1 Baize, V0.3.12. Role and RX unknown; no commands sent. DEF CON G1 material doesn’t identify Baize.
• X5: Pinout confirmed. Pin 4 input interrupts autoboot to Hobot>; boot: X5 ROM → U-Boot 2022.10 → Linux 6.1 / Ubuntu 22.04.
• Initial working wiring: USB-UART TX → X5 pin 4 RX; X5 pin 2 TX → USB-UART RX; common GND, 3.3 V logic.
• U-Boot command input and UMS were usable in the original setup.

Inside the firmware

U-Boot selects an A/B slot and verifies it [1, 6].

• system_a/b is read-only under dm-verity [1, 6]
• /data is a separate writable userdata partition [1].

• X5: Ubuntu 22.04, Linux 6.1, systemd; U-Boot selects A/B and calls AVB.
• system_a/b: dm-verity protected, read-only. /data: separate writable userdata.
• Boot log names ROS/vendor services; Hydra was confirmed running. Not a complete package inventory.

Test 1: Temporary boot parameter

Question: can Linux start a maintenance shell from a one-boot kernel argument?

1. U-Boot: append init=/bin/sh to the boot arguments temporarily in RAM.
2. Boot the known _a slot with hb_avb_helper.

We skipped eco_ab_select to avoid updating the A/B boot-attempt record.

Outcome: no shell obtained

UART echoed id and Ctrl-C, but returned no prompt or command output. The echo does not confirm that the shell started. No flash or boot files changed; power-cycle restored the normal environment [1].

• Replaced updatebootargs temporarily in RAM to append init=/bin/sh.
• Invoked hb_avb_helper on known _a slot; avoided eco_ab_select metadata writes.
• UART echoed id and Ctrl-C, but returned no prompt or command output. Inconclusive; not root access.
• No U-Boot/system flash changes; temporary environment cleared on power-cycle.

Test 2: use the bundled recovery image

boot_a is a FIT bundle with two boot configurations [1, 8]:

Configuration	Contents
boardid-0x2000	Normal mower boot
boardid-0x010202	x5-evb-v2-recovery with a ramdisk

We loaded boot_a into RAM at 0x90000000, then selected recovery:

bootm 0x90000000#boardid-0x010202

This ran the bundled recovery configuration for one boot; it did not install a new bootloader or write the image to flash.

• iminfo found both configurations inside the existing boot_a FIT image.
• Loaded that image into RAM at 0x90000000; bootm selected the recovery configuration by name.
• The recovery configuration includes a ramdisk. No evidence it provides a usable shell: no UART output, USB/ADB device, or normal LAN address was observed.
• It was a one-time RAM boot; power-cycle returned to normal boot. [1]

Neither temporary boot gave us a shell

The init=/bin/sh attempt echoed id and Ctrl-C, but returned no prompt or command output.

The recovery configuration gave no UART output, USB device, or normal LAN address.

These tests were inconclusive—not root access. Power-cycle restored normal boot.

• No maintenance access: no shell prompt or command output.
• Echoed input does not prove init=/bin/sh ran.
• No persistent change observed.

Find the boot hook from U-Boot

Read-only inspection: we examined selected files on system_a at U-Boot to trace the startup sequence [1]. No full image dump or system-partition write was involved.

U-Boot tools: ext4ls lists files; ext4load reads them into RAM; md.b displays bytes.

Files inspected:

autostart.service · /usr/bin/autostart.sh
serial-getty@.service · /usr/bin/serial_tty.sh

What they showed:

• autostart.service runs after ROS and invokes /usr/bin/autostart.sh.
• The script launches /data/autostart/*.sh with start in the background.
• No User= override: the system service runs as root.

• Initial boot-log review showed ROS and systemd services, and serial-getty starting then stopping without a login prompt. It did not establish the autostart mechanism or script identity.
• At U-Boot, ext4ls, ext4load, and md.b were directed at system_a to inspect the service and scripts listed above.
• Exact per-file command lines and RAM addresses were not preserved; do not reconstruct them from inference.
• This inspection established the hook and root context. Later, UMS exported the separate writable userdata partition so the bootstrap could be installed.

Why serial login was unavailable

The boot log: serial-getty@ttyS0 started, then stopped. No login prompt [1].

On system_a, serial-getty@.service calls /usr/bin/serial_tty.sh:

if [[ $1 != "ttyS0" || -f /data/serial_to_be_run ]]; then
    /sbin/agetty ... "$1" "$2"
fi

The marker enables agetty but supplies no credentials. I left it absent.

The root shell uses a separate hook: /data/autostart/*.sh, launched after ROS [1]. Neither this hook nor its installation depends on the failed boot-parameter experiment.

• Boot log: serial-getty@ttyS0 starts/stops without login prompt.
• Wrapper skips agetty unless /data/serial_to_be_run exists.
• Marker not created; it would not provide credentials or root.
• Root shell came from separate /data/autostart mechanism; system image stayed read-only.

Export userdata over USB

Reach U-Boot (UART)

• Interrupt autoboot over serial and wait for Hobot>
• Send ums 1 mmc 0:10 at the prompt [1].

Export userdata (USB)

• U-Boot presents the eMMC filesystem as USB mass storage.
• The host detected a 10.5 GiB ext4 disk at /dev/sda.

Install the hook (USB)

• Mount the disk on the host
• Copy the startup script, sync and unmount before stopping UMS.

• UART was the command channel to U-Boot; UMS then exposed the selected eMMC userdata filesystem over the separate USB data connection.
• Command: ums 1 mmc 0:10. Controller 1 worked; controller 0 did not enumerate. In this firmware mmc 0:10 is GPT partition 16 (partition indices are parsed as hex).
• Host enumerated a 10.5-GiB ext4 userdata disk as /dev/sda. Mounting that filesystem on the host enabled reading and writing persistent /data files.
• After copying the bootstrap, sync and unmount the host filesystem before stopping UMS and booting normally.
• This was USB Mass Storage, not ADB and not file transfer over the serial wires. The command itself was sent over UART.
• Reaching Hobot> is U-Boot access, not a Linux login. The separate root-shell route follows.

Successful route to the root shell

1. Reach U-Boot: connect UART and interrupt autoboot at Hobot> [1]. No boot-parameter change is needed.
2. Install the hook: run ums 1 mmc 0:10. Mount the exported ext4 userdata on the host; copy o500/tools/goat_serial_bootstrap.sh to autostart/10-serial-root.sh, set mode 0700, then sync and unmount cleanly.
3. Boot normally: after ROS starts, autostart.service runs the script as root. It stops serial-getty, configures /dev/ttyS0, and launches Bash. Verify: GOAT# id → uid=0(root).

Separate failed test: init=/bin/sh is unrelated. UMS mapping is firmware-specific. The hook persists in /data; remove it through UMS.

• The 3-step route is independent of the failed RAM-only init=/bin/sh attempt.
• This records the successful UART-to-root-shell procedure.
• In the tested U-Boot, mmc 0:10 is GPT partition 16 (partition indices are parsed as hex); controller 1 exported userdata as host /dev/sda.
• Copy the reviewed payload o500/tools/goat_serial_bootstrap.sh to the userdata filesystem as autostart/10-serial-root.sh, mode 0700; sync and unmount before leaving UMS.
• The first script failed because the stock getty competed for ttyS0; this payload stops it, sets 115200, then execs interactive Bash.
• Verified: normal boot produced GOAT#; id returned uid=0(root). No network service is opened; verified system remains read-only.
• Script persists in userdata and runs at every normal boot. Remove that file through UMS to disable it.

ADB was not a useful route

After the root-shell path was established, the USB-A port was checked: it enumerated as hobot / xj3, but ADB remained unauthorized [1].

No ADB shell or filesystem commands were attempted; this route was not investigated further.

• ADB is separate from U-Boot USB Mass Storage (UMS), which carried the /data script.
• Host saw the ADB gadget, state unauthorized; no usable access was established.
• No shell/filesystem commands sent. Not pursued further.

Get Hydra talking locally

Hydra is the mower process that connects to Ecovacs’ MQTT endpoint [1].

• Endpoint: jmq-ngiot-*.
• Hydra config option mqCa points to a writable TLS trust file: /data/certs/master.pem.

We redirected the MQTT endpoint to a local TLS listener (signed by a short-lived test CA) and placed both certificates (Ecovacs, ours) in /data/certs/master.pem:

• ❌ Ecovacs CA first: TLS handshake failed.
• ✅ Test CA first: TLS 1.3 handshake succeeded.

Restored the original trust file, removed the redirect. MQTT authentication or commands not tested.

• Hydra handles mower-side MQTT; app-facing NG-IoT API is separate HTTPS.

• Config references mqCa; no client certificate/private-key path found.

• jmq-ngiot-… is the server hostname prefix, not a protocol name.

• Initial self-signed server cert rejected (bad_certificate): validation, not proof of pinning.

• First CA append failed locally (missing PEM newline); original restored and checksum matched.

• Vendor CA first failed; test CA first worked: Hydra effectively used first bundle cert.

• Test used expected jmq-ngiot-… SNI and a source-restricted redirect.

• Original CA restored byte-for-byte; redirect removed. Hydra reconnected to Ecovacs.

• MCStatus: OnConnect observed on normal endpoint.

• TLS success proves server trust/connection only—not normal device auth or local commands.

MQTT framing observed

With the TLS trust path established, our metadata probe acted as a permissive MQTT peer, not a full broker [1]:

• It accepted Hydra’s MQTT 3.1.1 CONNECT without checking the username/password.
• It did not request a robot client certificate; the live Ecovacs endpoint does.
• Hydra sent four QoS-1 subscriptions; the probe acknowledged them.

Implication: a local broker can skip Ecovacs client-certificate and MQTT credential checks. Bumper supports a dedicated MQTT listener, but O500 compatibility has not been tested [2].

Still unknown: command and status topics, payloads, and a working start/stop/status loop. The stock app’s HTTPS API is separate.

• The local harness returned accepted CONNACK without checking CONNECT credentials, then SUBACKed Hydra’s four subscriptions.

• It was a metadata probe, not a faithful broker: it did not request a client certificate or test command/status handling.

• A local endpoint may choose to omit Ecovacs authentication; Bumper itself has not been tried against the O500.

• Credentials, IDs, full topics, and payloads withheld.

• Live Ecovacs endpoint requested a client certificate; the local harness did not. Client identity is unresolved.

• App-to-MQTT handoff and status return remain unconfirmed; the stock app API is separate HTTPS.

UART RX failure ended this test run

Before the interruption

• We installed a /data/autostart bootstrap and verified a root shell on normal boot.
• We redirected Hydra to a local TLS/MQTT probe and observed CONNECT plus four subscriptions.

Then: UART RX stopped accepting commands. Normal boot still reached GOAT#, but commands returned no output. The echo source and electrical cause remain unverified [1].

Open question: Bumper supports a dedicated MQTT listener, but O500 topic and status handling have not been tested [1, 2].

• The verified root-shell route and local MQTT probe were completed before the later RX failure.
• Post-failure, normal boot still reached GOAT#; id appeared as bytes on adapter RX but produced no visible output.
• Do not treat the adapter echo as proof of X5 TX or command execution. Root cause is unresolved.
• UART input failure currently blocks U-Boot/UMS maintenance. The root bootstrap remains installed.
• Bumper’s dedicated MQTT listener is documented; O500 command/status semantics remain unknown.

What we proved and what remains

Proven

• /data/autostart yields a root shell.
• Successful local TLS 1.3 handshake.
• A stub MQTT peer
  • accepted CONNECT,
  • acknowledged four subscriptions,
  • skipped AuthN/AuthZ.

Still unknown

• MQTT command and status topics and payloads.
• Whether Bumper can work with the O500.
• Whether local start, stop, and status are possible.
• How the stock app hands off to MQTT; its API is separate HTTPS.

• Confirmed: root shell, local TLS 1.3, MQTT CONNECT and four subscription exchanges with a permissive metadata peer.
• The peer did not validate MQTT credentials or request a robot client certificate; this is not a faithful cloud-auth test.
• Unknown: Bumper compatibility and MQTT command/status semantics. The stock-app HTTPS API is a distinct interface.
• Live-device follow-up is blocked by UART RX; camera remains a separate path.

Afterward: RX damage blocked maintenance access

The earlier UART setup reached U-Boot, accepted commands, and enabled the root-shell installation. After the RX pin was damaged, maintenance input stopped working.

Normal boot still reaches GOAT#, but id produces matching bytes on the adapter RX without visible command output. The echo source is unverified; the command may not be reaching Bash.

The bootstrap remains installed. UART cannot currently remove it, UMS cannot be started, and USB ADB remains unauthorized [1].

• This is a later hardware/access problem; it does not change the successful earlier route.
• Post-damage setup shown in the connector photo: USB-UART TX → SN74LVC1G125 → pin 4 RX; pin 2 TX returns to adapter RX.
• Buffer is powered from adapter 3.3 V, /OE grounded, common ground; 100 nF VCC/GND capacitor is installed and active.
• A 100 Ω series resistor appears in the photo by its bands, but identification is uncertain; prior notes say the tested 100 Ω part was removed.
• Static buffer checks passed, but the buffer did not restore command execution. RX echo source remains unverified; see research log [1].

Questions

What result would change your mind about local control?

• Invite questions: TLS interpretation, MQTT evidence, UART echo, and what would establish local control.

Literature · research & community

• [1] Philipp A. Baer. Ecovacs GOAT O500 research log. Field notes, captures, firmware inspection and test results; updated 26 Oct 2026.
• [2] Brian Martin. “How does Bumper work?”. Bumper project documentation, GitHub; describes its emulation of Ecovacs cloud services and observed XMPP/MQTT paths. Accessed 26 Oct 2026.
• [3] Rickard Nord. Ecovacs Mower for Home Assistant. Open-source integration, GitHub; GOAT-specific MQTT commands and state handling. Accessed 26 Oct 2026.
• [4] MatterXiaomi.com. “Part5 - ecovacs: Vacuum cleaner commands”. Blog post, 4 Jun 2025; community examples of clean_V2 requests.

Literature · platform & specifications

• [5] Ecovacs Robotics. Ecovacs Open Platform. Official developer portal; consulted 26 Oct 2026. Its public API is distinct from the private NG-IoT endpoint discussed here.
• [6] D-Robotics. X5 Chip User Manual, v2.0.0, §4.4.9.1 “OTA Functionality and Introduction”. Platform reference for OTA and A/B partitions; not evidence of the O500’s exact configuration.
• [7] Dennis Giese and Braelynn Hacker. “Reverse engineering and hacking Ecovacs robots”. DEF CON 32 presentation, 2024; GOAT G1 research, with different hardware from this O500.
• [8] Marian Balakowicz, Bartłomiej Sieka, and Simon Glass. Flattened Image Tree Specification, v1.0. Open Source Firmware Foundation, 11 Apr 2026; FIT image components and configurations.

• Entries [2]–[4] are community work; protocols and commands can vary by model.
• [5] documents Ecovacs’ public platform, not the private app endpoint investigated here.
• [6] and [8] provide platform/specification context, not proof of the O500’s exact firmware setup.

Slide deck changelog

• 26 Oct 2026 · feat: Generate deck changelog and align graph typography (#35)
• 26 Oct 2026 · fix(o500): open slides outside VitePress client router (#34)
• 26 Oct 2026 · feat: add walldisplay, revise home, improve o500 presentation (#33)
• 10 Oct 2026 · fix: open the title slide directly (#29)
• 26 Sep 2026 · feat: improve site and integrate o500 research (#27)