/FIRMWARE · 2026-08-07
The finding is often in /etc
Default passwords, Wi-Fi PSKs, cloud URLs, update keys in world-readable files. Look in /etc before you open Hex-Rays.
After unpack, analysts sprint to the biggest stripped ELF. Meanwhile /etc/shadow is still admin:admin, and the update HMAC sits in update.conf next to a comment that says “do not ship.” We have shipped reports where the decompiler found nothing and the tar found everything.
Configs in the image are what the vendor shipped. They are in-scope for an authorized firmware review. They are not a license to log into a customer’s deployed fleet.
Where we look, every time
- /etc/passwd, shadow, dropbear and ssh host keys
- wpa_supplicant, hostapd, vendor wifi JSON
- cloud endpoints, device certs, API tokens in plain JSON
- crontab, init scripts that curl | sh
- NVRAM defaults: a file that looks like a dump of factory env
NVRAM is not mystical
On a lot of gateways, “NVRAM” is a partition plus a userspace tool that prints key=value. The factory defaults are often a file in the squashfs. If that file contains the same WPS PIN for every SKU, that is a finding. If it is empty and the values live only on-device, write “not in image.” Empty is allowed. Do not invent values.
A 20-minute inventory
# after unsquashfs / unblob
find squashfs-root -type f | wc -l
grep -RInE 'password|passwd|psk|secret|api[_-]?key' squashfs-root/etc | head
find squashfs-root -name '*.key' -o -name '*id_dropbear*'
ls -l squashfs-root/etc/dropbear 2>/dev/null
Then read the hits. Most are false. The ones that are not go in the register with path and a quote. Do not paste a live customer token into a slide. Redact in the PDF; keep the original path in the archive they own.
What is not a config finding
An example password in a README the vendor never installs. A test key under /usr/share/doc. Say so. Inflating the count with documentation strings is how you lose the next engagement.