Firmware Extraction: Why Readable Flash Changes Your Threat Model

A readable flash chip can turn physical access into a copy of firmware, configuration and stored credentials. On an accessible, unencrypted SPI NOR device, that may require little equipment. On other products, packaging, board layout, disabled debug interfaces, readout protection or encryption make the task substantially harder, or prevent a usable dump through the tested path. There is no general time-to-dump: access to one memory chip is not the same as extracting the entire device, and a firmware image does not necessarily contain private keys.

"Physical access means the device is lost anyway" skips the important questions: what can an attacker actually read, which secrets are present, and what do those secrets authorize? A local compromise can remain local. It can also expose shared credentials or excessive backend permissions. The difference belongs in the threat model before the product ships.

How extraction actually works

Possible entry points include external SPI NOR or eMMC storage, a UART-accessible bootloader with read commands, and an enabled debug interface. Each requires verification: in-circuit reads can fail because other components drive the bus; UART does not imply a shell; an exposed JTAG or SWD connector does not imply unrestricted memory access. Desoldering, a different adapter or analysis of a vendor-specific format can change the effort substantially. Record the hardware revision, protection configuration, read method and memory regions actually obtained.

Illustrative example, not a recorded finding. The abbreviated console output below shows a possible workflow for a compatible SPI flash. Offsets and contents are examples, not measurements from a customer device. A format match identifies a candidate artefact; its use and permissions still need investigation.

ILLUSTRATIVE EXAMPLE$ flashrom -p ch341a_spi -r dump.bin
Reading flash ... done.
$ binwalk dump.bin
DECIMAL       HEX         DESCRIPTION
-----------------------------------------------------------------
262144        0x40000     squashfs filesystem, 4.0
1114112       0x110000    xz compressed data
3145728       0x300000    PEM certificate  <-- public artefact
3211264       0x30F000    PEM RSA private key  <-- investigate role

What a dump actually leaks

An update package may already make the firmware available without physical access. A device-specific dump can add provisioned data: Wi-Fi PSKs, backend tokens, TLS private keys, service credentials or customer configuration. Whether these are present in readable form depends on the product. Certificates, public keys and endpoint addresses are not secrets by themselves. For each recovered private key or token, establish its purpose, scope, validity and whether the backend still accepts it.

How this changes the threat model

If an attacker extracts a unique per-device private key, that device identity is compromised, it does not thereby become a shared fleet credential. The attacker may impersonate that device wherever the key is accepted. Other device identities are not automatically compromised. The benefit of independent credentials remains, provided the backend binds each authenticated identity to its permitted resources and operations and supports effective revocation.

Fleet-wide impact needs an additional condition: for example, the same secret is shared across devices, an API trusts a freely chosen device ID, or one device is authorized to administer others. A unique key with overly broad permissions can therefore still cause extensive damage. Conversely, a dump containing no usable authentication secret does not by itself enable device impersonation. Firmware also supports offline analysis of implementations; reproducing a suspected vulnerability may still require hardware, runtime state or additional access.

Mitigations, what actually moves the needle

The realistic goal is not "unreadable"; it is "expensive and bounded":

• Verify the relevant read protection. Check MCU readout protection and debug restrictions on production devices, and assess external storage separately. Write protection and secure boot do not by themselves prevent reading flash.
• Encrypt sensitive storage, protect the keys. A raw dump of encrypted regions should yield ciphertext if the decryption key is not also recoverable. Verify which regions are covered and where plaintext becomes accessible during operation.
• Keep private device keys out of bulk storage. A correctly integrated secure element or TEE can keep a private key out of the dump. Public certificates and other credentials may still be present; host compromise can also permit misuse of a protected key (see Device Identity).
• Bound the compromise in the backend. Combine unique credentials with per-device authorization, tenant isolation and tested revocation. Include existing sessions and derived tokens in the revocation design.

Test your own device first

Test extraction on a representative production unit before field deployment. Set an access model and time budget, document successful and unsuccessful paths, and catalog any recovered secrets and their permissions. A failed attempt establishes a limit of that test, not proof that extraction is impossible. A successful dump establishes what was readable on that unit, not a fixed effort or outcome for every product.