Why we're covering this
Most of Kokobo’s work sits on the compliance side of the fence — helping device manufacturers reach EU Cyber Resilience Act (CRA) and Radio Equipment Directive (RED / EN 18031) readiness. Talks like this one are a useful reminder of what the other side of the fence actually looks like in practice. When a regulation asks a manufacturer to protect debug interfaces, avoid hardcoded secrets, or secure the boot chain, this is the concrete adversary work those requirements exist to raise the cost of.
The researcher, who presents under the name Tokala and is based in Christchurch, New Zealand, walked an audience through the complete hardware-hacking process on a TP-Link Tapo home security camera — a genuinely inexpensive, plug-and-play consumer device. What makes the talk worth writing up is not any single exotic technique. It’s the discipline: a clean, start-to-finish research loop that anyone entering SOHO (small office / home office) device research can learn from. Below is our walkthrough of his process, with the technical steps stated precisely.
The device
A TP-Link Tapo pan/tilt home camera, bought overseas as a plug-in monitor for a relative’s house. Around US$30. As the presenter noted, the internal construction is surprisingly good for the price — which is part of the point. “Cheap” does not mean “carelessly built,” and it certainly doesn’t mean “easy.”
01 Reconnaissance
The first move is always identification. Photograph the board, zoom in on the tiny silkscreen markings, and catalogue every chip by part number. Then pull the datasheets — the single most valuable resource in hardware work. The datasheets revealed that the main processor is a camera-specific system-on-chip (SoC) with pan/tilt motor drivers, audio, and sensor interfaces integrated on-die, and — critically — a full pinout. With roughly 88 pins on the package, the datasheet is what tells you which pads are worth talking to.
02 The obstacle, and the X-ray
Probing the debug pads with a multimeter, Tokala found them dead. This is a deliberate anti-tamper measure: manufacturers frequently depopulate components — removing resistors on debug/UART lines that are smaller than a grain of rice — specifically to slow down researchers.
To confirm, he X-rayed the board (using an upgraded imaging setup, an improvement over the older dental-X-ray rig he’d used in the past) and could see the copper traces running toward footprints that simply had nothing on them. To reach the live pins without soldering, he used a pin-board jig — sharp spring pins held down with adhesive putty — tapping directly onto the pads he needed. Through a USB-to-serial converter, that gave him the console.
03 UART: so close, then stuck
The UART output (also referred to as TTL or serial — closely related interfaces) streamed the boot log: manufacturer, chip identifiers, and the memory layout the bootloader uses. All useful. But at the end, it dropped to a login prompt, and the usual credential guesses (root, admin, password, and combinations) went nowhere.
Rather than burn time brute-forcing an unknown password, he pivoted — the decision that defines the rest of the talk.
04 Pulling the flash
The board carries an SPI flash chip: the device’s persistent storage, functionally its hard drive, holding roughly 8 MB. He desoldered it — it’s soldered flat to the board, so removal demands controlled high heat and real care, since the adjacent grain-of-rice resistors and capacitors will happily reflow and fall off if disturbed. He then read the chip on an inexpensive programmer (the cheap reader is why the chip needed a pinned holder rather than going in directly) and dumped the full contents to a binary file.
05 Making the dump intelligible
A raw 8 MB hex dump is unreadable on its own. Enter binwalk, which scans a firmware blob and identifies the structures inside it — here, the flash partition table. The partition of interest was a SquashFS root filesystem: compressed, read-only, and near-ubiquitous on IoT devices precisely because it’s small and tamper-resistant at runtime.
He carved that partition out of the full image with dd (skip to the partition’s offset, copy out that slice), then re-ran binwalk on the carved file as a confirmation check — if binwalk no longer recognized it, his offsets were wrong. They weren’t. Finally, unsquashfs decompressed the partition into a browsable Linux filesystem tree.
A small note: he called dd “an old DOS command.” It’s actually a Unix/POSIX utility — a harmless aside that doesn’t affect the method.
06 The root move: editing inittab
This is the elegant part, and the step most often garbled in secondhand summaries — so let’s be exact.
He did not repack a modified SquashFS. Because SquashFS is read-only at runtime, editing the live filesystem and rebooting would just revert. Instead, he worked on the extracted tree offline and targeted a single configuration file: /etc/inittab, which tells Linux what to run at startup. The relevant TTY line invoked /bin/login — the exact thing demanding a password on the UART console. He changed that entry to launch /bin/ash (a shell) instead.
Then he reassembled the full flash image, not the SquashFS: original head + his modified middle section + original tail, padding the middle with zeros because his change made it slightly smaller. Preserving the byte offsets is essential — the bootloader looks for partitions at fixed locations, and shifting anything breaks the boot.
He reflashed the chip, resoldered it, powered on — and the console dropped straight to a root shell, no login at all.
07 Living off the land
With root, the post-exploitation phase is where the device’s real capabilities surface:
- BusyBox restore. The camera runs BusyBox — a single binary bundling stripped-down Linux utilities. The manufacturer had trimmed it to limit what an attacker could do. He mounted the device’s microSD card carrying a full ~400-command BusyBox build, restoring every utility the vendor had removed.
- Unexpected Ethernet. The SoC exposes a USB hub. With some wiring and a USB-Ethernet adapter, a Wi-Fi-only camera suddenly had wired networking. (An HDMI adapter, by contrast, didn’t come up — the hub is USB 2.0, and he simply noted it “said no” rather than diagnosing further.)
- His own access point. Rather than trust the vendor’s provisioning flow — which hands the SSID and password off to a remote service — he stood up his own hostapd configuration and controlled network access to the device directly.
- Serving from the device. Using the onboard web server and full BusyBox, he demonstrated the camera serving content, with a candid caveat that the browser was doing much of the heavy lifting.
He closed by noting he deliberately skipped deep software reverse engineering of the telemetry path — the device’s data flow to servers in China is stated on the packaging — but flagged the certificates baked into the flash as the natural next target for anyone wanting to work back up toward the device’s APIs.
What this means for device makers
Read as a compliance exercise, the talk is a checklist of the exact weaknesses the CRA and RED / EN 18031 are written to address:
- Debug-interface exposure. Depopulating UART resistors is speed-bump security, not a control. An X-ray and a pin jig defeat it in minutes. EN 18031 expects debug and test interfaces to be genuinely disabled or authenticated in production, not merely awkward to reach.
- A defeatable boot/login chain. The login prompt was undone entirely by an offline edit to a single config file, because the platform lacked secure/verified boot. Without signature verification on the firmware image, “we ask for a password” provides no assurance at all.
- Read-only filesystems are not integrity protection. SquashFS’s read-only nature stopped live tampering but did nothing against reflashing a modified image. Integrity has to be enforced by the boot chain, not by the filesystem’s mount options.
- Secrets in flash. Hardcoded certificates in an extractable flash image are a textbook CRA concern. Anything on the chip is readable once the chip comes off the board.
- Post-exploitation surface. A restorable BusyBox and a live USB hub turned a single-purpose camera into a general-purpose Linux host. Minimizing on-device tooling and locking down peripheral buses materially raises attacker cost.
None of these findings are unique to this camera — they’re representative of a large share of the consumer IoT market, which is exactly why the CRA is arriving with teeth. For manufacturers, the lesson is that physical-access resistance and a verified boot chain are not optional extras; under the incoming regime they are table stakes.