1. The Patient

Entry Point: Star Wars Racer Revenge (PS2 Legacy Title via Emulator)

Ultimate Target: AMD Secure Processor (Level 0 BootROM)

The PlayStation 5 security architecture was engineered as a “Hypervisor-First” fortress. Unlike previous generations that relied on software obfuscation, the PS5 establishes a cryptographic Chain of Trust anchored directly in the silicon.

This chain flows linearly from the hardware to the user experience:

1. Level 0 (Root): The AMD Secure Processor (PSP) executes immutable BootROM code fused into the chip.
2. Level 1 (Loader): The PSP verifies and loads the initial firmware.
3. Level 2 (Kernel): The Hypervisor starts, enforcing privilege separation.
4. Level 3 (Userland): Games and apps run in sandboxed environments.

However, this sophisticated fortress was breached not by attacking the walls, but by poisoning the water supply. The compromise begins at the weakest, most overlooked link: a decades-old legacy game running inside a privileged, high-performance emulator. A failure in this legacy layer (Level 3) provided the foothold necessary to launch a physical assault on the Root of Trust (Level 0).

2. The Diagnosis

Root Cause A (Software): Unbounded strcpy buffer overflow in Star Wars Racer Revenge (CUSA-03474).

Root Cause B (Hardware): Setup time violation via Voltage Fault Injection (VFI) in the AMD PSP.

The Software Fault (The Trojan Horse)

The primary entry point is a classic stack buffer overflow in the 2002 game Star Wars Racer Revenge.

In the game’s “Hall of Fame” (High Score) menu, the developers used a standard string copy function (strcpy) to move the player’s name into a fixed-size buffer on the stack. In the original PS2 environment, the input was naturally limited by the on-screen keyboard. However, on the PS5, the save file can be modified externally.

When the emulator loads a crafted save file containing a 5,000-character name:

1. Overflow: The name data exceeds the allocated buffer size.
2. Overwrite: The data spills over into adjacent stack memory, specifically overwriting the Return Address (RA).
3. Hijack: When the function attempts to return, it pops the corrupted address from the stack and jumps to a location defined by the attacker, effectively handing over control of the virtual CPU.

The Silicon Fault (The Glitch)

Once code execution is achieved via the game, the attacker faces the ultimate barrier: the Hardware Root of Trust. The AMD PSP verifies the firmware signature at boot using a cryptographic check:

// Critical BootROM Logic
if (VerifySignature(Firmware) == VALID) {
    Boot();
} else {
    Halt();
}

This logic relies on physics. The transistor gates inside the CPU need a specific amount of time (propagation delay) and voltage to switch states from 0 to 1.

By attaching an FPGA to the PS5’s voltage regulator and shorting the power rail to ground for mere nanoseconds (a “glitch”) exactly when this if statement executes, attackers induce a Setup Time Violation. The logic gate fails to switch state in time, causing the CPU to misinterpret the “Signature Invalid” result as “Valid,” allowing unsigned code to execute at the highest privilege level (Level 0).

3. The Kill-Chain

The attack methodology represents a hybrid vector, necessitating the physical acquisition of a legacy artifact to stage a software exploit, which is then leveraged to facilitate a hardware-level cryptographic break.

Phase 1: The Artifact Acquisition (Supply Chain Immutable Vulnerability)

The entry point is predicated on the possession of the physical Blu-ray release of Star Wars Racer Revenge (Title ID: CUSA-03474), specifically the limited print run manufactured by Limited Run Games (LRG).

• The Unpatchable Medium: Unlike the digital SKU (Stock Keeping Unit) available on the PlayStation Network—which Sony can patch, update, or revoke remotely—the physical disc relies on Read-Only Memory (ROM). The binary code, including the vulnerable PS2 emulator wrapper (version 1.00), is physically pressed into the polycarbonate layer of the disc.
• The “Dongle” Effect: This effectively transforms the game disc into a permanent “hardware dongle.” As long as the PS5 possesses an optical drive capable of reading the disc, it must execute the unpatched, vulnerable code contained within the optical media to launch the game, bypassing modern software deployment security controls.

