Google Reimagined a Phone. It was Our Job to Red Team and Secure it.

Overview: Members of Google's Android Red Team—Farzan Karimi, Xuan Chen, and Eugene Rodionov—detail their internal offensive security assessment of the Google Pixel 6. The device represented a major architectural redesign, introducing Google's custom Tensor System-on-Chip (SoC) and the proprietary Titan M2 discrete security chip. The speakers discuss their red team methodology, the broader migration of mobile attack surfaces into low-level firmware, and demonstrate impactful proof-of-concept exploits achieving code execution on both the Android Bootloader (ABL) and the Titan M2 secure element.

Key Topics: - Pre-launch offensive security evaluation of custom smartphone silicon (Tensor SoC) - Evolving mobile threat landscape moving down the stack to firmware, bootloaders, and ROM - Integrating red teaming with continuous automated fuzzing pipelines and exploit modeling - Hardware and firmware architecture of the Titan M2 security chip (custom RISC-V implementation) - Vulnerability discovery and proof-of-concept code execution on the Android Bootloader and Titan M2

Technical Details: The Pixel 6 marked Google's transition to proprietary hardware components, featuring the Tensor SoC (encompassing the TrustZone TEE, EL3 Secure Monitor, Tensor Security Core, and Private Compute Core) alongside the Titan M2 discrete secure element. The red team emphasized that mobile exploitation trends have shifted downward through the software stack into bootloaders, firmware, and ROM code as operating system sandboxes have matured. This shift is mirrored by exploit broker valuations, such as Zerodium offering .5 million for zero-click, persistent Android exploit chains.

The Titan M2 serves as the device's highest-security root of trust, handling Android Verified Boot (AVB), hardware-backed StrongBox key storage, and cryptographic attestation (carrying a million bounty in Google's Vulnerability Rewards Program). While the preceding Titan M utilized an ARM architecture, Titan M2 is engineered on a custom RISC-V architecture compiled with a non-standard toolchain, executing a completely rewritten firmware and OS stack in machine and user modes. Titan M2 interfaces with the Tensor SoC over a dedicated SPI bus; importantly, the application processor cannot communicate directly with Titan M2, requiring all communications to mediate through the Tensor Security Core.

The boot hierarchy begins in hardware mask ROM enforcing cryptographic secure boot, handing execution to the Titan M2 bootloader, which provides recovery functions and validates the main firmware image comprising the kernel and security applets. To identify flaws across this complex ecosystem within a one-year pre-launch window, the red team engineered specialized static analysis tooling and fuzzing harnesses. These fuzzers were integrated into Google's continuous 24/7 fuzzing infrastructure. Through this methodology, the team uncovered critical vulnerabilities and achieved proof-of-concept code execution within both the Android Bootloader (ABL) and the custom RISC-V Titan M2 firmware, enabling engineering teams to harden defenses prior to mass production.

Key Takeaways: Transitioning to custom silicon architectures and non-standard ISA implementations requires comprehensive offensive security validation spanning hardware, firmware, and low-level system software. Developing full proof-of-concept exploits is vital for demonstrating tangible business impact and justifying critical architectural security mitigations before device rollout. Establishing automated continuous fuzzing pipelines that operate continuously allows internal security teams to scale vulnerability discovery across rapid development cycles.

(AI summary — Gemini Flash)