Ep. 2 - Basics: Flash
Show Notes
Intro
Starting to define more of the core purpose of the show: to share wisdom and give back in some of the same measure we've received. In this 1/n series on flash, we're going to be getting into pulling information down from memory on an embedded system. Typically, pulling flash or looking for a debug interface are the first steps in trying to RE an embedded device.
The Problem:
You have a board...what do you do? The first step is to begin investigation of what exists. What can you identify? Can you identify flash? Consider this picture from a board of mine. There are a few different chips that we see here, can we find the datasheets?
The Solution, find the datasheet and start trying to pull bytes:
I just did a google search for the part in question. I start to determine that he part number is actually W25Q80DVNIG and it is in a SOP-8 package. I couldn't find one the specific chip, but I did find one for the family of these (W25Q80DV). From this, you can start get the voltage levels, pins, and certain things to which may be consequential later such as if the (in this case SPI flash) is configured to be dual or quad and therefore doing bidirection IO on the pins otherwise designated to be DI (data in) or DO (data out). Below is a snapshot of the datasheet with our pinout.
If we start to reconcile where the pieces are in the datasheet along with the pins on the device under test (DUT), in the context of the PCB that it is on, we can gain a little confidence that we are onto the right track.
For these types of devices, there is a clip you can purchase to sit right on top. And then you can hook onto that cable with an FTDI device (or other devices) to read the memory off. What are we hoping for here? Well, we're hoping for firmware (as a zipped archive, in the context of a filesystem, or as raw binary), application configuration data, cryptographic keys, or generally anything which is going the help us understand the device and repurpose it for our goals.
The cable I'll be using to run this is the C232HM multipurpose cable that can do up to 30 Mbps. It supports JTAG, SPI, and I2C. On a linux machine, you'll need libmsse installed. Also, the DUT is going to be the slave board and our cable the master, so we'll need to make sure the out of our cable is going to the in of the DUT. After we hook things up correctly, we'll want to install libmpsse, the open source library for SPI/I2C control via FTDI chips, and that comes with a utility called spiflash. From there we should be able to pull from the SPI flash.
Note: when you run ./configure, if you get 'no' answers back, chances are if you're on a debian based build that you can 'sudo apt search <missing item>' and installing that will resolve the check. Also, the link above uses python2. After you build it, if you do so in the src director, the spiflash program will be in the /examples directory. In the command-line example below, I assume you aliased the spiflash.py to wherever you want the permanent home for the script to be, assuming you want to be able to run it from any directory you're in.
Start the pull with small reads. You won't be able to use the FTDI cable until you install the drivers linked above. If you see it pop up with dmesg and assigned a TTY you should be good. Here is my dmesg.
[2509927.167517] usb 1-4: new high-speed USB device number 19 using xhci_hcd
[2509927.337226] usb 1-4: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00
[2509927.337229] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2509927.337230] usb 1-4: Product: C232HM-DDHSL-0
[2509927.337231] usb 1-4: Manufacturer: FTDI
[2509927.337233] usb 1-4: SerialNumber: FT1K75R7
[2509927.680056] usbcore: registered new interface driver usbserial_generic
[2509927.680069] usbserial: USB Serial support registered for generic
[2509927.684627] usbcore: registered new interface driver ftdi_sio
[2509927.684643] usbserial: USB Serial support registered for FTDI USB Serial Device
[2509927.684738] ftdi_sio 1-4:1.0: FTDI USB Serial Device converter detected
[2509927.684780] usb 1-4: Detected FT232H
[2509927.695387] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0
[2510038.796607] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Now, you should be able to use the cable with the clip. Assuming you have it all hooked up correctly, it could be good to pull. It can be useful to pull a small amount at a time to make sure its working. Generically, the command below would be "read data from the SPI flash to file named fileName, read s bytes worth and verify it is a good pull by pulling it twice and doing a diff of the two pulls.
$sudo spiflash -r <fileName> -s <bytes> -v
Once confident, you can also pull at a higher clock rate. The default is 15MHz, but as mentioned before this should go up to 30MHz.
$ spiflash -r 25Q80DVNIG.bin -s 1000 -f 30000000 -v
FT232H Future Technology Devices International, Ltd initialized at 30000000 hertz
Reading 1000 bytes starting at address 0x0...saved to 25Q80DVNIG.bin.
Verifying...reads are identical, verification successful.
From the above we can see that it took the data rate, read 1000 bytes, and was able to do so two times, thus 'verifying' a good pull.
An important note here, is that the flash is an 8M-bit flash. The program operates in bytes. That is ok though, you can use bash to figure it out for you. Let's go ahead and try to pull all of the memory as fast as we can.
$ spiflash -r 25Q80DVNIG.bin -s $((0x800000)) -f 30000000 -v
FT232H Future Technology Devices International, Ltd initialized at 30000000 hertz
Reading 8388608 bytes starting at address 0x0...saved to 25Q80DVNIG.bin.
Verifying...reads are identical, verification successful.
Great, now the interesting business starts to take place. We can run strings, binwalk, xxd to look at the bytes, pull it into ghidra if it is flash...all manner of things to start to see if it is what we think. More on those topics in future episodes.
Some places to look for datasheets:
Look on fcc.io (depending on the part) to see if there is more information to glean from the FCC number(s) on the device.
If the device is older and you come across a broken link, the Internet Archive's Wayback Machine is clutch.
Sometimes https://www.manualslib.com is great. Same is true with https://www.datasheetarchive.com/ or http://www.datasheetcatalog.com
For oldddddd parts, the old IC master volumes can be found here: http://www.bitsavers.org/components/icMaster/
Depending on the part, some google dorking with the part number or emailing support and asking nicely can work.
Jameco, Digikey, Mouser can have some if they sell the chip.
Despite your best efforts, sometimes the part was sold with an NDA and the datasheet is just not forthcoming. You may have to traipse around some forums and ask. Some I know have occasionally asked
Google Dorking Tips (using Google's built-in keywords to sift quickly for specific search results)
site:websitethatmayhavedatasheets.com filetype:pdf
<name of chip> filetype:pdf
If you search around for some doking cheat sheets there are many other possibilities.
This process doesn't just apply to flash, it also applies to any chip on the board, especially the uC. The reason being is that when you pull the memory, the next step is going to be pulling it into Ghidra and starting the software RE process. During that process you're going to run into functions which are driving certain uC pins in some fashion and you'll need the data sheet to understand what pin is going where. Chances are you're going to have to be tracing some PCB leads as well. Things escalate quickly.
Different Flash Form Factors:
There are too many for one sitting. Generally speaking, memory has different logical as well as physical forms. The one above of course was SPI, but there are others (SPI, NOR, NAND, eMMC). Physically these come in different forms too. One is thin small outline package (TSOP), there are different pin counts for these. There are also small-outline initgrated circuits (SOIC), plastic small-outline packages (PSOP), shrink small-outline packages (SSOP), thin-shrink small outline packages (TSSOP) and more. In addition to TSOP, there are also ball-grid array (BGA). With those there are many sub-types too (CABGA, DSBGA, LBGA, TABGA, VFBGA). Generally speaking, SPI has few pins and is easiest to get-after in my opinion. NOR has separate address/data pins and pin maps differ by vendor. NAND is typically 8 or 16 pins and address/data are multiplexed; pin mpas for them regardless of the form factor are mostly standard. Finally, eMMC is basically NAND but you typically talk to the controller to interface with them.
As you can see from the screenshot below, looking on mouser.com for TSOP-48 NAND flash yields a huge amount of additional results not mentioned.
TL866 Universal Programmer
If you have a type of flash besides SPI you may end up pulling it off. After you have it pulled, you can place it in a TL866II, TL866CS/TL866A directly into the ZIF socket or with one of the physical adapters which let you place the adapter in the board. If you're using the TL866, you might do well to purchase one of the kits which has many different physical form factor flash. Additionally, you may investigate using an Arduino.
Below is the 866 I purchased with a small smattering of the different form-factor adapters. At about $20 extra, I think it was worth the purchase.
<Placeholder, TL866 tutorial will go here when complete>
Other Show Mentions
The Internet Archive has some repos of some ROMs for SNES allegedly.
SEC Xtractor is another tool you can use for extraction. It is a tool for directly dumping memory chips and identifying on-chip debugging/programming interfaces. Can act as UART-to-USB converter and JTAG adapter. The BOM/design is on the github too if you wanted a weekend project.
JBC has some fantastic rework/soldering stations. Replaceable/removable tips that are hot very fast and some cool extractors. If you see this JBC, please sponsor us :D will shill/10 products.
Here is a video to the suction cup/hot air station I mentioned in the show. Not necessarily for the homegamer though at 2.3K.
Places to yank electronics:
Goodwill is a classic, Transfer and waste stations in your county, university IT departments. Perhaps we'll work in the future on a map.
Development Kits can be a good way to both learn the forward-programming of a device as well as often coming with some flash attached. The idea here is that you can program the device and then extract the firmware so you're working from a known dataset to build confidence.
https://www.digikey.com/en/product-highlight/s/stmicroelectronics/stm32-kits
Pictured below, and old TI DSP board I found randomly looking at eBay for about 60 bucks. It might be a pain to find the old toolchain to get it chooching, but it is a good place to start.
