Beyond Root: Custom Firmware for Embedded Mobile Chipsets

Overview: Christopher Wade, a security consultant at Pen Test Partners, explores the hardware security of embedded mobile chipsets and methods for writing custom firmware for peripheral controllers. The presentation focuses on overcoming the limitations of standard Android root access, which leaves closed-source hardware components unmodified. Wade specifically details reverse engineering the custom Samsung S3FWRN5 NFC controller present in devices like the Samsung Galaxy S6 and Galaxy Note 4.

Key Topics: - Limitations of Android root access on closed-source hardware peripherals - Samsung S3FWRN5 NFC chipset and ARM SC000 (SecurCore) architecture - Firmware update protocol reverse engineering via logcat and open-source kernel drivers - Exploiting undocumented bootloader command 6 for arbitrary memory read and firmware extraction

Technical Details: Christopher Wade explains that while gaining root access on Android devices permits kernel and OS modifications, it leaves closed-source peripheral microcontrollers unmodified. Hardware peripherals such as Broadcom Wi-Fi/Bluetooth and NFC controllers operate proprietary firmware with restricted interfaces. Standard Android NFC APIs restrict users to basic reading, mobile payments, and host card emulation (HCE), preventing security researchers from performing advanced attacks such as reader emulation against tag cryptography, arbitrary tag emulation, or passive RF sniffing as possible on Proxmark or Chameleon hardware. To overcome this, Wade targeted the custom Samsung Semiconductor S3FWRN5 NFC chip present in the Samsung Galaxy S6 and Galaxy Note 4.

The S3FWRN5 chip is built on an ARM SecurCore SC000 embedded architecture, communicating with the host application processor via I2C and GPIO lines using the standard NFC Controller Interface (NCI) protocol. Host-to-chip communication relies on group IDs, operation IDs, lengths, and payloads, including vendor group IDs. The host toggles a specific GPIO line to switch the controller from standard NCI mode into its bootloader mode for firmware updates. By monitoring Android logcat streams during legitimate updates and analyzing Samsung's open-source kernel driver, Wade reverse-engineered the proprietary bootloader protocol. Firmware frames consist of a command type (0, 1, or 2), a command byte, a two-byte payload size (capped at 256 bytes), and a parity bit. Firmware binaries comprise metadata, an RSA signature, and raw ARM Thumb code, which Wade quickly identified by searching for the Thumb bx lr mnemonic (ASCII pG / hex 0x4770).

While the open-source kernel driver documented bootloader commands for reset (0), boot info (1), update initiation (2), sector writing (4, in 4096-byte blocks), and signature verification (5), command 3 was omitted. Wade fuzz-tested bootloader commands by interpreting returned error codes (error 2 for invalid stage; error 9 for undersized payload). This revealed that command 3 accepted 512-byte sector blocks. Crucially, brute forcing exposed undocumented Command 6, which accepted two 32-bit parameters specifying an address and size. Command 6 provided an arbitrary memory read primitive, enabling extraction of RAM, memory-mapped registers, secure bootloader code, and firmware from base address 0x3000. Analysis showed the bootloader verifies the RSA signature and overwrites initial placeholder bytes (0xFFFFFFFF) with magic value 0x5AF00FA5 to mark the image valid.

Key Takeaways: Embedded chipsets within mobile phones often contain diagnostic and testing backdoors that persist in production devices. Because mobile OS isolation does not protect peripheral controller firmware interfaces, exposed bootloader commands over I2C can allow attackers with root access to read internal firmware, dump cryptographic keys, or modify hardware operation. Hardware vendors must purge manufacturing and debug commands (such as arbitrary memory dump functions) prior to commercial deployment.

(AI summary — Gemini Flash)