/FIRMWARE · 2026-08-05
The boot chain is the map
ROM → bootloader → kernel → rootfs → the vendor daemon. If you cannot name those hops on this image, you do not know what you unpacked.
A firmware tree with 4,000 files still needs those hops named. We write what runs first, what it loads, what it verifies, and which process still talks to the network after init before we open httpd in Ghidra.
This is inventory of an offline image, or of a lab device named in the letter. It is not a guide to glitching production units.
The hops
ROM / SPL
Often not in the upgrade file. The SoC boots a mask ROM, then a small SPL from flash. If the customer only sent “the app partition,” say so. You cannot audit a boot ROM you were not given.
Bootloader (U-Boot and cousins)
Environment, bootcmd, whether it accepts a netboot, whether it checks a signature before bootm. Default U-Boot env in the image is a finding when it still has a vendor password or an extra boot path the product UI never mentions.
Kernel + dtb
Tells you the board the vendor actually built, not the SKU name on the box. UART pins in the dtb are how we know a lab console exists — see the UART note. Kernel version plus config fragments beat guessing CVE soup.
Rootfs and init
/etc/inittab, systemd units, procd, a vendor rcS. The product is whatever that script execs and leaves listening.
What we write
given: gateway-fw.bin (hashed)
missing: mask ROM (not in image) — stated
bootloader: u-boot, bootcmd=..., extra netboot path
kernel: 5.10.x, dtb shows uart0
rootfs: squashfs, /etc/init.d/vendor-httpd
listens: :80, :22 dropbear, :9000 vendor
- What was in the image vs what we never saw (ROM, OTP, companion MCU).
- What is verified at each hop — or not.
- Which process we will actually reverse, and why that one.
If the updater can skip the bootloader check, that is an update-path finding, not a boot-chain mystery. Keep the two notes separate. Do not mix them in one paragraph of the report.