I²C (Inter-Integrated Circuit)

Let’s start with a bit of background history on why I²C was created and how it evolved. I²C was developed in 1982, by Philips, to enable their chips to communicate and exchange data with other components. In the first version of I²C, the highest data transmission speed was 100 kbps with a 7-bit address, which then later improved to 400 kbps with a 10-bit address. At present, components using I²C can communicate with each other with a speed of up to 3.4 Mbps.

Looking at the technical aspects of I²C, it’s a multimaster protocol with only two wires required to enable data exchange—serial data (SDA) and serial clock (SCL). However, I²C is only half-duplex, which means it can only send or receive data at a given point of time.

Why Not SPI or UART

It might appear confusing at first: Why would someone use I2C instead of UART or SPI? Well, there are a couple of reasons.

The challenge with UART is the limitation of facilitating communication between only two devices at a given time. Additionally, as we have seen in the previous chapter, a UART packet structure includes a start and stop bit, which adds to the overall size of the data packet that is transferred, also affecting the speed of the entire process. Additionally, UART was originally intended to provide communication over large distances, interacting with external devices via cables. In contrast, I²C and SPI are meant for communicating with other peripherals located on the same circuit board.

SPI is another extremely popular protocol for data transfer between components. SPI has faster data transmission rates compared to I²C, but the only major downside that SPI has is the requirement of three pins for data transfer and one pin for Chip/Slave select, which increases the overall requirement of space while implementing the SPI protocol for data communication compared to I²C.

Serial Peripheral Interface

SPI is one of the other most popular communication protocols used in embedded devices. SPI is full-duplex (unlike I²C, which is half-duplex) and consists of three wires—SCK, MOSI, and MISO—and an additional chip select/slave select. In cases when there is no data to read, though, when there is a write happening, the slave should send dummy data to make the connection happen.

SPI was originally developed by Motorola to provide full-duplex synchronous serial communication between the master and slave devices. Unlike I²C, in SPI only one single master is controlling all the slaves and the master controls the clock for all the slaves. The overall implementation and standardization of SPI is pretty loosely defined and different manufacturers can modify the implementation in their own way, due to the lack of a strict standard. To understand the SPI communication for any given chip on the target device, the best way is to look up the data sheet and analyze how our target has implemented the SPI protocol for communication.

Understanding EEPROM

Both SPI and I²C are common protocols when it comes to talking about data storage via Electrically Erasable Programmable Read Only Memory (EEPROM). In this section, we look into EEPROM and understand the various pins in it, which will be useful while working with I²C and SPI.

Also, as we have discussed, I²C works on two lines, namely SDA and SCL. The SDA line is for the data exchange, whereas the clock line, SCL, is controlled by the master and determines the speed at which the data exchange takes place. The master also holds the address and memory location of all the various slave devices that are used during any communication.

In I²C, unlike SPI, there can be multiple masters interacting with various slaves. That configuration is called a multimaster mode. You might wonder what would happen if two masters wanted to take control over an I²C bus at the same time. The answer is that whichever master pulls the SDA to LOW (0) will gain control of the bus; that is, zero rushes to win.

Exploiting I²C Security

Now that we have a good understanding of the foundational concepts of I²C and how the data transfer happens, let’s jump into how we can exploit the devices using the I²C protocol. By exploiting I²C here, I mean reading or writing data of the device using an I²C EEPROM in a real-world device.

For this section, you can choose any device that has a flash chip working on the I²C communication protocol. For the purposes of demonstration, I’ll be taking an example of an unnamed smart glucometer, which has a feature of saving health records of the user offline on the device. For the purpose of hands-on lab exercises, you can get any device with EEPROM working on I²C communication protocol such a as GY-521 breakout board or even any I²C chips from https://www.digikey.in/en/ptm/m/microchip-technology/ic-serial-eeprom and use an EEPROM adapter to connect to it. The connections would remain the same as mentioned in the upcoming sections, no matter which I²C EEPROM device you choose to go with.

In case of the smart glucometer that we have, it uses a MicroChip 24LC256 EEPROM chip, which works over the I²C communication protocol. Figure 5-1 shows an online data sheet for the specific I²C model.

