Reverse engineering the Pixel TitanM2 firmware

Reverse engineering the Pixel TitanM2 firmware

Speakers: willem, Independent Researcher

Conference: 39C3

YouTube: https://www.youtube.com/watch?v=sWEKObMbe80

Overview

In this insightful talk at 39C3, independent researcher willem delved into the intricacies of Google's Titan M2 security chip, a critical component embedded within modern Pixel phones. The Titan M2 is responsible for managing the most sensitive security functions of the device, including PIN entry validation and the secure storage and management of cryptographic keys. Given its pivotal role in device security, understanding its internal workings, particularly its firmware, is paramount for security researchers, even though it operates as a proprietary "black box."

willem, a self-proclaimed lifelong reverse engineer, shared his methodical journey of dissecting the Titan M2 firmware. His motivation stems from a deep-seated curiosity to comprehend the internal mechanisms of complex systems, a trait he humorously attributes to dismantling his mother's sewing machine at the age of three. The talk meticulously details the challenges encountered during the reverse engineering process, from acquiring and unpacking firmware images to overcoming limitations in commercial disassemblers and ultimately identifying and understanding Google's custom hardware instructions.

The significance of this research lies in its contribution to independent security verification. By shedding light on the Titan M2's architecture and firmware, willem provides a foundation for other researchers to scrutinize a critical piece of hardware that underpins the security assurances of millions of Pixel devices. His findings reveal not only the technical ingenuity behind such secure elements but also raise important questions about transparency and the silent evolution of security features, particularly concerning the unannounced disabling of a hardware cryptographic accelerator.

Background

▶ Watch: Introduction to Pixel Titan M2 security chip (0:30)

The concept of a dedicated security chip, often referred to as a secure element, has been a cornerstone of Google's security strategy, evolving across various product lines. Initially, the "Titan" moniker was associated with chips developed for Google Cloud data centers. For Pixel phones, the journey began with an NXP security chip in older models. With the Pixel 3, Google introduced its own Titan M chip, which was based on an ARM processor. This first iteration of the Titan M, used from Pixel 3 to Pixel 5 (introduced in 2018), ran a proprietary operating system called Nugget OS. Firmware for this chip could be found as an EC.bin file within the vendor image of Pixel firmware packages. Early research on the Titan M was notably conducted by Quarkslab.

The focus of this talk, the Titan M2, represents a significant architectural shift. Introduced with the Pixel 6 in 2021 and codenamed Dauntless, the Titan M2 transitions to a RISC-V IP core, sourced from a company named Soteria. Despite the change in CPU architecture, it continues to run the Nugget OS. Like its predecessor, its firmware is found as EC.bin files (though often multiple instances) within the vendor image after unpacking the main Pixel firmware zip. Physically, both Titan M and M2 are tiny chips, contributing substantial security value without requiring significant physical space on the phone's mainboard.

The Titan M2's hardware capabilities are tailored for cryptographic operations. It features a big number accelerator optimized for elliptic curve (ECC) and RSA calculations, dedicated AES crypto hardware, a random number generator (RNG), and other standard microcontroller components. While not physically inspected, anti-tampering hardware is assumed to be present given the chip's security function.

Google's transparency regarding security vulnerabilities in these chips has varied. The speaker observed that while Google published numerous CVEs mentioning "Titan M" or "GSC" (Google Security Chip) between 2019 and 2022, there was a noticeable drop in published CVEs in 2023 and 2024, despite continuous code changes in the firmware. This raises questions about whether bugs are genuinely decreasing or if reporting practices have changed, potentially reducing public visibility into ongoing security issues.

Acquiring the firmware for analysis presented its own set of challenges. Official Google sources provide the latest images, but for historical versions, willem developed a scraper tool to retrieve older firmware links from archive.org. This allowed him to amass a comprehensive collection of about 3,000 different firmware files, ultimately yielding around 40 distinct versions of the Titan M firmware. The extraction process involved dealing with various Android file systems (sparse images, X4, tar files) nested within the main zip archive. A crucial tool for this multi-layered unpacking was 7-Zip, which proved effective in handling most of these formats without requiring complex mounting procedures.

From the Android operating system's perspective, the Titan M2 firmware is loaded by a process called Citadel updater during phone boot. Communication with the chip occurs over an SPI channel, facilitated by android.hardware libraries that expose a JNI interface to Android's Java codebase. This layered interaction highlights the chip's integration into the broader Android security architecture, serving as a hardware root of trust.

Key Findings

▶ Watch: Unique hardware features of the Titan M2 chip (6:00)

The reverse engineering effort into the Titan M2 firmware yielded several significant discoveries, shedding light on its internal architecture, the challenges of analyzing proprietary RISC-V implementations, and the evolution of its cryptographic capabilities.

