Toward Verifiable Microcode: Reverse Engineering AMD Zen5 Update

Toward Verifiable Microcode: Reverse Engineering AMD Zen5 Update

Speakers: Kaya Ercihan (Security Engineer, Switch), Antonio Vazquez Blanco (Tarlogic)

Conference: Area41

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

Overview

In their Area41 talk, "Toward Verifiable Microcode: Reverse Engineering AMD Zen5 Update," Kaya Ercihan and Antonio Vazquez Blanco presented a groundbreaking methodology and a suite of custom tools designed to systematically collect, analyze, and reverse engineer AMD Zen 5 microcode updates. Their work addresses the critical lack of public documentation and transparency surrounding CPU microcode, a fundamental layer of software that dictates how complex instructions are executed by the hardware. The initial motivation for this extensive research was to investigate potential vulnerabilities in the cryptographic coprocessor responsible for generating random numbers (RNG), specifically the RDRAND and RDSEED instructions, which are widely used by applications like OpenSSL.

The speakers highlighted the profound security implications of microcode, noting that subtle alterations or vulnerabilities within this layer could compromise the integrity of cryptographic operations or introduce backdoors. Given the proprietary and often opaque nature of microcode, verifying its behavior and ensuring its trustworthiness remains a significant challenge for the security community. Ercihan and Blanco's project provides a crucial step toward demystifying this black box, offering a framework for security researchers to independently analyze microcode updates, link them to publicly disclosed vulnerabilities, and ultimately contribute to a more verifiable and secure computing ecosystem. Their tools and collection of over 400 AMD microcode patches represent the largest publicly available dataset, paving the way for deeper security analysis.

This research is particularly relevant as modern CPUs increasingly rely on complex microcode to implement features, fix bugs, and even patch critical security vulnerabilities post-silicon. The ability to understand and scrutinize these updates is paramount for maintaining trust in the foundational hardware of our digital world. By enabling a more systematic approach to microcode reverse engineering, the speakers are empowering the broader security community to independently audit CPU behavior, fostering greater transparency and accountability from CPU manufacturers.

Background

▶ Watch: Introduction and what microcode is (0:00)

Microcode serves as an essential intermediary layer within modern CPUs, translating complex Instruction Set Architecture (ISA) instructions into simpler operations that can be executed by the hardware's basic execution units. While the core microcode is typically stored in an immutable ROM on the CPU, manufacturers incorporate a small amount of RAM to allow for temporary updates, often referred to as patches. These microcode updates are crucial for addressing hardware defects, improving performance, and, most importantly, patching critical security vulnerabilities that are discovered after the CPU has been manufactured and deployed. The inherent complexity of modern CPUs, driven by demands for higher performance and speculative execution, makes them susceptible to serious hardware defects, as evidenced by a 70-billion-dollar problem linked to Intel.

The initial impetus for Ercihan and Blanco's research was a deep concern about the integrity of the cryptographic coprocessor responsible for generating true random numbers via ring oscillators and conditioning them with AES encryption (CBC-MAC). They identified potential attack vectors, such as replacing physical entropy with a deterministic counter or a static, manufacturer-known secret, which could weaken the RNG without being statistically obvious. This concern was amplified by the widespread use of RDRAND and RDSEED instructions in critical applications like OpenSSL when compiled with the --with-rand-seed option. Analyzing this specific logic, however, required a foundational understanding of AMD microcode itself, a field notoriously lacking in public documentation.

Prior work, notably from Google Project Zero, provided crucial insights. They established that microcode is initially shipped in ROM and must be reloaded from a patch RAM at every boot. Critically, for Zen 5 architectures, microcode patches are cryptographically authenticated, a significant security enhancement compared to earlier Zen 1 and Zen 2 generations, where authentication was either absent or limited. Google Project Zero also revealed that microcode is organized into op quads, meaning even single instructions might occupy a block, with the end of an op quad pointing to the next, which can be non-contiguous. These foundational understandings underscored the complexity of the task but also provided a starting point for their systematic approach to collecting, decrypting, and ultimately reverse engineering AMD microcode.

Key Findings

▶ Watch: Collecting AMD microcode with custom tools (6:00)

