Scroll to top

IoT Security Research — From Firmware Image to Published CVE

Embedded boards and IoT hardware security research
Network-connected camera security

Project Overview

This is the research I keep coming back to: consumer and small-business connected hardware — routers, TV boxes, IP cameras and the single-board computers behind them. The method is deliberately unglamorous. Buy the device, pull the official firmware from the vendor’s support page, carve it with binwalk, mount the SquashFS root and read the filesystem before touching a debugger. Then put the live unit on an isolated bench network and watch what it actually does. It keeps producing findings with unusually wide reach, because a single bad decision inside a firmware image ships to everyone who bought that model and is almost never patched after the first year. One of these became CVE-2026-58378 — a TV box shipping with Android Debug Bridge enabled and exposed on the network — published by CISA as advisory VA-26-190-03. Others were fixed quietly by vendors: a static RSA private key identical in every unit, management traffic with no transport encryption, and an unauthenticated debug protocol listening on the LAN.

Challenges

  1. Work from a stripped binary image with no source, no symbols and no vendor documentation.
  2. Handle ARM and MIPS OpenWrt-derived builds, custom packers and non-standard interpreter bytecode.
  3. Tell a genuinely remote-reachable flaw apart from a debug artefact that never leaves the factory.
  4. Prove impact on a live unit without bricking the device or reaching anyone else’s network.
  5. Get a report into the hands of a vendor that often publishes no security contact at all.

Approach

  1. Pull official firmware, carve it with binwalk, mount the SquashFS root and read the filesystem first.
  2. Grep for the boring things — keys, certificates, base64 blobs in init scripts, and every binary that listens on a socket.
  3. Rebuild the interpreter with the vendor’s permuted opcode map to decompile the web UI and recover its real logic.
  4. Confirm every finding on an isolated bench network with the device under test and nothing else on it.
  5. Report to the vendor PSIRT first, escalate to CISA coordinated disclosure when a vendor does not answer, and publish nothing before a fix exists.

Representative Findings

Disclosure, Not Publication

The process matters as much as the finding. Everything goes to the vendor’s PSIRT first, with the exact firmware version, file paths, reproduction steps and a suggested remediation for each issue. Where a product is widely deployed or the vendor is slow to respond, I escalate through CISA’s coordinated vulnerability disclosure programme — that is how CVE-2026-58378 ended up published under VA-26-190-03. No technical detail goes public before a fix exists. In practice the slowest part is rarely the analysis; it is finding a human at the vendor who is allowed to receive the report.

What I Look At