Hardcoded Secrets
Keys, passwords, certificates, and tokens baked into firmware instead of provisioned at runtime. Static, fleet-wide, and often found with a single grep.
Hardcoded secrets are credentials, API keys, certificates, or tokens embedded directly in firmware or binaries instead of being provisioned, derived, or fetched at runtime. They are the single most common finding in IoT firmware review because they are trivial to plant and trivial to find.
What it is
A hardcoded secret is any sensitive value that ships inside the image: a root password in /etc/shadow, a Wi-Fi PSK in a config file, an MQTT password compiled into a daemon, a TLS private key in .rodata, a cloud API token in an ESP32's NVS partition. The defining property is that it is baked in at build or provisioning time and is the same across every unit of that model, so it cannot be rotated without shipping new firmware to the whole fleet.
Why it matters
Hardcoded secrets are static and shared, which makes them uniquely damaging. Extract one from a single 50 USD device on your bench and you often hold a key that works against every device of that model in the field: the same default root password, the same shared TLS key, the same cloud token that talks to the vendor backend. What should have been per-device provisioning becomes a fleet-wide master key, and because it is in firmware it cannot be revoked without an update the vendor may never push.
How it works
Developers embed secrets for convenience and never remove them. A build script writes the Wi-Fi credentials into an image; a "temporary" debug account survives to production; a shared certificate is compiled in so every device trusts the same CA. Because these values are part of the image, they are readable by anyone who can dump the flash, and they are byte-identical across the fleet. On ESP32 devices the runtime secrets that are not in the code, SSIDs, PSKs, cloud tokens, live in the NVS partition, which is plaintext unless flash or NVS encryption is enabled.
From an attacker's view
After extracting the rootfs or dumping the flash (a SOIC-8 clip on the flash chip with a CH341A programmer is the standard offline read), hunt across every layer:
# Filesystem: grep the extracted rootfs for obvious credential patterns.
grep -rniE 'pass(word)?|secret|token|api[_-]?key|BEGIN (RSA|EC|OPENSSH)' rootfs/
# Binaries: pull printable strings, then filter.
strings -n8 daemon | grep -iE 'key|token|http|mqtt|://'
# Find embedded PEM keys and certs anywhere in a raw dump.
grep -aboE -- '-----BEGIN [A-Z ]+-----' dump.bin
# ESP32: carve the NVS partition out of the flash dump and read it.
strings -n6 nvs.bin | grep -iE 'ssid|psk|token|mqtt'
Look for base64 blobs, -----BEGIN PEM markers, high-entropy strings that survive a strings pass, and hostnames next to what looks like a password. Cross-reference recovered keys against cloud endpoints, other firmware versions, and known default-credential lists.
Pitfalls
- Encoding and light obfuscation hide from a naive grep: a secret may be base64, hex, or XOR-obfuscated, so it will not match a plaintext pattern. Decode candidate blobs and check entropy before concluding there is nothing.
- A found string is not automatically a live secret, test scope before you trust it; some are stale test values, some are per-device after all.
- Encryption moves the problem, it does not remove it: if the decryption key is also in the firmware (or in eFuse the running chip can use), the secret is still effectively hardcoded.