Introduction: Unveiling the Hidden World of I2C on Android

The I2C (Inter-Integrated Circuit) bus is a ubiquitous, low-bandwidth serial communication protocol found in nearly every modern electronic device, including Android smartphones and tablets. It’s the silent workhorse connecting critical components like sensors (accelerometers, gyroscopes, magnetometers), Power Management ICs (PMICs), camera modules, touch screen controllers, and more, directly to the System-on-Chip (SoC). For hardware reverse engineers, security researchers, and advanced Android enthusiasts, probing the I2C bus offers an unparalleled opportunity to discover undocumented hardware, identify proprietary components, and understand a device’s true capabilities.

However, accessing and analyzing I2C communications on Android isn’t always straightforward. Manufacturers often abstract these low-level interactions, making direct bus exploration challenging. This article will guide you through the process of I2C bus forensics on a rooted Android device, demonstrating how to enumerate adapters, scan for devices, and extract valuable information.

Prerequisites

• A rooted Android device.
• ADB (Android Debug Bridge) installed and configured on your host machine.
• Basic familiarity with Linux command-line tools.
• Optionally: The i2c-tools utility compiled for ARM/ARM64 and pushed to your device, or built from source on device. If not available, we’ll cover manual methods.

Understanding I2C on Linux and Android

On Linux-based systems like Android, I2C bus controllers are exposed through the kernel’s I2C subsystem. Each I2C controller (or adapter) provides access to one or more I2C buses. Devices connected to these buses are referred to as client devices. The kernel typically exposes these through:

• /sys/bus/i2c/: A sysfs interface providing details about I2C adapters and devices.
• /dev/i2c-*: Device nodes that allow userspace programs to communicate directly with I2C adapters.

The I2C protocol itself is a master-slave communication, where devices are addressed using a 7-bit (or sometimes 10-bit) address. A master (usually the SoC) initiates communication with a slave device at a specific address to read or write data to its internal registers.

Step 1: Identifying I2C Adapters

The first step is to identify the available I2C adapters on your device. You can do this by inspecting the sysfs filesystem.

adb shell
ls -l /sys/bus/i2c/devices/

You’ll typically see entries like i2c-0, i2c-1, etc., representing different I2C adapters. Alternatively, you can look for the device nodes:

adb shell
ls -l /dev/i2c*

This will list nodes like /dev/i2c-0, /dev/i2c-1, confirming their presence and permissions. Note down the adapter numbers; these are crucial for the next steps.

Step 2: Scanning the I2C Bus for Devices

Once you have identified an adapter, you can scan its bus for connected devices. The i2cdetect utility from the i2c-tools package is designed for this purpose. If you don’t have it, you might need to compile it for your device’s architecture and push it. For this example, let’s assume you’ve pushed it to /data/local/tmp/i2cdetect.

To scan an adapter (e.g., i2c-0), execute:

adb shell
/data/local/tmp/i2cdetect -y 0

The -y flag disables interactive mode. The output will be a grid showing detected I2C addresses:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

In this example, UU at address 0x68 indicates a device is present and active (usually busy, meaning a kernel driver is already controlling it). -- indicates no device responded at that address. Addresses with 0x in front are reserved for the adapter itself.

Repeat this process for all identified I2C adapters (e.g., i2cdetect -y 1, i2cdetect -y 2, etc.) to get a comprehensive map of connected devices.

Step 3: Interacting with I2C Devices: Reading Registers

Once you’ve found a device address (e.g., 0x68), you can try to read its internal registers. This is where the forensics truly begin. Many I2C devices, especially sensors, have a