The research yielded several critical findings that significantly advance the state of AMD microcode analysis. Foremost among them is the successful development of a comprehensive methodology and toolchain for collecting, processing, and analyzing AMD Zen 5 microcode updates, effectively transforming a largely opaque area into one amenable to systematic research. The speakers amassed the largest known public collection of AMD microcode patches, exceeding 400 samples, which is a vital resource for future security investigations.

A significant discovery was the presence of encrypted microcode payloads. Through statistical analysis of payload entropy, they identified that some patches exhibit high entropy, indicating encryption, while others have lower entropy, suggesting unencrypted code. This finding highlights a critical barrier to analysis and underscores the necessity of recovering encryption keys to fully understand the behavior of all patches.

Furthermore, Ercihan and Blanco developed a robust method to pinpoint specific microcode updates to AMD security bulletins and CVEs, despite the absence of public release notes for microcode. By correlating the revision ID found in microcode headers with those mentioned in AMD's security advisories, they successfully linked a specific patch to AMD SB7055, which addressed CVE-2025-62626—an entropy lowering issue affecting the RDRAND instruction on AMD Zen 5 processors, specifically demonstrated on an AMD EPYC 9965 128-core processor. This capability is paramount for security researchers to understand the precise nature of vulnerabilities and how they are mitigated at the microcode level.

The project also revealed the intricate structure of AMD microcode patches, detailing the presence of primary (unsigned) and secondary (signed) headers, cryptographic blocks, and critically, match and mask registers. These registers implement a "breakpoint-like" patching mechanism, redirecting execution from ROM to the patch RAM. The challenge of publicly unknown addresses for these match registers was also identified, requiring further dynamic analysis for full understanding. Overall, the project established a reproducible workflow for microcode reverse engineering, demonstrating that independent analysis of this crucial CPU component is achievable.

Technical Deep Dive

▶ Watch: Pinpointing microcode patches to security bulletins (12:00)

The technical core of this research revolves around dismantling the layers of obfuscation and proprietary formats surrounding AMD microcode. At its most fundamental level, microcode acts as a software layer that orchestrates the CPU's simpler hardware execution units to implement complex instructions defined by the Instruction Set Architecture (ISA). This approach reduces silicon complexity and cost but shifts complexity into an opaque software component.

Microcode updates are delivered as patches to address issues in the immutable ROM-based microcode. These patches are loaded into a small, volatile patch RAM upon every system boot. For AMD Zen 5 architectures, these patches are cryptographically authenticated, adding a layer of security by preventing unauthorized modifications. The microcode itself is organized into op quads, fixed-size blocks of instructions, where the last instruction points to the next op quad, which might not be contiguous in memory.

The first major challenge was microcode collection. Since AMD microcode is not publicly distributed, the researchers targeted the update process. They observed that Linux systems commonly load microcode patches from the linux-firmware package. To process these, they developed a custom Python script called AMD Microcode Container. This tool extracts individual patches from the container files, avoiding the limitations of the Linux kernel's loader code and AMD's proprietary tools. To build a historical and comprehensive dataset, they created Sense Scraper, a tool that iterates through public firmware repositories, extracting and standardizing microcode files across commits. This effort resulted in a collection of over 400 unique AMD microcode patches, made publicly available in the amd-zenith repository.

Once collected, the patches undergo a multi-stage analysis workflow:

1. Binary Header Extraction: This step parses the primary (unsigned) and secondary (signed) headers of each microcode patch. Fields like the update revision ID, loader ID, processor signature, and various date formats (including the peculiar "13th month" specific to AMD) are extracted. Consistency checks are performed across the two headers to ensure data integrity.
2. CPU ID to Model Enrichment: Raw hexadecimal CPU IDs are cross-referenced with public databases like x86.msr.online.db to map them to human-readable processor families, models, and platform labels. This contextual information is crucial for understanding which CPUs a patch targets.
3. Tabular Normalization: All extracted and enriched data is compiled into a CSV file, providing an easily digestible overview for semantic and differential analysis.
4. Revision to Advisory Pinpointing: A critical innovation was linking microcode revision IDs to AMD's public security bulletins (e.g., AMD SB7055). By programmatically crawling AMD's security advisories and matching revision strings, they successfully identified patches for specific CVEs, such as CVE-2025-62626, an entropy-lowering issue affecting the RDRAND instruction on AMD Zen 5 processors (e.g., EPYC 9965).

