Google Nexus 9 Cypress SAR Firmware Injection via I2C

The Nexus 9 device contains a sensor SoC manufactured by Cypress. The sensor is managed by a driver available under drivers/input/touchscreen/cy8c_sar.c. The driver uses the sensor’s data in order to regulate the radiation level emitted by the device.

The sensor communicates with the application processor via I\(^2\)C bus #1, which also provides a firmware update interface. During the platform boot, the driver samples the SoC’s firmware’s version via chip address 0x5{c,d}, register 0x6. If it is different than the one available under /vendor/firmware/sar{0,1}.img, it initiates with a firmware flashing process (via I\(^2\)C chip address 0x6{0,1}). It seems though that the firmware is not signed by Cypress, thus anyone having access to the I\(^2\)C bus, can reflash the firmware of the SoC.

On Nexus 9 before build N4F27B, the I\(^2\)C bus could be accessed in four ways:

1. Directly by the kernel.
2. Via the /dev/i2c-N character devices. However, as per the SElinux policy in Nexus 9, these devices have the i2c_device context which can only be accessed when one is under the su domain – only available on eng/userdebug builds, i.e. not on production.
3. Via the USB fastboot interface, accessible by the fastboot oem {i2cr, i2cw, i2crNoAddr, i2cwNoAddr} commands:

   $ fastboot oem i2cr 1 0xb8 6 1
   ...
   (bootloader) ret:0
   (bootloader) > [1] = 1f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   OKAY [  0.012s]
   finished. total time: 0.013s
   

4. Via the HBOOT interface, available by UART (exposed by the headphones jack). The I\(^2\)C buses could be accessed by the i2cr, i2cw, i2crNoAddr, i2cwNoAddr commands:

hboot> i2cr 1 0xb8 6 1
ret:0
     > [1] = 1f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
     
hboot>

Vectors 3 & 4 are especially significant because theoretically they can be used by either a physical attacker (rebooting the device into fastboot) or by malicious chargers / headphones. For example, a malicious charger connected to an ADB-enabled device may reboot the device into fastboot if the user authorizes the charger. As for headphones, on builds before N4F26T they could reboot the device into HBOOT by issuing reboot oem-42 on the FIQ debugger prompt. See our blog post for more details.

Proof-of-Concept

To demonstrate the SoC can be attacked via I\(^2\)C, we modified its firmware image. Then we managed to flash the modified image via the I\(^2\)C bus by the second vector using i2ctools (i.e. the test device ran our own AOSP-compiled, non-production build). The first firmware image we flashed, available on GitHub increases the version to 0x3f:

flounder:/ # /data/local/tmp/i2cget -f -y 1 0x5c 0x6
/data/local/tmp/i2cget -f -y 1 0x5c 0x6
0x3f
flounder:/ #

The second broke the operation of the chip – from that point forward, we could not reflash the chip since it stopped responding via I\(^2\)C:

[   21.431832] CYPRESS_SAR: probe of 1-005d failed with error -1
[   61.118692] [SAR] active=80 

As for the 3rd and 4th vectors, HBOOT limits the number of command arguments to 16 which creates a technical difficulty controlling the last bytes of each firmware image line (which also contains the checksum) during the flashing process, however further research may show it can be bypassed as well.

Patch

Google patched the vulnerability on build N4F27B / bootloader 3.50.0.0143 by restricting access to the I\(^2\)C buses – removing vectors 3 and 4. The I\(^2\)C related bootloader commands are no longer available:

$ fastboot oem i2cr 1 0xb8 6 1
...
(bootloader) [ERR] Command error !!!
OKAY [  0.011s]

finished. total time: 0.012s

Please note that although Google published the advisory on the April Security Bulletin, the patch has been included only since the April 5 2017 Security Patch Level, where the April Nexus 9 image (N4F26X) has the April 1 2017 Security Patch Level, hence it does not contain the patched bootloader.