Phase 2: The “Mast1c0re” Escalation (Software & JIT Exploitation)

Once the vulnerable environment is loaded, the attacker moves from a standard user session to arbitrary code execution via a multi-stage software payload.

1. Payload Injection (Save Game Modification): The PS5 treats PS2 save data as a virtual memory card file. The attacker constructs a malicious save file on a PC, manually editing the hexadecimal values of the “High Score” name entry. This entry is padded with a specific byte pattern (the payload) that exceeds the game’s internal buffer allocation.
2. Stack Smashing (Instruction Pointer Hijack): When the user navigates to the “Hall of Fame” menu, the game blindly copies the name into the stack memory.
   • The Overflow: The massive input overflows the local variable buffer and corrupts the Saved Frame Pointer and, crucially, the Return Address (RA).
   • Control Flow: Instead of returning to the main game loop, the CPU’s Instruction Pointer (RIP/PC) is redirected to a ROP Chain (Return-Oriented Programming). This chain of small code gadgets disables Data Execution Prevention (DEP) for a specific memory region.
3. JIT Spraying (Architecture Bridging): The PS5’s native architecture is x86-64, but the game is MIPS (PS2). To bridge this gap, the exploit abuses the emulator’s Just-In-Time (JIT) Compiler.
   • The Mechanism: The attacker feeds the emulator specially crafted MIPS instructions. These instructions are valid MIPS code, but they are chosen specifically because their translated x86 machine code representation forms a valid x86 shellcode payload.
   • The Execution: The emulator compiles this “game code” into executable x86 instructions in the PS5’s memory.
4. Sandbox Breakout: The ROP chain redirects execution to this newly compiled JIT block. The processor is now executing native x86-64 code supplied by the attacker, effectively escaping the “PS2 Virtual Machine” and gaining full Userland control over the PS5 OS.

Phase 3: The Root Extraction (Hardware Voltage Glitching)

With Userland access, the attacker can run unsigned code but cannot access the Kernel or Hypervisor, which are protected by the AMD Secure Processor (PSP). To defeat this, the attacker attacks the physics of the chip itself.

1. Hardware Preparation: The console is disassembled to expose the APU. Attackers solder wires to the VDD_CORE (Voltage Drain Drain) rails of the processor. These lines are connected to an FPGA-based glitching rig (e.g., ChipWhisperer or a custom-built crowbar circuit).
2. Differential Fault Analysis (The Glitch): The system is rebooted. The FPGA monitors the power signature to identify the exact clock cycle where the Level 0 BootROM performs the RSA signature verification of the firmware.
   • The Strike: At the precise moment of the conditional branch instruction (JNE - Jump if Not Equal), the FPGA shorts the voltage rail to ground for approximately 20-100 nanoseconds.
   • The Effect: This creates a setup time violation. The logic gates responsible for the “Security Check Failed” branch fail to switch states fast enough. The CPU treats the check as “Passed” and continues execution.
3. Level 0 Compromise (Key Dump): Having bypassed the signature check, the attacker executes a custom payload at the BootROM level (Ring -3). This payload instructs the PSP to read the fused, immutable Root Keys from the secure silicon and write them to a shared memory buffer accessible by the compromised Userland.
4. Total Architecture Collapse: Possessing the Level 0 keys breaks the Chain of Trust permanently. The attacker can now decrypt all subsequent layers (Level 1 Loader, Level 2 Kernel, Level 3 App), decrypt all past and future firmware updates, and sign their own custom firmware (CFW) if signature checks are patched out.

4. The Remediation Landscape

Status: Irreparable on current hardware revisions.

This vulnerability represents a “Forever Day” scenario due to the immutability of the two core components affecting the entire global install base of approximately 85 million units sold prior to Q1 2026.