Delving deeper into the patch structure, the researchers identified that the executable payload is preceded by a main header, cryptographic signing blocks, and a secondary header containing crucial metadata like an "encrypted" bit. The microcode patching mechanism operates akin to a hardware breakpoint: when the CPU encounters an address specified in a match register (part of the patch), execution is redirected from the ROM to the microcode patch in RAM. After the patch code executes, control returns to the ROM. The challenge here is that the addresses stored in these match registers are not publicly documented, making static analysis difficult without dynamic testing.

A key discovery was the presence of two distinct types of executable payloads, identifiable by their entropy. High-entropy payloads indicate encryption, meaning a significant portion of AMD's microcode updates are obfuscated and require decryption before meaningful analysis can occur. Low-entropy payloads, conversely, are unencrypted.

To facilitate interactive reverse engineering, the team developed Senella, a plugin for Binary Ninja. Senella automates the parsing of microcode headers, tags initial opcodes, and annotates various structural elements like compact metadata, cryptographic blocks, extended control regions, and the match/mask register blocks. It also exposes vital fields like the update revision identifier and loader identifier. The initial opcode tagging relies on a combination of known opcodes (some from Google Project Zero, others derived heuristically) and a classification system based on:

• Frequency of occurrence.
• Entropy of auxiliary operand bytes.
• Entropy of immediate fields.
• In-range immediate heuristics for branch-like behavior.

This heuristic analysis assigns a probability to potential branch opcodes, allowing for a more structured disassembly even without full documentation. The development of Senella was not without challenges, particularly in accurately calculating offsets within the complex header structures.

Demo / Proof of Concept

▶ Watch: Live demonstration of Senella reverse engineering tool (20:00)

The core of the live demonstration centered on Senella, the custom plugin integrated into Binary Ninja, showcasing its capabilities for interactive reverse engineering of AMD microcode. The speakers used a decrypted microcode patch specifically linked to CVE-2025-62626, the entropy-lowering issue affecting the RDRAND instruction on Zen 5.

Upon opening the patch binary in Binary Ninja, the presenters first had to manually "undefine" the automatic analysis performed by Binary Ninja, as it was not tailored for the unique microcode architecture. This highlighted an area for future improvement in the plugin's integration. With the default analysis cleared, they invoked the AMD microcode plugin from the Binary Ninja interface.

The plugin immediately parsed and annotated the file. The first prominent display was the primary header, which is unsigned. Key fields were highlighted:

• The dating code (e.g., 3CD).
• The update revision string, which was crucial for pinpointing the patch to the AMD security bulletins.
• The loader ID, emphasized as a critical field because different CPU components (e.g., main processor vs. cryptographic coprocessor) might use different loaders, leading to varied interpretations of the microcode.
• The processor signature, which, while displayed, currently requires external tooling for mapping to a human-readable name, indicating an area for future integration into Senella.

Following the primary header, the plugin displayed the cryptographic material, including the microcode signature and modulus. Next was the secondary header, which is signed. This header contained an encrypted bit, which for this specific demo patch was set to zero, confirming it was not encrypted. The loader ID was also present again here, reinforcing its importance.

A significant part of the demo focused on the match and mask registers. These were displayed as raw hexadecimal values. The speakers explained that these registers contain the addresses where microcode execution is redirected from ROM to the patch RAM. They openly acknowledged a limitation: due to budget constraints, they could not afford dynamic testing on an expensive AMD EPYC 9965 processor, and thus the exact meaning of these hexadecimal addresses (i.e., which ROM instructions they target) could not be fully resolved. This also meant they couldn't "steal" (in their words, for documentation purposes) this information from Google Project Zero's work, as it focused on different processor models.

Finally, the demo revealed the actual microcode payload, with opcodes already tagged by the Senella plugin. The structure of these tagged instructions was visible, although some instruction names were noted as being quite long, leading to truncation in the Binary Ninja display (e.g., "AMD Zen Rex SRC control flow candidate"). The tagging, while heuristic, provided a foundational level of disassembly, demonstrating the plugin's ability to bring structure to the otherwise raw binary data. The demonstration successfully conveyed the power of their tooling in providing an initial, structured view into AMD microcode, despite the inherent complexities and remaining challenges.

