I2C is a synchronous serial communication interface. It is primarily used for short-distance intra-board communication.

It
was developed by Philips Semiconductor(now NXP Semiconductors). It provides a half-duplex communication mode (i.e.,
sender and receiver can transmit/receive the data one at a time, not simultaneously). It has a master-slave architecture
that supports multiple masters and multiple slaves. It is a 2-wire serial interface.

It consists of two bidirectional open-collector(i.e., the device can pull the respective lines low but cannot drive it high.
Hence, this avoids any contention between the devices when one is trying to drive the line high, and the other is trying to
pull it low.), lines pulled up with resistors (it keeps the line high when the line is not pulled low by any device) :

 Serial Clock (SCL)

 Serial Data (SDA)

It supports different bidirectional speed modes 100 kbit/s standard mode, 400 kbit/s fast mode, 1 Mbit/s fast mode plus,
3.4 Mbit/s high-speed mode, and unidirectional 5 Mbit/s ultra fast-mode (these bit rates are without any clock stretching or
any other overhead). Multiple masters can exist simultaneously on the same bus. The I2C bus has two nodes :

 Master node – This node generates the clock and starts the communication with slaves.
 Slave node – It receives the clock and communicates with the master if addressed by it.

Each device connected to the I2C bus has a unique address. The number of nodes on the bus is determined by the
address space and the total capacitance of the bus, i.e., 400 pF (Source – wikipedia). It has a 7-bit or 10-bit address
space. Further on, we will be discussing w.r.t 7-bit address space. In 7-bit, the maximum number of devices that can be
connected over I2C bus is 128. Apart from data bits, I2C has START and STOP bits that indicate the beginning and end
of the communication between the master and the slave.

The image below shows the general connection diagram in I2C (Source – here).

1. Master initiates the communication by sending the START bit (SDA line is pulled low when SCL is high, then the
SCL is pulled low) followed by the 7-bit/10-bit address of the slave it wants to communicate with, it is followed by
1-bit indicating if it wants to write to (0) or read from (1) the slave.
2. If the slave exists, it responds to the master with an acknowledgment bit ACK.
3. Then, depending on the read or write operation, the master continues to either transmit or receive, and the slave
operates in the complementary way, i.e. receive or the transmit, respectively. The size of the data frame that is
transmitted is 8-bit. The most significant bit (MSB) of the data byte is transferred first. While transferring, the data
 is put on the SDA line after SCL is pulled low. During the high period of SCLK, data on the SDA line should be
stable. The HIGH or LOW state the SDA line changes only when the SCL line is LOW.
o In case of the write operation, the master repeatedly transmits the data, and the slave sends the ACK bit
after every received data byte.
o In case of the read operation, the master repeatedly receives the slave’s data and sends the ACK bit
after each received byte except the last one.
o This transaction can have multiple messages. In the case of the combined format of I2C protocol where
the master has to perform multiple reads or write to one or more slaves, instead of sending a STOP bit,
the master sends another START bit to retain the bus’s control for another message. It is called repeated
START bits.
4. If the transaction has to be ended, the master terminates it by sending a STOP bit (SDA line is set high after the
SCL is set high).

The image below shows bit transfer on the I2C bus (Source – Standard Doc).

The below image shows the START and STOP conditions on the I2C bus (Source – Standard Doc).

The below image shows the data transfer on the I2C bus (Source – Standard Doc).

If the slave cannot transmit or receive another data byte due to the slave being involved in some other process like
servicing some internal interrupt, it can hold the SCL line low to keep the master in a wait state. Data transfer is continued
when the slave is ready to receive/transmit another byte, and it releases the SCL line.
The receiver sends the acknowledgment bit on every received byte. ACK bit (i.e., receiver pulls the SDA line low in the
9th clock cycle after the transfer of 8-bit data) acknowledges the transmitter that the data has been successfully received
and the following data can be transferred. In the given five conditions when:

1. there is no receiver present on the bus with the transmitted address

2. receiver is busy performing some real-time functions
3. receiver receives such data or commands that it does not understand
4. receiver cannot receive any more data bytes
5. the master-receiver has to send the end of the transfer signal to the receiver

