Opening pAMDora's box and unleashing a thousand paths on the journey to play Beatsaber custom songs

Opening pAMDora's box and unleashing a thousand paths on the journey to play Beatsaber custom songs

Speakers: tihmstar

Conference: 39C3

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

Overview

This talk, presented by tihmstar at 39C3, delves into a comprehensive hardware hacking journey aimed at enabling custom Beat Saber songs on a commercial gaming console. While the ultimate goal might seem lighthearted, the research behind it is a deep, technical exploration of the AMD Platform Security Processor (PSP), a critical component in modern AMD silicon responsible for secure boot and hardware initialization. The presentation outlines a multi-stage process involving bootloader exploitation, custom mod chip development, voltage glitching, and extensive reverse engineering of both firmware and hardware.

The speaker, representing a collaborative effort, meticulously details the challenges faced when conventional software exploits proved unfeasible or unsustainable. This led to a pivot towards hardware-level attacks, targeting the very root of trust within AMD's architecture. The talk is a testament to persistent, creative problem-solving in the face of complex security mechanisms, showcasing how determined researchers can uncover and leverage subtle vulnerabilities to gain control over highly secured systems.

The importance of this work extends beyond the immediate goal of playing custom songs. It provides valuable insights into the secure boot process of AMD Zen 2 CPUs, demonstrates practical techniques for fault injection, and highlights specific vulnerabilities in secure bootloaders and the PSP's internal mechanisms. For security researchers and hardware enthusiasts, it offers a detailed "cookbook" for approaching similar challenges and underscores the ongoing cat-and-mouse game between hardware designers and those seeking to bypass their protections.

Background

▶ Watch: Introduction and the challenge of custom Beat Saber songs (0:00)

The genesis of this ambitious project was a personal desire: to play custom Beat Saber songs on a specific commercial gaming console that offered an exclusive VR game. Unfortunately, the console's built-in song selection for Beat Saber was limited, and while custom songs were widely available for other platforms, they were inaccessible on the target console. The speaker's initial approach involved exploring existing software hacks, but these proved insufficient. Major exploits were either too old for the required firmware version or were user-space hacks with severely restricted attack surfaces, making them unsustainable for long-term use or widespread adoption.

Faced with these limitations, the team shifted their focus to hardware hacking. This paradigm shift was inspired by the resurgence of mod chips and the increasing prevalence of glitching techniques in the security research community. However, the console itself was prohibitively expensive for repeated hacking attempts. A clever workaround was identified: instead of buying more consoles, the team acquired significantly cheaper desktop mainboards equipped with the exact same AMD chip, albeit with the GPU disabled due to manufacturing defects. These boards shared the same ROM and a very similar boot flow, making them an ideal, cost-effective target for deep hardware research.

The true target of their investigation was the AMD Platform Security Processor (PSP). This is a 32-bit ARM Cortex A5 core embedded within the main x86-64 CPU. The PSP is the root of trust for the entire system, responsible for critical functions such as hardware bring-up (e.g., DRAM initialization) and orchestrating the secure boot chain. The boot flow sequence is intricate: upon power-on, the PSP is released from reset, its internal ROM executes initial hardware and crypto initialization, then loads, decrypts, and verifies an off-chip bootloader from SPI flash. This bootloader, in turn, loads various ALs (likely "Agiza Bootloaders" or similar mini-applications) for further hardware setup, then a secure OS (for features like fTPM or remote attestation), before finally releasing the x86 CPU to run the traditional BIOS. The core idea was that if code execution could be achieved within or immediately after the PSP ROM, full control over the system's security mechanisms and subsequent execution stages would be possible.

Key Findings

▶ Watch: Hacking cheaper, broken desktop chips instead of consoles (3:00)

The research uncovered several significant findings, demonstrating both the complexity of modern hardware security and the ingenuity required to bypass it:

1. Bootloader Bug Exploitation: A critical vulnerability was identified in the off-chip bootloader's handling of ALs (Agiza Bootloaders). Specifically, ALs were read twice from SPI flash: once for execution into SRAM and a second time for cryptographic hashing and verification. This timing window allowed for a "two-chip method" (later refined to a direct RP2040 injection) to substitute a custom, unverified payload during the first read, bypassing signature checks. This provided early code execution in the off-chip bootloader context.

