Extracting Firmware from SPI Flash Chips Using a Bus Pirate and Clip-On Probes

The Firmware Is Already There. You Just Need to Ask Nicely.

Every router, IP camera, smart appliance, and embedded Linux device you've ever touched has a secret sitting on its PCB: a small, eight-legged chip that holds everything — the bootloader, the OS, the credentials, the private keys, the hardcoded configuration. It's not behind a firewall. It's not encrypted by a cloud service. It's sitting on a board, millimeters from your hands, waiting to be read.

Firmware extraction is the entry point for nearly every serious hardware security engagement. Before you can reverse engineer a binary, before you can find command injection in a web interface you didn't even know existed, before you can understand what a device is actually doing at runtime — you need the firmware. And in the embedded world, that firmware almost always lives on a SPI NOR flash chip. Extracting it non-destructively, without desoldering a single component, is one of the most valuable skills in a hardware researcher's toolkit.

This guide walks you through the full process: identifying the right chip on a target PCB, understanding the SPI protocol just enough to make sense of what's happening, attaching SOIC clip probes in-circuit, and dumping a raw binary image using a Bus Pirate and flashrom. We'll spend equal time on the parts most tutorials skip — troubleshooting interference from surrounding circuitry, and verifying that what you read is actually what's on the chip.

🎯 TL;DR

4. Foundations & Theory

What Is SPI and Why Does Firmware Live There?

SPI — Serial Peripheral Interface — is a synchronous serial communication protocol developed by Motorola in the 1980s. It's simple, fast, and cheap to implement in silicon, which is exactly why embedded designers love it. A SPI flash chip is a non-volatile memory device: it retains data without power, which makes it ideal for storing firmware that must survive a power cycle.

The protocol uses four signals:

┌─────────────────────────────────────────────┐
│  MOSI  →  Master Out, Slave In              │
│  MISO  ←  Master In, Slave Out              │
│  CLK   →  Clock (master drives timing)      │
│  CS    →  Chip Select (active LOW)          │
└─────────────────────────────────────────────┘

The master (in our case, the Bus Pirate) drives the clock and initiates all transactions. The slave (the flash chip) responds only when its CS pin is pulled LOW. This is important: when CS is HIGH, the chip ignores everything on the bus. When you pull it LOW, you're saying "I'm talking to you specifically."

SPI NOR flash chips — chips like the Winbond W25Q series, Macronix MX25L series, and GigaDevice GD25Q series — typically store between 512KB and 128MB. For most consumer embedded devices (routers, cameras, IoT nodes), you'll encounter 4MB to 32MB chips. These are more than enough to hold a compressed Linux kernel, a root filesystem, and a U-Boot bootloader.

The SOIC-8 Package: What You're Looking At

The physical chip you'll be targeting is almost always in an SOIC-8 package — a small rectangle with four pins on each side, eight total. The package is roughly 5mm × 4mm, making it small but absolutely manageable with the right clip.

Pin 1 is always marked. On the physical chip, it's denoted by a small dot, a notch on one end, or occasionally a line. This is your orientation anchor. Every other pin is numbered counterclockwise from Pin 1 when the chip is viewed from above:

        ┌──────────┐
  CS ──1┤          ├8── VCC
  SO ──2┤  SOIC-8  ├7── HOLD/RESET
  WP ──3┤          ├6── CLK
 GND ──4┤          ├5── SI
        └──────────┘
   (Standard SPI NOR pinout — verify against datasheet)

Always verify this against the specific datasheet for your chip. The general layout above is typical for W25Q-series parts, but variations exist. Pull up the datasheet before you touch anything.

5. Where It Fits in the Workflow

Firmware extraction sits at the very beginning of a hardware security engagement, inside the reconnaissance and artifact collection phase.

Before you can:

• Identify hardcoded credentials
• Find vulnerable services running at boot
• Reverse engineer proprietary protocols
• Analyze update mechanisms for signing weaknesses