In these cases, the transmitter receives no acknowledgment signal NACK (i.e., the SDA line remains high during the 9th
clock pulse). The master can then either send the STOP signal to end the transfer or send a repeated START signal to
start a new transfer.

I2C protocol includes collision detection and arbitration to prevent data corruption in the case; multiple masters
simultaneously start the data transfer. Clock synchronization and arbitration are used to decide which master will take
control of the bus and complete the transmission when multiple masters begin transmitting on the same bus
simultaneously. In the case of a single master system, it’s not required. The detail working about the Clock
synchronization and arbitration can be read from the standard document.

Another essential feature of the I2C protocol is Clock stretching. There are cases when a slave device to which the
master is communicating is not ready to perform the next transaction with the master. This can be when the previous
operation on the slave side has not been completed yet. In this case, the slave device can perform clock stretching, i.e.,
the slave can hold the SCL line low after reception and acknowledgment of byte that makes the master wait until the slave
releases the SCL line to high. I2C protocol has many applications. They are used to communicate controllers with
sensors, actuators, memory chips, displays, real-time clocks, digital tuning, signal processing circuits, etc. If an adversary
gets access to the device’s hardware part, there are several ways in which the I2C bus can be exploited if not
implemented properly. In further sections in this blog, we will discuss the attacking cases and methods. The attacking
methods would be very similar to what we discussed in the previous part of this blog series.

Possible Attack Scenarios

 Sniffing the communication between an I2C device like sensors, controlling device, memory chip, ADC, DAC, etc.
and the controller/processor. It may lead to the stealing/leak of sensitive information by the attacker. As also
discussed in the previous blog, for example, in some of the embedded devices, an I2C EEPROM is used to store
some sensitive information, keys, logs, etc. This sensitive info can be leaked if an attacker sniffs the
communication between the EEPROM and the controller/processor. After getting this sensitive info, an attacker
can damage many ways and may be on a large scale if the vendor of the hardware has used the same sensitive
info like the same keys in all the hardware in the production.
  Patching the data in the I2C based memory chips, sensors, or any controlled device. In this case, if the data is not
securely managed on the device, an attacker can manipulate it. It may result in a malfunction of the device.
Depending on the application, manipulation of sensor data can cause significant damage to the system.
 There are also clock glitching related attacks like modifying the frequency of the I2C clock signal. Refer to this
research paper to get a more in-depth insight into the attacks related to I2C.

Attacking hardware via I2C

There are various ways in which the attacker can attack the hardware via I2C. Few methods to perform the attacks are
explained in the below section. It is similar to that explained in the previous replacement of the blog series.

Recon

Case 1: You do not have the actual hardware, but you know the FCCID number of the device. Go to the FCCID website,
search for the FCCID number of the device. If correct, you will find all the internal images and detailed internal, external
information about the device. Seeing the internal image, you may get the hint for the presence of an I2C chip or any I2C
based device on the hardware. Yayy!! Once you know that you have the attack surface, you can get/purchase that device
and perform further required steps to attack the device.

Case 2: You got access to the hardware. Once the device’s hardware is found, the first step should be to tear down the
device and perform reconnaissance. Inspect each chip, test points present on the printed circuit board (PCB) to look if
you can get the access to the i2c bus. You can read more about hardware recon here.

 If successful in identifying the I2C chip used on the device, search for its datasheet on the Internet, identify the
pin diagrams given, and trace those pins on the PCB. Check the continuity between the I2C pins of the controller
and the test points present on the PCB using Multimeter. For example, We are showing below the image
of EXPLIoT DIVA board that we had also used in our previous blogs.
It contains some chips on the PCB. We googled the datasheet for each chip and found that one of its chips denoted as
U1 is an I2C EEPROM 24LC256 After finding the chip, the next task is to identify if the I2C pins (SDA, SCL) of the chip is
connected to some points on the PCB or not. Fetching the datasheet of 24LC256, we identified the respective pins of the
chip as shown in the image below (Source – 25LC256 datasheet)

Using the multimeter, we checked the connectivity of these I2C pins with other pins on the PCB. We found that pins on
the J5 header, as in the image below, were connected to these I2C pins.