Dumping SPI Flash off the Board
When the firmware download is encrypted and the console is locked, there is still the chip itself. Most connected products keep their firmware in an external SPI flash chip, an eight-pin part you can read directly with a clip and a few dollars of hardware. Here is how a flash dump actually goes, and why storing secrets in that chip is a losing bet.
When You Read the Chip Directly
Every other route to firmware can be closed off. Downloads can be encrypted, the serial console can be disabled, the debug port can be fused shut. The external flash chip is harder to hide, because the main processor has to be able to read it at boot. If the processor can read it, so can you, with the right clip and a steady hand.
Step 1: Identify the Chip
Find the flash, usually a small eight-pin SOIC package near the processor, and read the part number off the top. That tells you the capacity, the voltage, and the pinout from the datasheet. A typical find is a 16 MB Winbond part running at 3.3V, which a standard SPI clip handles without trouble.
Step 2: Pick Your Method
There are three reliable ways to get at the chip, and the right one depends on how cooperative the board is once you clip on:
Step 3: Read It With flashrom
Wire a cheap CH341A USB reader to the chip and let flashrom probe it. If it identifies the part, you are ready to read:
# probe first to confirm the chip is detected
flashrom -p ch341a_spi
flashrom 1.2 on Linux 6.1.0 (x86_64) Using clock_gettime for delay loops. Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi. No operations were specified.
# read the whole chip to a file
flashrom -p ch341a_spi -r dump1.bin
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi. Reading flash... done.
Step 4: Read Twice and Verify
A single read off a clip can be subtly corrupt if a pin makes poor contact. Always read a second time and compare hashes before you trust the image:
flashrom -p ch341a_spi -r dump2.bin sha256sum dump1.bin dump2.bin
Reading flash... done. 9f2c... a1b4 dump1.bin 9f2c... a1b4 dump2.bin
Matching hashes mean the dump is clean and you can move on to extraction. Mismatched hashes mean reseat the clip and try again before you waste hours analyzing a corrupt image.
Defending Against a Flash Dump
You cannot stop someone from reading an external chip, so the defense is to make the contents worthless once read. Encrypt the firmware at rest and decrypt it only inside the processor, keep private keys in a secure element or the MCU’s protected key store rather than in external flash, and treat anything in that chip as public. A dump should yield ciphertext, not secrets.
Where This Fits
Flash extraction and the question of what it reveals sit at the center of a product security assessment. Pulling the image is step one; judging whether the contents are protected is the real deliverable, and that analysis is the kind of work we do at Berkner Tech.