Demystifying Hardware Security – Part III

By Alain Iamburg ·

Riding the Copper Bus

Welcome to Part III of this series on hardware security. In Part II we explored passive data captures of EEPROM read operations over the SPI bus. In this installment, we will be looking at techniques for actively probing and communicating with such chips.

Memory chips can contain interesting data. You can find firmware, device configurations such as passwords or network addresses, and so on.

The tool of choice for this post is the Bus Pirate. This device can be used to interface with a wide range of chips using various low-level communication protocols, and it supports both interactive and binary modes. Think of it as a hardware hacker’s multi-tool. I will only cover some of its features in this article but you should do some reading to see what it can do. I chose this device because it is:

  • Useful for a range of hardware assessment applications
  • Readily available as a fully assembled device
  • Well-documented and supported
  • Inexpensive

Connect the Bus Pirate

Figure 1: Bus Pirate (not connected)

After connecting to the Bus Pirate via USB (at 115200 baud) we are presented with a banner followed by the HiZ> prompt which indicates the device is in high impedance mode by default. A list of commands can be produced with the ‘?’ command.

Figure 2: Bus Pirate Welcome Banner and Command List

If you are using your Bus Pirate for the first time, it is advisable to perform a hardware self-test using the ‘~’ command. For this you will need to tie the Vpu pin to +5V and the ADC pin to +3.3V. This can be accomplished using wires or traditional jumpers.

Figure 3: Jumpers Attached for Bus Pirate Self-Test

Figure 4: Bus Pirate Hardware Self-Test

The ‘m’ command shows the supported modes. Depending on the device you want to talk to, you should select the appropriate protocol. We are dealing with a SPI chip so enter ‘5’. Hit enter to accept the default values for the options but select Normal (2) for ‘output type’. You can read the target chip’s datasheet for the actual SPI configuration parameters.

Figure 5: Bus Pirate Supported Modes

Figure 6: Setting Options for SPI Mode

At this point we are in SPI mode and we can begin talking to SPI chips. For the first example, we will probe the SPI chip contained in the PVED.

Connect Probes to the Device Under Test

Attach the 10-pin probe wire connector to the Bus Pirate and clip the probe leads to the SPI chip. In the previous part of this series, we connected a logic analyzer directly to the SPI bus of live systems. That was OK for passive analysis, but now that we want to actively communicate, we will remove the chip from the host device. This is because we don’t want two devices trying to talk to the chip at the same time.

Figure 7: Bus Pirate with Probe Wires Connected

The PVED was designed with a DIP socket for easy installation and removal of chips, so no (de)soldering is required.

Figure 8: CAT25128 SPI EEPROM in PVED

Remove the SPI EEPROM and attach the correct Bus Pirate probes to the corresponding pins on the SPI chip. A good way to figure out which wires to connect is by issuing the ‘v’ command to get a listing of the Bus Pirate’s pins and their states. As you can see, the output maps the purpose of each probe wire to its color. Look at the following figures to help you make the right connections.

Figure 9: Bus Pirate Pins and Pin States

Figure 10: CAT25128 SPI EEPROM Pin Out from Datasheet


Wire Color (Bus Pirate)

Pin Name (Bus Pirate)

Pin Name (EEPROM)

















Master Out, Slave In




Chip Select




Master In, Slave Out

It should be noted that the color of the Bus Pirate’s wires may differ from the color of the clips that are seen below.

Figure 11: PVED EEPROM Removed and Probed

Bus Pirate Interactive Mode

If you read the last part of this series, you learned that transactions on the SPI bus are performed by toggling the Chip Select pin which is commonly active-low. The Bus Pirate uses left and right brackets to indicate low and high CS transition, respectively. Left and right braces act the same way but they would also print a received byte for each byte written.

Finally the ‘r’ command causes the Bus Pirate to read the specified number of bytes by continuing to run the clock. These commands can be issued one at a time or all at once as shown below. As we saw in Part II, the PVED’s memory chip contained usernames and hashed passwords starting at address 0x80. The EEPROM READ command is ‘3’, and we are reading from the start of memory using a 16 bit address of 0x0080. The first 16 bytes of memory are read starting with the string ‘admin’ (in hex, 0x61 0x64 0x6D 0x69 0x6E).

Figure 12: Reading EEPROM Using Bus Pirate Interactive Mode

This is nice for manual interrogation and performing small reads and writes. However, if we wish to extract useful data from devices over the bus, an automated approach is best.

Bus Pirate Binary Mode

The Bus Pirate exposes an API such that it can be used as a bridge between your workstation and a target chip. You can use a script that leverages the Bus Pirate to read and write SPI EEPROM as shown below.

Figure 13: Reading EEPROM Using Bus Pirate Binary Mode

The EEPROM contents mirror what we discovered passively in the last blog post. We were able to recover the password for ‘acidburn’, however we were not able to crack the password for ‘admin’. So, let’s just change it! Using a hex editor we can edit ‘pved.bin’ to replace the password hash. Here I replaced it with the MD5 hash for ‘opensesame!’ and rewrote the EEPROM using the modified file.

Figure 14: Writing EEPROM Using Bus Pirate Binary Mode

Now, after popping the EEPROM back into its socket in the PVED, we can log in with our freshly minted admin credentials. Using the PVED’s ‘eeprom’ command we can verify the new EEPROM contents.

Figure 15: Reading EEPROM in PVED Shell as 'admin'

A Real-World Example

Again, I will use our friend the TRENDnet TV-IP110 for a real-world example.

Figure 16: Winbond 25Q32BVSIG SPI EEPROM in TRENDnet TV-IP110 IP Camera

As you can see the SPI EEPROM is soldered to the board. In order to remove it, you can use Chipquik and a soldering iron. After chip removal, I soldered wires to the pins. This is because the pins are small and close together, and the wires allowed for easier probing with the Bus Pirate’s large probe hooks.

Figure 17: TRENDnet IP Camera EEPROM Removed and Probed

The pin out for the IP camera’s SPI EEPROM is the same as that of the PVED’s SPI EEPROM, however some pin names are different.

Figure 18: Winbond W25Q32BV SPI EEPROM Pin Out From Datasheet

Luckily Flashrom supports this chip by default, and it supports the Bus Pirate as a hardware programmer. It can automatically detect the EEPROM and dump the memory contents to a file.

Figure 19: Reading EEPROM Using Flashrom

A great tool for performing automated analysis on binary blobs is binwalk.

Figure 20: Extracting Files from EEPROM Contents Using Binwalk

Running binwalk with the ‘-e’ flag causes the tool to attempt auto-extraction of known file types. The SquashFS image contained the IP camera’s filesystem while the individual compressed files contained configurations details for the camera. This is likely the default filesystem and configuration that is written to the device’s main memory when performing a factory reset. You can extract the filesystem locally using unsquashfs and dig through the files to your heart’s content.

Figure 21: Root Directory of Extracted SquashFS Image

Figure 22: Reading Configuration Files Extracted from EEPROM

In addition to the default admin/admin, another set of credentials was found: productmaker/ftvsbannedcode. A hidden account!


In this post, we explored active communication with chips in order to extract and rewrite sensitive EEPROM contents. We leveraged the multipurpose Bus Pirate to do the heavy lifting combined with software tools to achieve our specific goals. With these techniques and your own research, you should be well-armed to approach hardware security assessments with more confidence.