Finding Hardcoded Secrets in Firmware
Once a firmware image is extracted, the highest-value findings are often just sitting in the filesystem: an API key in a config file, a private key in /etc, a root password in a script. Vendors commit them during development and forget to strip them. Here is how I hunt hardcoded secrets and prove they are real.
Why Secrets End Up in Firmware
A secret in firmware is shipped identically to every unit. Buy one device, extract it, and you hold a credential that may unlock the vendor’s cloud, sign updates, or log into every other unit. Because the same image goes to everyone, one hardcoded secret is a fleet-wide problem.
Step 1: Grep the Obvious
Start simple. Private keys and tokens have recognizable markers:
grep -rlE 'BEGIN (RSA |EC )?PRIVATE KEY|AKIA[0-9A-Z]{16}' squashfs-root/
squashfs-root/etc/ssl/device.key squashfs-root/etc/cloud/config.json
Step 2: Run a Secret Scanner
Pattern scanners go further, recognizing hundreds of credential formats and verifying which are still live:
trufflehog filesystem ./squashfs-root --results=verified
Found verified result Detector Type: AWS Decoder Type: PLAIN File: squashfs-root/etc/cloud/config.json Verified: true
A verified AWS key means it still authenticates. That is no longer a code-quality note; it is a live path into the vendor’s cloud, shipped in every device.
Three Kinds of Hardcoded Secrets
What turns up, in rough order of impact:
Keeping Secrets Out of Firmware
Provision per-device secrets at manufacturing instead of baking shared ones into the image, store them in a secure element rather than the filesystem, and run a secret scanner in the build pipeline so a committed key fails the build. The goal is that an extracted image contains nothing an attacker can use.
Where This Fits
Secret hunting is one of the first things a firmware review does, and one of the most consistently productive. That analysis is the kind of work we do at Berkner Tech.