...you need the binary. Everything else is downstream of this step.

Once you have a raw dump, binwalk becomes your next instrument — it can identify compression boundaries, filesystems (SquashFS, JFFS2, cramfs), and extract individual components. From there, you might emulate the firmware with QEMU, perform static analysis with Ghidra, or run dynamic analysis by booting the device with a UART serial console attached. The extraction you perform here is the seed for all of that.

6. Key Concepts in Depth

6.1 Identifying the Target Chip

Before you clip anything, spend time with the PCB itself. The goal is to find the SPI flash chip and match it to its datasheet. Here's how to approach it:

1. Look for the SOIC-8 package near the main SoC (System on Chip) or CPU. Flash chips are almost always placed close to the processor that boots from them. On routers, they're often near the Ethernet switch SoC. On cameras, near the image processor.

2. Read the markings on the chip top. The laser-etched text will give you a manufacturer code and part number. Common prefixes: W25Q (Winbond), MX25L (Macronix), GD25Q (GigaDevice), EN25Q (EON). The numbers after the prefix encode the capacity — for example, W25Q64 is a 64Mbit (8MB) chip.

3. Search the part number + "datasheet" in your browser. The datasheet will confirm the pinout, operating voltage (3.3V is standard; some older parts use 5V — this matters for your Bus Pirate settings), and supported SPI modes.

⚠️ Voltage mismatch is a real risk. The Bus Pirate outputs 3.3V logic by default for SPI. Connecting it to a 5V chip without level shifting can damage the Bus Pirate. Verify the chip's VCC before powering anything.

6.2 Attaching the SOIC Clip In-Circuit

The SOIC-8 clip (also called a Pomona SOIC-8 clip or SOIC test clip) is a spring-loaded jaw that grips all eight pins simultaneously without soldering. It's elegant, non-destructive, and fast to attach.

Key attachment steps:

• Orient the clip by matching its Pin 1 marker (usually a red wire or a marked corner) to the chip's Pin 1 dot
• Press down until you feel/hear it seat fully — a partially seated clip is the #1 cause of bad reads
• Check under magnification (a loupe or phone camera zoom works) that each jaw is contacting its respective pin, not bridging two

Wire the clip to the Bus Pirate as follows:

Bus Pirate Pin   →   Flash Chip Pin (SOIC-8)
─────────────────────────────────────────────
MOSI             →   SI   (Pin 5)
MISO             →   SO   (Pin 2)
CLK              →   CLK  (Pin 6)
CS               →   CS   (Pin 1)
GND              →   GND  (Pin 4)
3.3V             →   VCC  (Pin 8)
3.3V             →   HOLD (Pin 7) — pull HIGH to disable
3.3V             →   WP   (Pin 3) — pull HIGH to disable write protection

HOLD and WP are important. If HOLD is pulled LOW, the chip pauses its current operation and ignores the bus — your read will stall or fail silently. If WP is undriven or floating, write protection behavior becomes unpredictable. Tie both HIGH to 3.3V to put the chip in a clean, cooperative state.

6.3 Dumping with flashrom

flashrom is an open-source utility that supports hundreds of flash chips and dozens of programmers, including the Bus Pirate. On Linux, install it via your package manager or build from source.

First, identify the Bus Pirate's serial device:

dmesg | grep tty
# Look for something like: /dev/ttyUSB0

Run flashrom to probe and identify the chip:

flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M

If flashrom detects the chip, you'll see output like:

Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on buspirate_spi.

If you see No EEPROM/flash device found, don't panic yet — this is where troubleshooting begins (see section 6.4). Once identified, dump the firmware:

flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -r firmware_dump1.bin

The -r flag means read. The file firmware_dump1.bin will contain the raw binary image exactly as stored on the chip.

Speed note: The Bus Pirate is not fast. At 1MHz SPI clock, reading an 8MB chip takes several minutes. This is normal. Faster programmers like the CH341A or a Raspberry Pi in SPI mode can do the same job in seconds, but the Bus Pirate is excellent for learning because it exposes you to the underlying SPI mechanics.