1. EL1 Code Execution & Off-chip Bootloader Dump: By leveraging the ability to replace binaries, the team targeted the Secure OS, a larger component that runs in EL1 (Exception Level 1), granting higher privileges. A custom, "insecure OS" payload was injected, allowing for arbitrary code execution at EL1. This primitive was then used to dump the entire off-chip bootloader from SRAM, a crucial step for subsequent reverse engineering.

1. PSP ROM Dumping: The ultimate achievement in firmware extraction was the successful dumping of the AMD PSP ROM itself. This was accomplished by combining an AL0-based MMIO (Memory-Mapped I/O) exploit (which allowed overriding the EL1 exception vector via the CCP in pass-through mode) with a novel CPU reset primitive. The CPU reset was discovered by brute-forcing MMIO registers to find one that could halt the x86 core without resetting the PSP. This allowed for a carefully timed DMA (Direct Memory Access) transfer of the ROM contents to SRAM, which could then be extracted.

1. ROM Bug Discovery (Unexploited): Analysis of the dumped ROM revealed a fascinating vulnerability in a function dubbed "clear Rex and ST then boot." If this function was entered in FIQ (Fast Interrupt Request) mode, banked registers (R11 and R12, holding should_panic and boot_address) would be inadvertently zeroed out. This would cause the system to attempt booting from address zero instead of panicking, effectively bypassing security checks. However, the team could not identify a method to trigger a non-watchdog FIQ, rendering the bug unexploitable at the time of the talk.

1. Custom Voltage Glitching Mod Chip: For a more robust and fine-grained fault injection technique, a custom mod chip was developed. This chip integrates an op-amp (OPA 354) into the voltage regulator's feedback loop, allowing for precise manipulation of the target CPU's voltage rail. This technique successfully demonstrated SRAM glitching, corrupting code execution by inducing voltage dips. While it proved effective against SRAM, the ROM proved significantly more resilient, requiring substantially stronger glitches.

1. I²C Boot Trigger Discovery: The team identified the I²C bus as the mechanism used by an external IC to send the boot address and command to the PSP. By removing this IC and emulating its behavior with a Raspberry Pi Pico, they gained manual control over the PSP's boot sequence, enabling precise timing for future glitching attempts against the ROM.

1. Unexpected Goal Achievement: Ironically, the primary goal of playing custom Beat Saber songs was achieved not through the elaborate hardware hacks presented, but through the public release of unrelated software exploits and jailbreaks for the target console after the talk submission. This highlights a common occurrence in security research, where the journey of discovery often yields more significant technical insights than the initial objective.

Technical Deep Dive

▶ Watch: Detailed explanation of the PSP's secure boot flow (4:40)

The technical journey began with the realization that software-based exploits were a dead end for the desired firmware version. The focus shifted entirely to the AMD Platform Security Processor (PSP), an embedded ARM Cortex A5 core (likely 32-bit) within the main Zen 2 x86-64 CPU. This PSP is the root of trust, managing secure boot and hardware initialization.

The boot flow is critical:

1. Power On: PSP is released from reset.
2. PSP ROM: Executes, performs initial hardware/crypto setup.
3. Off-chip Bootloader: Loaded, decrypted, and verified by ROM from SPI flash.
4. ALs (Agiza Bootloaders): Loaded by off-chip bootloader from SPI, signed but not encrypted. Perform further hardware init (e.g., DRAM).
5. Secure OS: Loaded by off-chip bootloader from SPI, signed but not encrypted. Used for fTPM, remote attestation.
6. x86 BIOS: PSP releases x86, which then runs its BIOS.

Compromising the PSP ROM or the off-chip bootloader would grant full control.

Postcode Observation and Initial Glitching Attempts

To understand the boot process, an LPC sniffer was built using a Raspberry Pi Pico to capture postcodes — diagnostic codes output during boot. This allowed the team to map boot stages, identify success/failure conditions (e.g., SHA errors, signature errors), and pinpoint specific execution windows.

Initial glitching attempts followed the principles of "One Glitch to Rule Them All," targeting AMD's SVI2 protocol to undervolt the CPU. However, the specific voltage rail for the PSP core on the desktop board was controlled by a "dumb" voltage regulator, not an SVI2-compatible "smart" one. The team attempted to "smartify" it by bridging the target rail to an unrelated rail with a smart regulator. This approach, while conceptually sound, failed to yield consistent glitches, primarily due to an undiscovered bug in the bootloader.