The first step for any analysis is finding the component name on the data sheet and looking it up online. Based on the data sheet of the I²C found on this device, which is a Microchip 256K I²C EEPROM arranged as 32K × 8 serial memory, we find out the pinouts of the EEPROM, as shown in Figure 5-2.

Making Connections for I²C Exploitation with the Attify Badge

Once we have the previously mentioned information from the data sheet, we can now connect the EEPROM to our Attify Badge. You can either directly connect it to the Attify Badge by holding the EEPROM using a SOIC clip, or by removing the EEPROM from the device and soldering it on an EEPROM adapter corresponding to the packaging of EEPROM. Figure 5-3 displays how the connection will look between the EEPROM and the Attify Badge, with the Attify Badge plugged into our system.

Once we have made all the connections, let’s look at the script that we are going to use to read and write data from I²C EEPROM.

Understanding the Code

To work with I²C, we will use the script i2ceeprom.py by Craig Heffner located at https://github.com/devttys0/libmpsse/blob/master/src/examples/i2ceeprom.py .

Before actually running the script, let’s try to understand how the script works. This will also be useful if you want to modify the script for your own requirements. You’ll also need to modify the script a bit while working with different I²C EEPROMs with different configurations and speeds.

The script starts by mentioning the size of the EEPROM chip, which in this case is 32 KB followed by specifying the Read and Write commands. It also later specifies the speed to be 400 KHz as shown in our data sheet. Note that different I²C EEPROMs might have different speeds and you’ll need to modify this value to suit your target.

from mpsse import *

SIZE = 0x8000            # Size of EEPROM chip (32 KB)

WCMD = "xA0x00x00"    # Write start address command

RCMD = "xA1"            # Read command

FOUT = "eeprom.bin"      # Output file

      try:

      eeprom = MPSSE(I2C, FOUR_HUNDRED_KHZ)

print "%s initialized at %dHz (I2C)" % (eeprom.GetDescription(), eeprom.GetClock())

Next, we try to start the I²C clock by using eeprom.Start() and sending the Start command to initialize the EEPROM at the speed of 400 KHz.

eeprom = MPSSE(I2C, FOUR_HUNDRED_KHZ)

print "%s initialized at %dHz (I2C)" % (eeprom.GetDescription(), eeprom.GetClock())

       eeprom.Start()

       eeprom.Write(WCMD)

Now if we want to read data from the EEPROM, the script first checks if the EEPROM is available by checking for an ACK of start(). It then sends the Read command using eeprom.Write(RCMD) and sets the EEPROM to read mode. Once everything is set, it simply starts reading content from the EEPROM and saving it in data().

if eeprom.GetAck() == ACK:

            eeprom.Start()

            eeprom.Write(RCMD)

      if eeprom.GetAck() == ACK:

            data = eeprom.Read(SIZE)

            eeprom.SendNacks()

            eeprom.Read(1)

      else:

            raise Exception("Received read command NACK!")

else:

      raise Exception("Received write command NACK!")

eeprom.Stop()

Once the read operation is complete, we close the I²C connection and write the content to a file named EEPROM.bin.

open(FOUT, "wb").write(data)

print "Dumped %d bytes to %s" % (len(data), FOUT)

      eeprom.Close()

except Exception, e:

print "MPSSE failure:", e

Once we run the script after making the appropriate connections, we will see that the content from the EEPROM has been dumped to the file (see Figure 5-4).

Similarly, we can also write data to the I²C chip.

This is how we perform I²C analysis on any given device. To summarize, these are the steps involved in the process:

• Open the device.

• Identify the I²C chip on the PCB.

• Note the component number printed on the I²C chip.

• Look online for the data sheet to determine the pinouts.

• Make the required connections.

• Use the i2ceeprom.py script to read or write data to the I²C EEPROM.

Digging Deep into SPI

Now that we understand I²C and EEPROM, let’s dig deeper into how SPI works and how to interact with target devices using the SPI communication protocol.

Out of these lines, the SCK, MISO, and MOSI pins are shared by slaves, whereas each SPI slave will have its own unique SS line. In SPI (unlike I²C) there can be only one master and multiple slaves. The master in SPI is the one in charge of the clock.

To give you a better perspective of what an SPI connection looks like, Figure 5-4 provides a diagram of SPI communication with a single master and multiple slaves. We discuss the individual pins later as explore SPI further.

