flaShMASH:
a flash dump smashing tool

While inspecting an electrocardiograph (ECG) device from Spacelabs (specifically the 90496 shown in Figure 1) I ran into a little issue. Upon dumping the firmware, it appeared there were no valid strings! I dumped both flash chips and inspected them thoroughly for any valid words, both UTF-8 and UTF-16. After looking at the board for hours, I finally broke out my multimeter, flipped it into continuity mode, and started probing. What I found next led me to a week of research and the creation of flaShMASH.

The ECG machine contains two parallel flash chips. These are TE28F800B3T flash memories and have similar characteristics to the parallel NOR flash I discussed in my previous blog post. They hold the memory for the XPC860, which is the main processor on this board. The XPC860 has a debug header, VGA, an ethernet header that is non-populated and possibly uninitialized, two flash ICs, four RAM ICs, and other ports for communicating with the other board inside the device. Some of the non-populated areas may be features this model does not include. Pro tip: Non-populated components sometimes means supported, but you must add the hardware required to use it…but that is for another blog post.

Flash chips during the 80s and 90s only had limited bus and storage size. A workaround for this was to use a chip select pin that would then allow a hardware engineer to use multiple flash chips together. Dr. Masuoka (a Japanese engineer from Toshiba) implemented a chip select pin for both NAND and NOR flash chips for more onboard flash for a microprocessor to use. The addresses maintain the same structure, never being stacked one upon the other but rather being intertwined with each other. Kinda like when you weave your fingers together or how bricks are laid offset of one another but still connected.

Flash Removal

Pulling the flash chips is fairly easy. I wound up upgrading from my crappy heat gun (used in my last blog post), easily removing the TSOP48 flash chips, and loading them into my flash adapter for reading. I am using a flash programmer instead of the FPGA from my previous post to save time and avoid bricking the flash chips by connecting ground or power to the wrong pins. With a Sharpie, I marked on the board where each flash chip is located before extracting, so I do not lose the place of where they are located or swap them (Figure 2 and Figure 3). Reinstalling the flash chips in the wrong order won’t break them, but it can destroy other hardware and put the processor in a very unhappy state because it is reading the wrong code in the wrong order. More than likely it will not boot and the board should be OK.

For reading the flash memories, I am using an Xgecu programmer from eBay. These are cheap programmers that support a ton of devices. There are different versions of the Xgecu software that exist, some more trusted than others. I recommend running Xgecu software in a VM or an air-gapped system. The Xgecu T56 has support for up to a TSOP56 package, which is quite a big flash IC. Adapters are also cheap on Amazon and eBay for this platform.

Now that the data has been collected, it is time to talk about the tool, flaShMASH. FlaShMASH is a Python script that supports up to four flash dumps of 32 bytes each, totaling a data bus of 128B. Here is an example of a flash chip that would meet those parameters. That would require four TSOP56 packaged flash memories all tied together and used for one processor. The chances of ever coming across an atrocity like that are low but greater than zero outside of data storage devices like SDD and CompactFlash cards.

Downloading and Using flaShMASH

To download flaShMASH, go to this GitHub repository and run

git clone https://github.com/Zetier/flaShMASH
chmod +x ./flashmash.py
./flashmash.py

to execute the script with using the Python interpreter shebang’d in the script. Or use

python3 flashmash.py 

to execute. FlaShMASH needs a minimum of two dumps but can support four. It has flags to get every permutation of the dumps, flip bytes, or reverse dumps. Visit the readme on GitHub to learn more about the usage. Here is a general walkthrough of the tool usage.

Move the binaries you are looking to smash into the same directory that you just pulled down from GitHub.

In this case, I wanted every permutation of the dumps I was feeding into flaShMASH. I wanted to see every bit option and every bitflip that I could. By default, flaShMASH will output files with every bitflip and bus size but will not do permutations unless the -p flag is provided. This is to conserve space. I ran the command

./flashmash.py TE28F800B3T@TSOP48_2.BIN TE28F800B3T@TSOP48_1.BIN -p 

against the binaries in my directory. This outputted the directory MashedFlash where the permutations and combinations exist. Moving into the directory and listing its contents provides the names of the output files. Figure 7 presents an image of the files listed in the directory.

Using grep, you can now look for common hardware strings that may exist in the dumps. Things like months, manufacturers, compilers, password, functions, and the letters (in sequence) of an alphabet are all valid ways to find strings in the dumps. I used password as it is a common firmware string (Figure 8). To look recursively in the dir, use

grep -r {stringtosearchfor}

to find the string you are looking for in the dumps.

To confirm this dump is valid, running strings against it provides some of the valid strings found in the file. As Figure 9 illustrates, this appears to be a valid dump.

This binary can now be loaded into Ghidra per the bitsize that was outputted. Try both little and big endian. In my case, I had a PowerPC part that was big endian. I found it by loading it as a default version of PowerPC 32-bit and looked for which one decompiled better at the same address.

Looking at Figure 10, we see the window on the right is decompiling better than the one on the left. I imported the left as little endian and the right as big endian. Moving forward with the right one, this firmware image can then be reversed out and modifications can be made to the code or inspected for further use. 

I will document in a future blog post what I do next with the ECG machine. Until then, feel free to email hello@zetier.com if you have any questions.