Defensive Implications

▶ Watch: Q&A: AMD RDRAND entropy lowering bug (27:00)

The research presented by Ercihan and Blanco carries profound defensive implications, particularly for organizations and individuals relying on the integrity of their CPU hardware. The ability to systematically collect, identify, and partially reverse engineer AMD microcode updates provides an unprecedented level of transparency into a critical and historically opaque layer of computing.

Firstly, the project highlights the paramount importance of applying microcode updates promptly. The successful correlation of specific patches to security bulletins and CVEs, such as CVE-2025-62626 addressing an entropy-lowering issue in RDRAND, underscores that critical vulnerabilities can reside deep within the CPU's microcode. Defenders must recognize that these updates are not mere performance tweaks but essential security fixes that directly impact the reliability of cryptographic operations and other fundamental CPU functions.

Secondly, the discovery of encrypted microcode payloads introduces a new challenge for defensive analysis. While the research provides tools for unencrypted patches, the existence of encrypted updates means that a significant portion of CPU behavior remains a black box even after collection. Defenders should advocate for greater transparency from CPU vendors regarding microcode encryption mechanisms or, failing that, support further research into key recovery to enable independent auditing of all patches. Without decryption, the potential for malicious or flawed code to be hidden within these updates persists.

Thirdly, the methodology for pinpointing patches to CVEs empowers defenders to perform more targeted risk assessments. Instead of treating all microcode updates as generic fixes, security teams can now potentially link specific patches to known vulnerabilities affecting their hardware. This allows for a more informed understanding of the actual security posture of their systems post-patching.

Finally, the entire endeavor contributes to the broader goal of verifiable microcode. In an era of increasing supply chain attacks and sophisticated hardware vulnerabilities, the ability to independently audit the lowest levels of CPU operation is becoming indispensable. Defenders should view this research as a critical step toward building trust in their hardware by enabling external scrutiny. It provides a framework for future work, such as differential analysis of patches, which could reveal subtle changes in CPU behavior that might not be explicitly documented, potentially uncovering new vulnerabilities or undocumented features. The tools and dataset released by the speakers offer a foundational resource for the defensive community to begin engaging with microcode analysis directly, rather than relying solely on vendor disclosures.

Key Takeaways

• Microcode is a Critical Security Layer: CPU microcode is not merely an implementation detail but a fundamental software layer that can harbor critical vulnerabilities, directly impacting the integrity of cryptographic operations like RDRAND.
• Systematic Reverse Engineering is Possible: Despite significant proprietary barriers and lack of documentation, a systematic methodology and custom tools can be developed to collect, parse, and begin reverse engineering AMD Zen 5 microcode updates.
• Linking Patches to CVEs is Crucial: It is possible to correlate specific microcode updates to public AMD security bulletins and CVEs (e.g., SB7055 and CVE-2025-62626), enabling targeted security analysis and understanding of vulnerability mitigations.
• Encrypted Payloads Pose a Challenge: A significant portion of AMD microcode patches are encrypted, requiring further research into key recovery to enable full analysis and verification of all updates.
• "Match and Mask Registers" Dictate Patching: AMD microcode patching relies on a breakpoint-like mechanism using match and mask registers, redirecting execution from ROM to patch RAM, but the target addresses are not publicly known, limiting static analysis.
• Offset Calculation is Paramount: Accurate offset calculation within complex binary headers is a recurring and time-consuming challenge in microcode reverse engineering, highlighting the need for robust parsing tools.

About the Speaker(s)

Kaya Ercihan is a Security Engineer at Switch, where his work focuses on malware analysis, operating misbehaving stances, fishing kit analysis, and, of course, reverse engineering. His expertise in dissecting complex software and hardware interactions was clearly demonstrated in this talk.

Antonio Vazquez Blanco works at Tarlogic in Spain, where he conducts extensive security research. His background includes significant work with embedded and IoT systems, Bluetooth technologies, and a strong passion for reverse engineering, making him a fitting collaborator for this deep dive into CPU microcode.