The speed of SPI is not limited and that is why SPIs are typically faster than other protocols. Also, the fact that it is full-duplex makes it a better choice for device developers who want to utilize the speed.

Reading and Writing from SPI EEPROM

To read and write data from or to an SPI EEPROM, we use a utility called spiflash.py available to download from https://github.com/devttys0/libmpsse/ .

As you can see, we can set values such as specifying whether to read, write, or erase, as well as provide size to read and write, starting address to perform the operation, and custom clock frequency instead of the default 15 MHz. We also have an option of -v, which will verify if the data that has been written or read from the chip is the same as the original one.

Now that we are familiar with the script, we are ready to go ahead and try it on a target device. In my case, I have a Winbond SPI flash that I have removed from the PCB via desoldering. Once it is desoldered, we can then solder it to an EEPROM adapter (or reader). You could also directly read it while the chip is on the device by hooking miniprobes to the EEPROM or using a SOIC clip of a real-world IoT device without removing the chip from the device.

Figure 5-6 shows what our SPI flash looks like when soldered to the EEPROM adapter.

Let’s go ahead and get started with making all the necessary connections for SPI. To do this, we need to first understand the pinouts of our target SPI flash chip, which in our case is W25Q80DVSNIG.

If we look online for data sheets for this flash chip, we find the pinout mentioned in the data sheet, as shown in Figure 5-7.

One of the things that we need to note here is that the connections of MOSI and MISO will reverse if you are using another tool instead of Attify Badge (e.g., the Bus Pirate). This is because of the naming conventions of Attify Badge.

As we can see in Figure 5-8, we have been able to successfully read the contents from the SPI flash EEPROM chip and store it on our local system.

This means that now given any device, you will be able to dump the content that the device has been storing in its EEPROM chip. Additionally, we can also write data to the chip as shown in Figure 5-9.

This is extremely useful, as we can write a modified version of a device’s firmware if we are able to interact with the EEPROM flash chip over SPI.

Dumping Firmware Using SPI and Attify Badge

Let’s try it out on another device that has a complete firmware (in this case OpenWRT) and dump the firmware using the spiflash.py script and Attify Badge. The device that we are going to use in this case is a WRTNode shown in Figure 5-10. For the purpose of performing a hands-on exercise, you can either use the same device (WRTNode) or any other development board that has an SPI interface.

We can see that WRTNode has several pins and pads allowing us to connect and interact with it. We can look online for the data sheet of WRTNode because it is a popular development board (Figure 5-11).

Now because we are already familiar with the SPI communication protocol and how to interact with devices using this protocol with Attify Badge, we can interact with WRTNode. In this case, if we read data from the flash chip, it will be the entire firmware, which we can then extract the file system from. Even though we cover firmware analysis and file system extraction in Chapter 7, I’ll show you briefly here the process of dumping firmware from a device using SPI.

Figure 5-12 shows a tabular view of the connections in case of WRTNode, which is the same as what we saw earlier.

Once you have made the connections, Figure 5-13 shows the final connection diagram for clarity.

After the connection, the next step would be the same as earlier, which is running spiflash.py and then specifying a large enough size so that the entire flash chip content gets dumped. Figure 5-14 shows the firmware dumping process.

Finally, once we have the wrtnode-dump.bin we can run firmware analysis tools (which we cover later) such as Binwalk and get the entire original file system (Figure 5-15).

This is how we apply the SPI exploitation skill sets on real-world devices to dump the entire firmware from the device.

Conclusion

In this chapter, we covered several topics including EEPROM, I²C, and SPI. We also had a look at how we can read and write data from the EEPROM using both I²C and SPI communication protocols. This knowledge would be extremely useful for you when you are pentesting a real-world device and want to look at the firmware, which would be stored in the EEPROM, or any sensitive information.

You can also modify a firmware image dumped from the EEPROM chip and write it back and analyze the device’s behavior.

In the next chapter, we start looking at one of the other most popular concepts in embedded device hacking, JTAG.

Often, you’ll find real-world commercial devices storing content such as secret keys, firmware, binaries, and interesting data pieces in its EEPROM flash, which with the knowledge gained from this chapter, can be exploited.