Firstly, the firmware binary itself exhibits a distinct structure. It is typically divided into two main parts, designated as "upper" and "lower," facilitating A/B updates where one partition can be updated while the other remains active, allowing for rollback in case of issues. The firmware also contains a small loader responsible for initial boot, the main operational code, and a signature. While the signature appears to be based on an RSA modulus, willem was unable to fully validate its mechanism or factor the large number, indicating Google's robust cryptographic protection over firmware integrity.

A major hurdle in the analysis was the incompatibility of standard reverse engineering tools. Initial attempts with IDA Pro 8 (and later IDA 9 with its RISC-V decompiler) encountered difficulties, presenting numerous "undefined bytes" that prevented proper disassembly and decompilation. This indicated that the Titan M2's RISC-V implementation was not standard. The breakthrough came with Ghidra, which, despite initially facing similar disassembly issues, offered a crucial advantage: the ability to define custom processors and extend its instruction set.

Leveraging Ghidra's extensibility, willem meticulously analyzed the bit patterns of these unknown instructions. By comparing them against the official RISC-V instruction set specification (found on GitHub) and observing their operational context (e.g., preceding CSR read functions, processing results), he successfully deduced the functionality of several custom instructions. These were initially dubbed "Google zero," "Google one," "Google two," and "Google three." Further analysis revealed they performed "mundane" but essential operations like batch byte swap and R bit scan (similar to a count leading zero instruction). The speaker hypothesized that these custom instructions likely arose because the chip's design predated the finalization of certain standard RISC-V extensions (e.g., the count leading zero instruction was finalized in November 2020, while the Pixel 6 launched in mid-2021).

The internal architecture of the Nugget OS was also elucidated. It functions as a real-time operating system with five primary "apps": AVB (Android Verified Boot), GFA (Face Authentication), Identity (likely for key storage), Keymaster (for managing cryptographic keys), and Weaver (for PIN code management, including retry limits and timeouts). These apps communicate internally via a Cisco-like interface for calling crypto functions and externally with the Android OS using protobuf packets, whose definitions were found to match publicly available Google source code.

Perhaps one of the most intriguing findings concerned the elliptic curve accelerator. By examining hex dumps, willem identified code sections that did not resemble typical cryptographic keys or prime numbers but instead contained specific generator points and prime numbers associated with ECC. A striking observation was a sudden, significant drop in the code size of this coprocessor driver in later firmware versions. This, coupled with the absence of a corresponding public CVE, strongly suggests that Google silently decided to stop using this hardware coprocessor entirely, likely due to an undisclosed security flaw. This highlights a potential area of concern regarding transparency in hardware security module vulnerabilities.

Technical Deep Dive

▶ Watch: Analysis of Titan M CVE trends and code changes (6:30)

The technical journey into the Titan M2 firmware began with the challenging task of acquiring and preparing the binaries. Pixel firmware packages are distributed as large zip files. Within these, a vendor image must be extracted, which itself contains further compressed or structured data. Ultimately, the Titan M2 firmware resides in one or more EC.bin files. To manage the diversity of Android's file system formats (sparse images, X4, tar files) encountered during extraction, willem found 7-Zip to be an indispensable tool, capable of recursively unpacking these formats without manual mounting or specialized scripts. This streamlined the process of collecting and preparing approximately 40 distinct versions of the firmware for analysis.

Once extracted, the firmware's internal structure was analyzed. It's organized to support secure updates, typically featuring an "upper" and "lower" region, allowing for A/B firmware updates and rollback capabilities. A small loader segment initializes the chip, followed by the main operational code. A critical component is the signature, which ensures firmware integrity and authenticity. While the signature's presence was confirmed, identifying it as an RSA modulus, its full validation mechanism remained elusive, indicating a strong cryptographic barrier protecting the firmware from unauthorized modification.

The core of the reverse engineering effort involved tackling the custom RISC-V instructions. Initial attempts with IDA Pro 8 (and its successor IDA 9 with RISC-V support) proved frustrating due to the presence of unrecognized instructions, leading to large blocks of "undefined bytes." This rendered static analysis largely ineffective. The pivot to Ghidra was crucial, primarily because of its extensible processor definition language. Ghidra allows users to define custom instruction sets, an essential feature for proprietary hardware.

willem's methodology for understanding these custom instructions was systematic:

