Reconstructing Device Firmware From SPI Reads

If you wanted to extract the firmware from a mystery device, you might pull the flash chip out of it and toss it into a reader. But if you only had one chance to get it right and couldn’t risk damaging the device in the process, physically removing the chip may seem much less attractive. Reading the chip in-circuit failed — because of course it did — so what does that leave?

Well, if you follow the example of [Matthew “wrongbaud” Alt], the next tool you reach for might be a logic analyzer. In a recent write-up, [wrongbaud] explains the process of identifying, capturing, and ultimately decoding the SPI read operations used to load the firmware from a common W25Q-series flash chip at boot time. He notes it’s not a perfect solution, as in the end you’ll only be able to sniff out what the CPU actually reads, not necessarily the entire contents of the chip, but it’s a big step in the right direction if you’re reverse engineering something in the dark.

Before digging into the decoding of the captured data, [wrongbaud] does what he does best and breaks down the nuts and bolts of SPI communication. Armed with the output from his logic analyzer and the datasheet for the flash chip, he explains how to interpret the various signals at play.

Even if you’re not terribly interested in slurping the firmware from mystery boxes, it’s a great primer on how SPI works and a fascinating read for anyone who’s looking for a better understanding of how chips talk to each other.

Once he’s covered the basics and captured some data moving across the SPI bus, [wrongbaud] moves on to decoding it with Scapy. The powerful Python tool is most commonly associated with the manipulation of network packets, but as demonstrated here, it can be turned loose against other types of data. With a little massaging, it can work through the capture files produced by the logic analyzer and turn it into an image file ready to get loaded into binwalk.

But wait! Just when you think [wrongbaud] was done, he notes something a little odd — the firmware image contains the bootloader and Linux kernel, but there’s a big gap where the filesystem should be. It turns out there’s a little more work to be done, as before the CPU loads the filesystem off of the chip, it kicks into the faster Quad-SPI, which adds two more data lines to the mix. That means more capturing, a dash of extra processing, and a dd one-liner to merge the two image files into one, but [wrongbaud] gets us there in the end.

If this is the first time you’ve run across [wrongbaud]’s work, you’re in for a treat. From his overarching hardware hacking roadmap to deep dives into individual techniques such as fault injection, he’s produced phenomenal content that’s almost guaranteed to teach you something new.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.