1. The Silicon (Root of Trust): The Level 0 BootROM keys are stored in eFuses (electronic fuses). These are microscopic physical bridges burned during the manufacturing process. They cannot be logically rewritten, rotated, or patched. The secret is no longer secret, and the lock cannot be changed.
2. The Media (Entry Point): The Blu-ray disc is Read-Only Memory (ROM). The vulnerable machine code is physically pressed into the polycarbonate layer of the disc. Sony cannot push an over-the-air update to a piece of plastic sitting on a user’s shelf.

Mitigation Strategies (Soft Revocation):

While the flaw cannot be removed, the exploitation path can be obstructed via firmware updates (e.g., Firmware 12.50+):

1. Title ID Revocation (The “Ban” Hammer):
   • Mechanism: Sony can update the Operating System’s “Denylist.” Before mounting any game, the Hypervisor checks the disc’s param.sfo (header file).
   • Implementation: If the Title ID matches CUSA-03474 (the specific LRG release), the OS can refuse to launch the executable, displaying a “Security Policy” error or forcing a mandatory download of the patched digital version.
   • Limitation: This only works if the user updates their console. Offline consoles remain vulnerable indefinitely.
2. Save Data Chain-of-Trust Hardening:
   • Mechanism: The entry point relies on a PC-modified save file. The current save encryption (or checksumming) for the PS2 emulator wrapper is evidently insufficient or has been reverse-engineered.
   • Implementation: Sony can introduce a new, stronger signing key or encryption wrapper for PS2 save data in the next firmware. The emulator would then reject any save file that does not possess a valid signature generated by the new firmware, effectively neutralizing the “trojan horse” save file.
3. Future Silicon: Active Glitch Detection:
   • Mechanism: For future hardware revisions (e.g., PS5 Pro / Chassis D), the fix must be physical.
   • Implementation: AMD must integrate Brown-Out Detectors (BOD) and Glitch Filters directly onto the APU die.
   • Function: These analog sensors monitor the voltage rail in real-time. If they detect a transient voltage drop (a “glitch”) that exceeds a safety threshold (e.g., >10% drop for <50ns), the circuit immediately triggers a hardware RESET signal, wiping the volatile memory and halting the CPU before it can execute the instructions in the compromised state.

5. Developer’s Takeaway

The Asymmetry of Temporal Defense. This breach serves as a definitive case study in Temporal Attack Surfaces. Security architects often visualize attack surfaces in terms of network ports or user inputs, but rarely in terms of time.

• The Conflict: The PlayStation 5 was engineered in the 2020s, utilizing state-of-the-art mitigation strategies: Kernel Address Space Layout Randomization (KASLR), Control Flow Integrity (CFI), and a hardware-enforced Hypervisor.
• The Failure: These 2026 defenses were rendered irrelevant by a single function call written in 2002. The standard strcpy function (which lacks bounds checking) pre-dates modern secure coding standards. By integrating this legacy binary, Sony inadvertently effectively “backported” a vulnerability from an era before stack canaries existed into a modern zero-trust environment.

The Emulator Trap: JIT is the Bridge. Developers must recognize that high-performance emulation is inherently dangerous. To run legacy code at acceptable speeds, emulators utilize Just-In-Time (JIT) compilers.

• The Risk: JIT compilers frequently require memory pages that are both Writable and Executable (), or rapidly switch between the two. This violates the fundamental (Write XOR Execute) security principle.
• The Exploit: The “Mast1c0re” exploit did not just crash the game; it used the emulator’s own JIT engine to compile the buffer overflow payload into valid x86-64 native code. If your application includes a scripting engine or emulator, you are providing attackers with a mechanism to bypass your own memory protections.

The Mandate for Hardware Isolation. Software sandboxing is no longer sufficient for legacy compatibility layers.

• The Flaw: Running an emulator as a process within the main OS (even with reduced privileges) exposes the Kernel syscall interface to the legacy code.
• The Solution: Legacy environments should ideally be restricted to Isolated Hardware Contexts. This means utilizing IOMMU groups to strictly limit what memory the legacy process can address, or offloading legacy execution to separate, lower-privileged cores that physically cannot access the primary hypervisor’s memory space. If you must support 20-year-old code, treat it as hostile malware by default.