Introduction: The Hidden World of Android I2C Devices

The Inter-Integrated Circuit (I2C) bus is a cornerstone of modern embedded systems, including Android devices. It’s the silent workhorse connecting a myriad of sensors, camera modules, touch controllers, power management ICs (PMICs), and other peripherals to the main System-on-Chip (SoC). For hardware reverse engineers, security researchers, and even advanced developers, understanding and enumerating these I2C devices is paramount. While Linux-based systems like Android expose I2C adapters as /dev/i2c-* device files, merely listing these files only tells part of the story. To truly understand the connected hardware, we need to delve deeper into the kernel’s mechanisms.

The Limitations of `/dev/i2c-*`

On an Android device with root access, you might typically start your I2C exploration by listing the I2C character devices:

adb shell ls -l /dev/i2c-*
crw-rw---- 1 root i2c 89,   0 2023-10-26 10:30 /dev/i2c-0
crw-rw---- 1 root i2c 89,   1 2023-10-26 10:30 /dev/i2c-1
crw-rw---- 1 root i2c 89,   2 2023-10-26 10:30 /dev/i2c-2
# ... and so on

These files represent I2C adapters (controllers) present on the system. You can interact with these using tools like i2cdetect or custom programs to scan for devices at specific addresses. However, this approach has significant limitations:

• It doesn’t tell you *what* device is at a given address (e.g., is 0x44 a gyroscope or a temperature sensor?).
• It doesn’t reveal the driver bound to a device.
• It doesn’t provide properties or configuration details of the devices.
• It only works for *active* I2C adapters and visible devices.

For a comprehensive understanding, we need more advanced techniques that leverage the Linux kernel’s internal representation of hardware.

Method 1: Deep Dive into `sysfs` for I2C Device Discovery

The sysfs virtual filesystem provides a hierarchical view of the kernel’s device model. It’s an invaluable resource for understanding hardware without needing to compile custom kernel modules. I2C devices and adapters are extensively exposed here.

Identifying I2C Adapters and Their Properties

I2C adapters (controllers) are exposed under /sys/class/i2c-adapter/. Each subdirectory corresponds to an I2C bus:

adb shell ls -l /sys/class/i2c-adapter/
lrwxrwxrwx 1 root root 0 2023-10-26 10:30 i2c-0 -> ../../devices/platform/soc/1a000000.i2c/i2c-0
lrwxrwxrwx 1 root root 0 2023-10-26 10:30 i2c-1 -> ../../devices/platform/soc/1b000000.i2c/i2c-1
# ...

These symbolic links point to the actual device nodes in /sys/devices/, which often reveals the platform driver responsible for the adapter (e.g., a Qualcomm ‘qcom,i2c’ controller). You can also find the bus name:

adb shell cat /sys/class/i2c-adapter/i2c-0/name
i2c-qcom-geni.0

Enumerating Connected I2C Devices

The most detailed information about *registered* I2C devices is found under /sys/bus/i2c/devices/. Each subdirectory here represents an I2C device that the kernel has identified and, in many cases, bound a driver to:

adb shell ls -l /sys/bus/i2c/devices/
lrwxrwxrwx 1 root root 0 2023-10-26 10:30 0-0060 -> ../../../devices/platform/soc/1a000000.i2c/i2c-0/0-0060
lrwxrwxrwx 1 root root 0 2023-10-26 10:30 1-0020 -> ../../../devices/platform/soc/1b000000.i2c/i2c-1/1-0020
lrwxrwxrwx 1 root root 0 2023-10-26 10:30 2-0050 -> ../../../devices/platform/soc/1c000000.i2c/i2c-2/2-0050
# ...

The directory names follow the pattern N-ADDR, where N is the I2C bus number (e.g., i2c-N) and ADDR is the 7-bit I2C slave address (hexadecimal). Inside each N-ADDR directory, you’ll find crucial files:

• name: Often reveals the device’s driver name or a generic identification.
• uevent: Contains kernel uevent properties, including MODALIAS which can be useful for identifying the driver.
• driver (symlink): Points to the driver directory if a driver is bound.
• of_node (symlink): Points to the corresponding Device Tree node if the device was defined in the DT.

For example, to identify a device:

adb shell cat /sys/bus/i2c/devices/2-0050/name
sensor_hub_ic

This immediately tells us that the device at address 0x50 on I2C bus 2 is identified as a