Demystifying Hardware Security –

Part III

Demystifying Hardware Security – Part III

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

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.


Demystifying Hardware Security III 2

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.


Demystifying Hardware Security III 3

Figure 3: Jumpers Attached for Bus Pirate Self-Test


Demystifying Hardware Security III 4

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.


Demystifying Hardware Security III 5

Figure 5: Bus Pirate Supported Modes


Demystifying Hardware Security III 6

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.


Demystifying Hardware Security III 7

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.


Demystifying Hardware Security III 8

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.


Demystifying Hardware Security III 9

Figure 9: Bus Pirate Pins and Pin States


Demystifying Hardware Security III 10

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.


Demystifying Hardware Security III 11

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).


Demystifying Hardware Security III 12

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.


Demystifying Hardware Security III 13

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.


Demystifying Hardware Security III 14

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.


Demystifying Hardware Security III 15

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.


Demystifying Hardware Security III 16

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.


Demystifying Hardware Security III 18

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.


Demystifying Hardware Security III 19

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.


Demystifying Hardware Security III 20

Figure 19: Reading EEPROM Using Flashrom


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


Demystifying Hardware Security III 21

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.


Demystifying Hardware Security III 22

Figure 21: Root Directory of Extracted SquashFS Image


Demystifying Hardware Security III 23

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.