Reverse-engineering my Eufy NVR S4 for local Home Assistant access, got UART reading working, but U-Boot write is blocked
I own an Eufy NVR S4 (T8N00) with 8 PoE cameras, and the fact that I can't pull live streams locally into Home Assistant is baffling. Everything goes through Eufy's cloud, and the P2P protocol they use (NDT, not PPCS) isn't supported by any existing integration.
So I started reverse-engineering the device.
What I've done so far:
Found the UART console on the mainboard, three solder pads on the bottom edge of the PCB (RX, TX, GND in a neat little test-point header). Soldered in an FTDI adapter, fired it up at 1.5Mbaud, and got a full boot log. Turns out the SoC is a Rockchip with verified-boot enabled .
The blocker:
The device has hotkeys for CTRL+C at the SPL and U-Boot level, which on Rockchip usually triggers download mode (rockusb) a path to dump the firmware and potentially access the internals without breaking security. But here's the catch: Eufy compiled U-Boot with Cmd interface: disabled. There's a hotkey listener, but no shell prompt. And when I try to send CTRL+C over the serial line to trigger download mode, nothing happens.
The read side works perfectly I'm getting full visibility into the boot process. The write side is what's failing. Whether it's:
- The actual CTRL+C isn't reaching the device (some kind of serial flow control issue)
- The hotkey is compiled out even though the string is there
- The USB-C port isn't the one connected to the SoC's OTG (most likely)
...I haven't pinned down yet.
Why this matters:
The camera feeds are sitting on an isolated PoE subnet behind the NVR. They're literally never leaving my network. I'd like to at least try to pull them into Home Assistant without routing everything through Eufy's servers. I'm not trying to hack anyone else's device, I'm not ignoring warranty (I made a full backup before touching anything), and I'm not selling this. I just want local streams.
The ask:
Has anyone else poked around Rockchip devices with disabled U-Boot shells? Or hit a wall with write-only serial interfaces? Curious if there's a path I'm missing whether it's a different trigger for download mode, or if the USB-C is a red herring and I need to look at the DP/DM test pads instead.
Also open to alternative approaches if anyone's got them.
----
06/26 EDIT / UPDATE — progress + a correction:
Spent a long session on this and learned a lot. TL;DR: a couple of my original assumptions were wrong.
1. The write side actually works fine. This was the big one. I confirmed the serial TX→device RX is solid: U-Boot prints a Hotkey: <key> line during boot, and it reflects whatever control char I'm spamming — send CTRL+C and it prints Hotkey: ctrl+c, send CTRL+U and it prints Hotkey: ctrl+u. If my input weren't reaching the SoC, that line couldn't change. So it was never a flow-control or contact problem. Lesson: don't assume the write path is broken just because nothing "happens."
2. Correction on the hotkeys. It's not CTRL+C at both stages. The SPL stage uses CTRL+U (SPL Hotkey: ctrl+u), and U-Boot proper uses CTRL+C. On Rockchip the SPL ctrl+u is normally the rockusb/download trigger — so that should be the way in.
3. ...except it isn't, on this build. I spammed CTRL+U continuously (various timings, from 30ms gaps down to a full no-gap flood), captured both hotkey banners cleanly each time, and the box always boots straight through to Starting kernel. No rockusb device ever enumerates. Combined with Cmd interface: disabled on U-Boot, it really looks like Eufy neutered both the U-Boot shell and the SPL download action — the banner prints but the action is gone.
4. USB-C is a red herring (confirmed). It never enumerates anything on the host, in any boot state. So it's host-only, not wired to the SoC's USB OTG. The OTG is almost certainly broken out on the DP/DM/ID/VBUS test pads instead.
Net result: the UART→download path on this firmware is a dead end. UART is read-only in practice here. Not a wiring issue — it's locked down by design.
Next plan: go lower than U-Boot entirely and force maskrom (BootROM) mode — short the eMMC clock at power-on so the BootROM can't find the boot device and falls back to USB download. That can't be disabled in firmware. Then dump the eMMC over the SoC's real USB OTG (the DP/DM pads) with rkdeveloptool. If/when that works I'll post the dump.
Still very open to other ideas — especially from anyone who's pulled a maskrom dump off a locked-down Rockchip box, or knows whether the SPL download being dead means I'm wasting my time vs. just needing the right pins.