1. Identify Unknowns: Pinpoint the specific bit patterns that Ghidra failed to disassemble.
2. Analyze Bit Patterns: Examine the raw binary representation of these unknown opcodes.
3. Consult RISC-V Specification: Refer to the official RISC-V instruction set architecture (ISA) documentation and opcode repositories (e.g., on GitHub) to understand standard encoding schemes (e.g., ranges for immediate values, registers, function codes).
4. Hypothesize Instruction Types: Based on bit patterns and surrounding code, deduce potential instruction components (e.g., immediate values, register operands).
5. Define Dummy Instructions in Ghidra: Using Ghidra's Processor Specification Language (Sleigh), create placeholder instructions (e.g., "Google zero," "Google one") with the observed bit patterns. This allowed Ghidra to successfully disassemble the entire code, making it readable.
6. Contextual Analysis: With the code now disassembled, observe how these "Google" instructions were used in the surrounding code. For instance, an instruction used after a CSR (Control and Status Register) read and before a result operation could imply a specific data manipulation. Through this iterative process, willem identified functions like batch byte swap and an R bit scan (which finds the position of the least significant bit). This bit scan instruction, while common, had a non-standard encoding in the Titan M2, likely due to the chip's development cycle overlapping with the finalization of the standard count leading zero RISC-V extension in November 2020. This detailed analysis transformed opaque binary blobs into understandable, albeit proprietary, operations.

The Nugget OS running on the Titan M2 operates as a real-time embedded system. It hosts five distinct security-critical applications:

• AVB (Android Verified Boot): Ensures the integrity of the Android boot chain.
• GFA (Google Face Authentication): Manages biometric face unlock data.
• Identity: Likely handles secure storage and management of user identities or sensitive credentials.
• Keymaster: A fundamental Android security service responsible for cryptographic key generation, storage, and usage.
• Weaver: Manages PIN code verification, including anti-bruteforce mechanisms like retry limits and timeouts.

These applications interact with each other and with the underlying hardware via a Cisco-like interface for secure function calls. Communication with the main Android OS is handled through protobuf packets exchanged over an SPI channel. willem confirmed that the compiled protobuf encoding within the firmware matched publicly available Google source code, aiding in understanding the communication protocols.

A particularly detailed aspect of the deep dive was the investigation into the elliptic curve accelerator. Initially, willem identified unusual data patterns in hex dumps that did not resemble typical keys or prime numbers. Upon closer inspection, these patterns corresponded to known generator points and prime numbers used in specific elliptic curves for ECC signatures. This led to the conclusion that these sections represented the microcode for a dedicated hardware coprocessor. The analysis of the C code that invoked this coprocessor revealed a specific pattern:

1. Coordinates are copied to designated memory locations.
2. A "magic number" (e.g., 0x2cc) is used as an address to jump into the coprocessor's microcode.
3. The main RISC-V core interacts with the coprocessor via an IO space, checking status bits and writing function names.
4. It then waits for status bits to change, indicating completion.
5. Finally, results are copied back from the coprocessor's memory.

By correlating these C-level calls with the coprocessor's hex dump, willem began to deduce the meaning of its low-level instructions, identifying patterns for immediate loads, call instructions (e.g., 08 followed by an address), and return instructions, based on the known order of ECC coordinates and constants. The observation that this coprocessor was silently disabled in later firmware versions, marked by a significant reduction in its driver code size, strongly hints at an undisclosed security vulnerability that led Google to abandon its use.

Demo / Proof of Concept

▶ Watch: Using 7-Zip for efficient firmware extraction (9:30)

While the talk did not feature a live exploit demonstration, willem presented a significant proof of concept: a functional RISC-V simulator for the Titan M2 firmware. This simulator, initially developed in Python, comprises only a few hundred lines of code, demonstrating the relative simplicity of the RISC-V instruction set. The simulator includes logic to emulate the Titan M2's various IO ports, ensuring that the firmware code takes the most logical execution paths, even for hardware components whose exact behavior is unknown.

The success of the simulator was validated by comparing its output with the debug output obtained from a physical Pixel phone. willem proudly stated that his simulator accurately mirrored the debugger's output, successfully booting the entire Titan M2 chip, initializing its emulated IO, and ultimately reaching the "task idle starting" state. This achievement signifies a critical step in dynamic analysis, as it allows researchers to execute the firmware in a controlled environment without needing physical hardware.

To enable the debug output from a physical Pixel phone, willem detailed a specific hardware and software setup:

• Special USB Cable: A custom-made USB-C cable with two specific pins connected.
• Voltage Level: Crucially, the debug output operates at 1.8 volts, requiring careful attention to avoid applying the standard 5 volts from USB, which would damage the phone.
• Android Configuration: Specific Android settings must be enabled, typically by booting into fastboot mode and setting OEM UART enable and debug UART mux to configure the USB-C port for UART debug output.