The Off-chip Bootloader Bug and SPI Injection

Analysis of SPI lines during AL loading revealed a crucial vulnerability: AL0's body was read twice. The first read copied the payload into SRAM for execution, while the second read was used for cryptographic hashing and verification by a crypto co-processor (CCP). This created a window for attack.

The team developed a "two-chip method" as a proof-of-concept. By removing the original SPI flash and replacing it with two, a Raspberry Pi Pico was used to proxy the chip select (CS) lines. The Pico would monitor SPI read accesses; upon detecting the address for AL0's body, it would switch the CS line from a flash containing a custom, malicious binary (for the first read) to one containing the original, legitimate binary (for the second read). This successfully delivered custom postcodes, confirming code execution.

This method was later refined into a more practical RP2040 direct injection. By carefully lifting a single CS pin on the original SPI flash and connecting it directly to an RP2040, the Pico could directly intercept and manipulate the SPI data stream, injecting the custom payload without needing two physical flashes. This "mod chip" enabled arbitrary binary replacement, provided the custom binary was equal to or smaller than the original. A key limitation, however, was that this specific exploit path didn't work on the console, which booted differently and had a distinct off-chip bootloader.

EL1 Code Execution and Off-chip Bootloader Dump

To overcome the limitations of AL0's small size and EL0 (user-level) sandboxing, the team aimed for higher privileges. They targeted the Secure OS, which runs in EL1 (privileged mode) and is significantly larger. By replacing the Secure OS with their own "insecure OS" payload via the RP2040 SPI injection, they gained EL1 code execution. This provided capabilities like:

• Outputting custom postcodes to the LPC bus.
• Reading and writing to the SPI bus.
• Defining "magic addresses" on the SPI bus that the RP2040 could monitor, enabling a custom logging primitive and data injection for larger stage 2 payloads.

Crucially, with EL1 access, the team could dump the entire off-chip bootloader, which resides in SRAM at the point the insecure OS gains control. This dump was essential for subsequent reverse engineering.

Crypto Co-Processor (CCP) Exploration

The CCP features Local Storage Blocks (LSB), a private memory region for keys (8 blocks, 16 slots, 32 bytes each). Slots could be protected, preventing direct readout but still allowing use as keys. The team discovered that CCP addresses slots by memory type and byte offset, not index. This meant that if a key in a preceding slot was known, by incrementing the offset, one could partially access the next slot's key. This allowed for brute-forcing unknown bytes of subsequent keys. While this technique successfully dumped keys, the critical key for decrypting the off-chip bootloader was found to be overwritten with a different key before control was transferred to the off-chip bootloader, making the dumped keys "useless" for the primary goal.

PSP ROM Dumping

Dumping the PSP ROM was the holy grail. Hints from previous private research suggested "resetting the CPU while DMAing" and that "secure OS might be too late."

The breakthrough for early code execution came from an AL0 MMIO exploit. Despite AL0 running in EL0, it had read/write access to MMIO registers used for system bring-up, including CCP registers. By placing a custom CCP configuration in EL0 memory and pointing the MMIO registers to it, the CCP's pass-through mode could be used to override the EL1 exception vector. This granted EL1 code execution from within AL0. Even newer BIOS versions, which blacklisted some MMIO devices, failed to blacklist the CCP MMIO registers, allowing the same exploit to work.

Since AL0 is tiny, a stage 2 payload mechanism was devised: the EL1 payload would repeatedly read from a "magic address" on the SPI bus. The RP2040 would intercept these reads and stream in a larger stage 2 payload.

The final missing piece was a reliable way to reset the CPU without resetting the entire PSP or board. The team brute-forced the entire MMIO space by writing 0xFFFFFFFF to every address and observing system behavior (hangs, data aborts, no effect). This revealed a specific register that, when written to with 0x1, would reset the CPU.

The ROM dump strategy was then formulated:

1. Gain early EL1 code execution via the AL0 MMIO exploit.
2. Use the CCP pass-through to initiate a DMA transfer of the ROM.
3. Introduce a delay (by performing an unrelated memory copy) to allow the CPU time to receive its reset command.
4. Trigger the CPU reset via the newly discovered MMIO register.
5. Chain a second DMA transfer to copy the ROM contents into a persistent SRAM region.
6. Reset the board. The SRAM contents would survive.
7. Upon the next boot, read the SRAM contents via the SPI primitive and dump them to the RP2040's serial console.

