Security

The Angry Path to Zen: AMD Zen Microcode Tools and Insights

EntrySign opened the door to custom microcode on AMD Zen CPUs earlier this year. Using a weakness in the signature verification we can load custom microcode updates and modify behavior of stock AMD Zen 1-5 CPUs. While AMD has released patches to address this weakness on some CPUs, we can still use unpatched systems for our analysis. In this talk we cover what we found out about microcode, what we saw in the microcode ROM, the tooling we build, how we worked to find out more and how you can write & test your own microcode on your own AMD Zen systems. We have our tools up on https://github.com/AngryUEFI for everyone to play around with and hopefully help us understand microcode more than we currently do.
Modern CPUs often translate the complex, user visible instruction set like x86_64 into a simpler, less feature rich internal instruction set. For simple instructions this translation is done by a fast path decoding unit. However some instructions, like `wrmsr` or `rdrand` are too complex to decode that way. These instructions instead are translated using a microcode decoder that can act almost like an execution engine. The microcode decoder still emits internal instructions into the pipeline, but allows for features like conditional branches and calls & returns. All of this logic happens during a single x86_64 instruction and is usually hidden from the outside world. At least since AMD K8, launched in 2003, AMD CPUs allowed updating this microcode to fix bugs made in the original implementation. Building on our [previous](https://media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask) [experience](https://media.ccc.de/v/35c3-9614-inside_the_amd_microcode_rom) with AMD K8 & K10 microcode and [EntrySign](https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking) [published](https://media.ccc.de/v/why2025-156-entrysign-create-your-own-x86-microcode-for-fun-and-profit) earlier this year, we took a closer look at AMD Zen 1-5 CPUs. We build on top of [Zentool](https://github.com/google/security-research/tree/master/pocs/cpus/entrysign/zentool) to understand more instructions and created a set of tools to easily create microcode patches as well as apply them on CPUs. We can modify the behavior of instructions and observe some usually not visible internal state by supplying our own microcode update. Like on K8, we extracted the physical ROM on the CPU using an electron microscope to read the hardcoded microcode on a Zen 1 CPU. Using the understanding of the microcode encoding we could then start disassembling the contents and understand how some instructions are implemented. While there are still a lot of things we don't understand, we could follow control flow and analyze algorithms like the XXTEA decryption of the microcode update. To start off this work, we implemented a set of tools that allow easy testing of microcode updates without the need for a fully featured OS. That way we can run timing tests with low noise and don't risk data corruption if we corrupt a vital instruction. To continue our naming scheme from our work on K8 we dubbed this the AngryTools, all of them available on [GitHub](https://github.com/AngryUEFI). The core components are a UEFI application running from RAM, AngryUEFI, and a Python framework for test writing on a client computer, AngryCAT. AngryUEFI starts on the test system and waits for AngryCAT tests supplied via TCP. These tests usually consist of a microcode update that gets loaded on the target CPU core and a buffer with x64 instructions that get run afterwards. AngryUEFI then sends back information about the test execution. AngryUEFI also recovers most faults caused by invalid microcode, often even allowing reuse of a CPU core after a failed test run. We also added some syscall-like interfaces to support more complex data collection like [IBS](https://reflexive.space/zen2-ibs/). To make it easier to write custom microcode updates we also implemented [ZenUtils](https://github.com/AngryUEFI/ZenUtils), a set of Python tools. So far we support single line assembly and disassembly based on architecture specification for Zen 1 & 2 with limited support for other Zen architectures. We also include a macro assembler that can create a full microcode update from an assembly-like input file. Later we will also extend ZenUtils with utilities to sign and en/decrypt microcode updates. Currently we rely on Zentool for these tasks. We also show some basic examples of how microcode programs work, from a simple CString strlen implementation in a single x64 instruction to a [subleq](https://esolangs.org/wiki/Subleq) VM implemented entirely in microcode. These show off the basics of microcode programming, like memory loads & stores, arithmetic and conditional branches. We are also currently looking at other examples and more complex programs. We hope this talk shows you how to start throwing random bits at your own AMD Zen CPU to figure out what each bit does and help us in further understanding the instruction set. We welcome improvements to the tooling and even entirely new tools to help analyze microcode updates and the ROM. If you are already familiar with EntrySign, we only cover the very basics of it and focus more on what we learned after having a foothold in the microcode.

Weitere Infos

Live Stream https://streaming.media.ccc.de/39c3/fuse
Format Talk
Sprache Englisch

Weitere Sessions

27.12.25
Security
Jade Sheffey
Zero
The Great Firewall of China (GFW) is one of, if not arguably the most advanced Internet censorship systems in the world. Because repressive governments generally do not simply publish their censorship rules, the task of determining exactly what is and isn’t allowed falls upon the censorship measurement community, who run experiments over censored networks. In this talk, we’ll discuss two ways censorship measurement has evolved from passive experimentation to active attacks against the Great ...
27.12.25
Security
Fuse
Reports of GNSS interference in the Baltic Sea have become almost routine — airplanes losing GPS, ships drifting off course, and timing systems failing. But what happens when a group of engineers decides to build a navigation system that simply *doesn’t care* about the jammer? Since 2017, we’ve been developing **R-Mode**, a terrestrial navigation system that uses existing radio beacons and maritime infrastructure to provide independent positioning — no satellites needed. In this talk, ...
27.12.25
Security
Christoph Saatjohann
Zero
Zwei Jahre nach dem ersten KIM-Vortrag auf dem 37C3: Die gezeigten Schwachstellen wurden inzwischen geschlossen. Weiterhin können mit dem aktuellen KIM 1.5+ nun große Dateien bis 500 MB übertragen werden, das Signaturhandling wurde für die Nutzenden vereinfacht, indem die Detailinformationen der Signatur nicht mehr einsehbar sind. Aber ist das System jetzt sicher oder gibt es neue Probleme?
27.12.25
Security
tihmstar
One
While trying to apply fault injection to the AMD Platform Security Processor with unusual (self-imposed) requirements/restrictions, it were software bugs which stopped initial glitching attempts. Once discovered, the software bug was used as an entry to explore the target, which in turn lead to uncovering (and exploiting) more and more bugs, ending up in EL3 of the most secure core on the chip. This talk is about the story of trying to glitch the AMD Platform Security Processor, then ...
27.12.25
Security
One
The Deutschlandticket was the flagship transport policy of the last government, rolled out in an impressive timescale for a political project; but this speed came with a cost - a system ripe for fraud at an industrial scale. German public transport is famously decentralised, with thousands of individual companies involved in ticketing and operations. Unifying all of these under one national, secure, system has proven a challenge too far for politicians. The end result: losses in the hundreds of ...
27.12.25
Security
Ground
In August 2024, Raspberry Pi released their newest MCU: The RP2350. Alongside the chip, they also released the RP2350 Hacking Challenge: A public call to break the secure boot implementation of the RP2350. This challenge concluded in January 2025 and led to five exciting attacks discovered by different individuals. In this talk, we will provide a technical deep dive in the RP2350 security architecture and highlight the different attacks. Afterwards, we talk about two of the breaks in ...
27.12.25
Security
Fuse
FreeBSD’s jail mechanism promises strong isolation—but how strong is it really? In this talk, we explore what it takes to escape a compromised FreeBSD jail by auditing the kernel’s attack surface, identifying dozens of vulnerabilities across exposed subsystems, and developing practical proof-of-concept exploits. We’ll share our findings, demo some real escapes, and discuss what they reveal about the challenges of maintaining robust OS isolation.