Looking ahead, willem expressed his intention to further enhance the simulator by implementing the protobuf protocols that govern communication over the SPI port between the Titan M2 and the Android OS. This would enable him to fuzz the firmware, systematically testing its robustness against malformed or unexpected inputs. He also mentioned porting the simulator logic to Spike, a faster RISC-V simulator written in C, to improve fuzzing efficiency. While the Python simulator is functional for booting, a C-based version would be more practical for extensive dynamic testing and vulnerability discovery.

Defensive Implications

▶ Watch: How Android OS interacts with the Titan chip (10:30)

The detailed reverse engineering of the Pixel Titan M2 firmware by willem provides several critical insights and implications for defenders, highlighting areas where attention and scrutiny are warranted.

First and foremost, the research underscores the inherent challenges of black-box security. As a proprietary chip, the Titan M2's internal workings are not publicly documented, making independent security audits and vulnerability discovery arduous. willem's work demonstrates that even without official documentation, dedicated reverse engineering can reveal significant architectural details, custom instructions, and potential weaknesses, reinforcing the need for continuous, independent verification of secure elements.

The discovery of custom RISC-V instructions is a double-edged sword. While these instructions were found to be "mundane" bit-fiddling operations rather than complex cryptographic primitives, their proprietary nature adds complexity to the attack surface. Any deviation from standard ISA (Instruction Set Architecture) increases the learning curve for researchers and could, theoretically, harbor subtle bugs or unintended side effects that are harder to detect without intimate knowledge of the custom logic. Defenders should be aware that even seemingly simple custom instructions could be a source of vulnerabilities if not rigorously vetted.

Perhaps the most significant defensive implication stems from the silent discontinuation of the dedicated elliptic curve accelerator. The observation of a substantial reduction in the coprocessor's driver code size in later firmware versions, without any corresponding public CVE or announcement from Google, suggests that the hardware accelerator was likely abandoned due to an undisclosed security flaw. This raises concerns about the transparency of vulnerability disclosures related to secure hardware. Defenders relying on the security assurances of such chips should be aware that critical components might be silently retired or modified due to unpatched or unannounced bugs. This also implies that older devices running firmware versions that still utilize this potentially flawed hardware might remain vulnerable.

The ongoing nature of firmware updates, even without public CVEs, is also notable. willem observed continuous code changes in the Titan M2 firmware despite the drop in published CVEs. This reinforces the importance for users to always apply the latest firmware updates, as they may contain fixes for undisclosed vulnerabilities or silent security improvements. For organizations deploying Pixel devices, maintaining an up-to-date fleet is crucial, even if the specifics of every patch are not publicly detailed.

Finally, the talk implicitly highlights the challenges in supply chain security for secure elements. The reliance on an external IP core vendor (Soteria for RISC-V) combined with Google's proprietary customizations means that the security of the entire stack depends on multiple entities. While willem did not delve into rollback prevention mechanisms, this is a crucial security feature for secure elements, ensuring that older, potentially vulnerable firmware versions cannot be reloaded onto the chip. Further research into how the Titan M2 enforces rollback prevention would be valuable for a complete defensive posture. The inability to load custom firmware due to Google's signing keys, as mentioned by willem, signifies a strong defense against unauthorized modification, but also means that independent security researchers cannot easily test hypothetical fixes or custom security enhancements.

Key Takeaways

• The Titan M2 is a highly critical security chip in Pixel phones, responsible for safeguarding sensitive operations like PIN entry and cryptographic key management.
• Reverse engineering proprietary hardware and firmware, while challenging, is essential for independent security verification and understanding the true security posture of devices like Pixel phones.
• Google's Titan M2 utilizes custom RISC-V instructions not found in the standard ISA, which were successfully identified and understood by analyzing bit patterns and leveraging Ghidra's extensible processor definition capabilities.
• A dedicated elliptic curve accelerator in the Titan M2 was observed to be silently disabled in later firmware versions, likely due to an undisclosed security vulnerability, raising questions about transparency in hardware security module disclosures.
• A functional RISC-V simulator for the Titan M2 firmware was successfully developed, capable of booting the chip's firmware and providing debug output, paving the way for more efficient dynamic analysis and fuzzing for vulnerabilities.
• The research underscores the ongoing need for independent security research into secure elements to ensure transparency and accountability, especially for components operating as black boxes with proprietary implementations.

About the Speaker(s)

The talk was delivered by willem, an independent researcher with a long-standing passion for reverse engineering. His journey into understanding how things work internally began at a very young age, famously disassembling his mother's sewing machine at three. He has a history of "hacking at Hectic," an early indication of his deep-rooted interest in low-level systems. Throughout his career, willem has been driven by an insatiable curiosity to uncover the inner workings of technology. He shares his tools and insights on GitHub, contributing to the broader security research community. His expertise lies in meticulously dissecting complex systems, a skill evident in his detailed analysis of the Titan M2 firmware.