This intricate dance successfully yielded the PSP ROM dump, whose SHA hash was shared in the talk.

ROM Reversing and the "Boot or Hang" Bug

With the ROM dumped, reverse engineering began. A critical function, internally named "clear Rex and ST then boot," was identified. This function takes a boot address and a should_panic boolean. It clears the stack, BSS, and most registers, then restores the original exception state and either boots or hangs.

The bug was in its handling of FIQ mode. If the function was entered in FIQ mode, registers R11 and R12 (which hold should_panic and boot_address) are banked. When the function switches to FIQ banked mode, these registers are zeroed. Upon switching back to the original FIQ mode, R11 and R12 are still zero. This effectively turns should_panic to false and boot_address to 0x0. The implication: any FIQ triggered by a source other than the watchdog timer would cause the system to attempt booting from address 0x0 instead of panicking. Unfortunately, at the time of the talk, no method to trigger such a non-watchdog FIQ was known, leaving this intriguing bug unexploitable.

Glitching Attempt 2 (ROM Branch) and Custom Voltage Regulator Mod

Despite the ROM bug remaining unexploitable, the ROM dump provided a new glitching target: a branch in the main function that switches to an "alternate boot path" (likely a test mode) with no decryption or signature checks. The challenge remained: when to glitch?

Further investigation of the boot flow revealed that the PSP waits for an "external boot address" and command. This was found to be delivered via I²C from a suspicious, unidentified IC on the mainboard. By observing the I²C communication (specifically writes to addresses A0, A4, A8), the team deduced the boot address (FF A200 00) and the command that triggers the actual boot. They then removed the IC and replaced its functionality with the Raspberry Pi Pico, gaining manual control over the boot sequence and precise timing for glitching.

For actual glitching, the previous SVI2-based method was deemed unsuitable for a stable system. A more refined, custom voltage regulator mod chip was designed. This chip integrates an OPA 354 op-amp into the feedback loop of the target voltage regulator. By cutting the trace between V_out and R1 in the voltage divider and inserting the mod chip, they could inject a fake voltage signal. Increasing the feedback voltage reduces the actual output voltage (undervolting), and vice-versa. This provided fine-grained control over the CPU's voltage rail.

The mod chip successfully demonstrated SRAM glitching, corrupting counter values in test code running from SRAM with relatively weak glitches. However, the ROM proved significantly more robust, requiring glitches orders of magnitude stronger. The theory is that the ROM bus itself is more resilient, and the presence of large capacitors slows voltage discharge, creating a prolonged "SRAM glitching window" where unrelated memory operations are corrupted before the voltage drops low enough to affect the ROM. Combining this with a crowbar mod to rapidly discharge capacitors was suggested but not yet attempted.

Demo / Proof of Concept

▶ Watch: The power of compromising the boot ROM or off-chip bootloader (5:30)

The talk included several demonstrations of the developed tools and techniques:

• LPC Sniffer: A physical setup showing the Raspberry Pi Pico connected to the LPC bus, capturing and displaying postcodes, illustrating the ability to observe boot progress and errors.
• RP2040 SPI Injection (Mod Chip v1): Screenshots and physical setups of the RP2040 connected to the SPI flash, showcasing how custom postcodes could be triggered by injecting custom AL payloads. This confirmed the bypass of the off-chip bootloader's signature checks.
• Voltage Regulator Mod Chip (Mod Chip v2): Visualizations from an oscilloscope demonstrated the precise, fine-grained control over the CPU's voltage rail. Custom voltage shapes, including rapid dips and rises, were shown. The effectiveness of this mod was proven by a successful SRAM glitching demonstration, where a simple counter incrementing in nested loops was corrupted, showing altered final values (e.g., 123 becoming 25000000 instead of 0). This confirmed the ability to induce faults in executing code.
• Custom Beat Saber Song: While the hardware exploits detailed in the talk did not directly lead to this, the speaker concluded the presentation by demonstrating a custom Beat Saber song running on the target console. This was achieved using unrelated public software exploits that emerged after the talk's submission, allowing for console jailbreaking, game dumping/decryption, map conversion, and binary patching to replace an existing song. A YouTube video of the speaker playing the custom song was shared, marking the successful (albeit indirectly achieved) completion of the original personal goal.

Defensive Implications

