- Researchers desoldered a Eufy HomeBase 2 flash chip, edited its recovery image and got a root shell past the serial console lockout.
- The attack needed physical access, so it matters most for hubs in shared spaces. The post does not say whether the new Wi-Fi password scheme can be broken.
- Ask vendors whether recovery images are signed and what protects a device once someone holds it.
A lock that lives in software, on a device an attacker can hold, protects less than it appears to. A researcher's teardown of the Eufy HomeBase 2 shows the point well. It also leaves a question open: does the Wi-Fi secret the hub fetches over a wiring bus hold up? The post does not say.
The write-up comes from the researcher behind adepts.of0x.cc, published October 10, 2026. It covers firmware version 3.4.2.2h on the HomeBase 2, the hub in Eufy's camera and doorbell range. The researcher worked with his brother-in-law, Óscar Lestón. This is one device and one firmware build. The post describes no remote attack, and we saw no vendor response.
What the researchers did
The hub's flash memory chip is soldered to the board with no pins to attach test hooks. A clip-on reader failed. Powering the chip also woke other components on the board, and three reads produced three different checksums. The dumps were useless.
So they desoldered the chip and read it off the board. This time three reads matched. One 64 KB block was unreadable, probably damaged during removal. It sat at 0x500000, the load address of the main system image.
How the serial lockout worked
The hub has a serial debug port, called UART. In production, pressing Enter on it launches a small script, /sbin/login.sh. The script checks one stored setting, debug_log. If debug mode is off, it exits and the prompt restarts. That is the endless loop the researchers saw.
Interrupting the bootloader did not work. The ways to switch the boot mode were out of the researchers' reach, they wrote. They found no straight route to flip the setting.
The fallback door
The researchers noted that the firmware contained nothing encrypted. And the damaged main image had an intact neighbour: a much smaller recovery image at 0xe70000. With the main image broken, the bootloader would have to load the recovery one.
That damage was an accident of desoldering, and the researchers' route relied on it. A deliberate attacker would need to corrupt the main image on purpose to force the same fallback.
They unpacked the recovery image, removed the lockout so it opened a root shell, repaired its checksums and wrote it back to the chip. After resoldering, the hub failed to load the normal image, fell back to the edited recovery image, and gave them a shell.
The lesson here is about trust. A recovery path is part of the device's security. If it will boot an edited image, the lock on the main path can be sidestepped once someone can force that fallback. The source describes only checksum repair, not a signature check, before the edited image ran.
The Wi-Fi password question
The researchers also wanted to know how the hub makes the password for its management Wi-Fi network, named OCEAN_ plus the device's MAC address. They had expected a weak scheme, as a 2024 paper described. This one looked different.
The firmware first checks a device-type parameter against 0x0C. If the value differs, the password comes from the MAC address. If it matches, as it did here, a different path runs.
For this device type, a function called z8GetSN talks over a wiring bus called I2C. It sends command 0xC1 and reads 17 bytes back. The hub mixes that value with its serial number using HMAC-SHA256, a standard keyed fingerprint. It then encodes the result as text and sets it as the Wi-Fi password.
The serial number follows a known template, so it is predictable. The researchers wrote that the only unknown is the value returned by z8GetSN.
The post leaves the key question undecided. It does not say whether the researchers recovered that value, or whether the password can be broken. A secret that is hard to read may be the stronger defense. The source gives no evidence either way.
What the access gave them
The recovery image was bare. The filesystem was not mounted, and the kernel lacked Wi-Fi and I2C modules. The researcher built a staged filesystem and a fuller BusyBox toolkit, then loaded a debugger. Getting the main service binary running took about three hours of trial and error.
He then gave his terminal logs to Codex, an AI coding tool, and asked for one script to repeat the steps. By his account the next morning, he barely remembered the details. AI did not break the device. It removed the repetition from the work.
Questions to put to your team
This attack needed hands, a soldering iron and a Raspberry Pi-based reader. That is modest equipment. Treat it as a physical-access finding. For any connected hub or camera you deploy, ask:
Does the vendor sign its recovery images, or only checksum them? Do debug ports stay reachable in production? Where are device secrets stored, and what stops someone who holds the device from reading them? Who can physically reach these devices, in offices, shared spaces or staff homes?
A serial lock on a device you can hold is a speed bump. Ask vendors what protects the device once someone has it in their hands.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: adepts.of0x.cc.