6.4 Troubleshooting In-Circuit Interference

This is the section most tutorials skip, and it's where most beginners get stuck. When the flash chip is on a live PCB with power applied, other components share the same SPI bus or power rails and can actively interfere with your reads.

Common failure modes and fixes:

The most reliable approach: power the target device off. When the device is powered down, the SoC is not driving the SPI bus, and you're the only master. Connect VCC and GND through your Bus Pirate clip (or via bench power supply), leaving the rest of the board unpowered. This eliminates most interference.

If you must read with the board powered (rare but sometimes necessary), you risk bus contention — both the SoC and the Bus Pirate driving signals simultaneously. Some researchers use a logic analyzer in parallel to observe what's on the bus before probing.

6.5 Verifying Dump Integrity with Repeated Reads

A single read is never enough. Flash memory, clip contact issues, and signal noise can all produce reads that look successful but contain bit errors. The standard practice is to read three times and compare MD5 hashes:

flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -r firmware_dump1.bin
flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -r firmware_dump2.bin
flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -r firmware_dump3.bin

md5sum firmware_dump1.bin firmware_dump2.bin firmware_dump3.bin

If all three hashes match, you have a stable, trustworthy read:

a3f1c92d...  firmware_dump1.bin
a3f1c92d...  firmware_dump2.bin
a3f1c92d...  firmware_dump3.bin

If the hashes differ, do not proceed to analysis with a corrupted dump. Reseat the clip, lower the SPI clock speed with spispeed=125K, and try again. A mismatched hash means at least one — possibly all — of your reads contains errors.

Once you have a verified dump, hand it to binwalk for initial reconnaissance:

binwalk firmware_dump1.bin

binwalk will identify embedded file signatures — uImage headers, SquashFS filesystems, compressed kernel blobs — and give you a map of what's inside. From there, binwalk -e (extract) carves out individual components for deeper analysis.

7. Alternatives & Comparison

The Bus Pirate is not the only way to talk SPI. Here's how it compares to common alternatives:

The CH341A is extremely popular for this specific task because it's cheap, fast, and natively supported by flashrom. Its weakness is that it operates at 5V by default — which can damage 3.3V chips without a voltage modification. The Bus Pirate, by contrast, is explicitly configurable and transparent about what it's doing at the protocol level, which is why it's the better pedagogical tool.

8. Takeaways & Further Reading

What you've learned here:

• SPI flash chips are the primary firmware storage medium in embedded devices, and reading them in-circuit is non-destructive when done correctly
• Pin 1 orientation and datasheet verification are non-negotiable steps before attaching any probe
• HOLD and WP pins must be tied HIGH to ensure clean, uninterrupted reads
• In-circuit interference from the host SoC is the dominant failure mode — powering the board off eliminates it
• Three reads + MD5 comparison is the minimum bar for trusting a dump before analysis

📚 Further Reading & Resources:

• flashrom project documentation — chip support matrix, programmer list, troubleshooting
• Bus Pirate SPI documentation — protocol modes and wire colors
• The Hardware Hacker by Andrew "bunnie" Huang — the essential long-form reference for hardware security
• Craig Smith's Car Hacker's Handbook — embedded systems extraction in automotive context
• Winbond W25Q128 datasheet — an excellent reference for understanding SPI NOR command sets (JEDEC standard commands)
• binwalk documentation and the Firmware Analysis Toolkit (FAT) for post-extraction analysis
• Joe Grand's hardware hacking courses (Grand Idea Studio) — excellent video content for visual learners

Your next step: Once you have a verified firmware dump and binwalk has mapped its structure, the real work begins. Extracting the root filesystem reveals the actual attack surface — default credentials, custom web servers, telnet daemons, and hardcoded API keys. The chip was never the target. The chip was the door.