▶ Watch: Strategy for obtaining the PSP ROM dump (7:00)

The detailed research into AMD's PSP and secure boot process provides critical insights for hardware designers and security architects:

• Robustness of Secure Boot Chains: The discovery of the double-read vulnerability in the off-chip bootloader's handling of ALs highlights the need for extreme diligence in secure boot implementation. All stages of loading and verification must be robust against timing attacks and partial data substitution. Cryptographic verification should ideally occur before any part of the payload is executed or used.
• MMIO Access Control: The AL0 MMIO exploit demonstrates that even low-privileged execution environments (EL0) can pose a significant threat if they retain write access to critical MMIO registers, especially those controlling security-sensitive components like the Crypto Co-Processor. Strict blacklisting and whitelisting of MMIO access, even for seemingly innocuous devices, is crucial.
• Key Management and Lifecycle: The observation that the off-chip bootloader decryption key is overwritten before its control flow transfer is a potential design flaw. While intended to protect the key from later compromise, it inadvertently made it "useless" for attackers seeking to decrypt other bootloaders from a compromised later stage. Secure key derivation and storage mechanisms should ensure that critical keys are available only when absolutely necessary and are protected throughout their lifecycle.
• Glitching Resilience: While the PSP ROM proved highly resilient to voltage glitching compared to SRAM, the successful demonstration of SRAM glitching and the theoretical path to ROM glitching (e.g., with crowbar mods) indicates that fault injection remains a potent threat. Hardware designs should incorporate features to detect and mitigate anomalous voltage fluctuations or instruction corruption, such as redundant execution, parity checks, or robust clock and power delivery networks.
• Banked Register Vulnerabilities: The discovered ROM bug related to banked registers in FIQ mode underscores the complexity of ARM exception handling. Careful architectural review and thorough testing are needed to ensure that context switching, especially across different exception levels and modes, correctly preserves or clears sensitive register values as intended, preventing information leakage or unintended control flow redirection.
• Supply Chain Security: The reliance on external I²C components for boot command delivery introduces another potential attack surface. While the team used this to their advantage, it highlights how seemingly minor external chips can become critical points of control if their communication protocols are not secured or if the components themselves can be tampered with.

Overall, this research serves as a stark reminder that even well-designed secure boot mechanisms require continuous scrutiny. Attackers will relentlessly explore every avenue, from software bugs to deep hardware vulnerabilities, to gain control over systems.

Key Takeaways

• Hardware hacking is a viable and powerful alternative when conventional software exploits are patched or unavailable, especially against deeply embedded systems like the AMD PSP.
• Persistence and creative problem-solving are paramount. The journey involved numerous failed attempts, shifts in strategy (e.g., from console to desktop boards, from SVI2 to custom voltage mod), and ingenious techniques like the "two-chip method" and MMIO brute-forcing.
• Deep understanding of the boot flow is critical. Meticulously mapping the boot stages, observing postcodes, and analyzing SPI communication were essential for identifying vulnerabilities and timing attacks.
• Even seemingly "useless" findings contribute to the overall understanding. The crypto co-processor key dumping, despite yielding "useless" keys, provided valuable insights into AMD's key management, and the unexploitable ROM bug deepened understanding of the PSP's internal architecture.
• Custom mod chips and fault injection are powerful tools. The voltage regulator mod chip demonstrates how fine-grained control over hardware parameters can enable precise glitching for bypassing security mechanisms.
• The research journey itself holds immense value. While the ultimate goal of playing custom Beat Saber songs was achieved through unrelated public exploits, the detailed hardware research significantly advanced the understanding of AMD PSP security.
• Open-sourcing tools and findings benefits the security community. Releasing the ROM dumping payload, mod chip PCB design, and firmware allows others to reproduce, learn from, and build upon this work.

About the Speaker(s)

The talk was presented by tihmstar, who emphasized that the work was a collaborative effort involving several individuals, many of whom could not be publicly named due to corporate affiliations or personal preference. tihmstar himself appears to be a dedicated hardware hacker, driven by a personal goal (playing custom Beat Saber songs) that led to an extensive and deeply technical exploration of AMD's Platform Security Processor. His presentation style is confident and analytical, reflecting a deep understanding of the subject matter and a methodical approach to complex security challenges. The motivation to "commit and push" ("if you commit you need to push") encapsulates the persistent nature of the research presented.