RE//verse 2026: Hacking the Xbox One by Markus 'doom' Gaasedelen
57:17

RE//verse 2026: Hacking the Xbox One by Markus 'doom' Gaasedelen

REverse Conference

7 chapters7 takeaways15 key terms5 questions

Overview

This video details the complex process of hacking the Xbox One's boot ROM, a feat previously considered impossible due to Microsoft's advanced security measures. The presenter, Markus 'doom' Gaasedelen, explains the layered security architecture and the challenges faced, including the lack of traditional debugging interfaces and the implementation of randomized stalls. The talk culminates in the discovery of a method to bypass these protections, achieving code execution at the most fundamental level of the console's startup process. This breakthrough, dubbed 'Bliss', allows for full system compromise, enabling decryption and execution of any code, with significant implications for console preservation and repair.

How was this?

Save this permanently with flashcards, quizzes, and AI chat

Chapters

  • The Xbox One was marketed as Microsoft's most secure product, with previous generations of consoles (Xbox 360) being more vulnerable.
  • Unlike other consoles, the Xbox One had never been publicly hacked, making it a significant challenge for security researchers.
  • The talk aims to achieve code execution on the boot ROM, a 'god mode' hardware hack that cannot be patched.
  • The presenter's previous talk focused on the original Xbox, serving as a prelude to this more complex hack.
Understanding the historical context and the perceived invulnerability of the Xbox One highlights the significance of the subsequent hacking achievement.
Microsoft describing the Xbox One as 'the most secure product Microsoft has ever produced' even in 2020.
  • The Xbox One's security relies on a layered approach, emphasizing compartmentalization, virtualization, and revocation, as architected by individuals like Tony Chen.
  • The entire chain of trust hinges on the boot ROM, which is considered the most critical and unrecoverable component.
  • The console features a custom System on Chip (SoC) with a Platform Security Processor (PSP) containing the boot ROM.
  • The boot process begins with the ARM core of the PSP, which then initializes the x86 components.
Knowing the security architecture and boot flow is essential for identifying potential attack vectors and understanding the significance of compromising the boot ROM.
Tony Chen's 2019 talk described the Xbox One security stack in layers, leaning heavily on compartmentalization, virtualization, and revocation.
  • Unlike the Xbox 360, the Xbox One lacks traditional debugging interfaces like postcodes or JTAG, and has disabled features like reset pin glitching.
  • Microsoft implemented 'randomized stalls' within the boot ROM, acting like Address Space Layout Randomization (ASLR) for glitch timings, making precise fault injection difficult.
  • The presenter initially lacked crucial hardware introspection tools, forcing them to 'glitch totally blind' without power traces or clear targets.
  • Early attempts involved analyzing power traces and I2C traffic, but the randomized stalls and lack of clear signals made interpretation challenging.
These challenges illustrate the extreme difficulty of hardware hacking on modern secure systems and the ingenuity required to overcome them.
Microsoft disabled postcodes via e-fuses and removed the reset pin, preventing common fault injection techniques used on the Xbox 360.
  • By analyzing power traces and probing various signals, the presenter identified an interrupt signal that unexpectedly varied, hinting at randomized stalls.
  • Further investigation revealed that while postcodes were fused off, the GPIO pins used for them were initialized early in the boot process.
  • A voltage glitch applied during the GPIO initialization logic successfully enabled the fused-off postcodes, providing the first meaningful hardware introspection.
  • This breakthrough demonstrated the ability to influence the boot ROM and broke the illusion of the Xbox One being unhackable.
Enabling postcodes was a critical turning point, providing the necessary visibility to understand and manipulate the boot ROM's execution.
Applying a voltage glitch caused the normally flat GPIO line to show activity, indicating the successful enablement of postcodes.
  • The next target was to glitch the fetching of the SP1 bootloader header over the PCI bus, specifically during a memcopy operation.
  • Memcopy is a vulnerable target for fault injection because attacker-controlled data frequently flows through it, increasing the chance of corruption leading to arbitrary writes or PC hijacks.
  • By corrupting a memcopy operation, the presenter could cause a segmentation fault, resulting in a fatal error code that revealed information about the faulting address.
  • This allowed for the control of the program counter (PC), enabling arbitrary jumps within the boot ROM, effectively bypassing security checks and randomized stalls.
Gaining control of the program counter is a fundamental step towards full system compromise, allowing the attacker to dictate the execution flow.
Corrupting the memcopy routine led to a 'permission fault' where the PC tried to jump to an invalid address, which was reported as a fatal error code.
  • Despite PC control, the system's Memory Protection Unit (MPU) and 'user jails' prevented arbitrary memory access and execution.
  • The MPU, initialized early in boot, compartmentalizes different modes and regions of memory.
  • A second glitch was developed to target the MPU initialization loop, causing it to break out early and preventing the MPU from being enabled.
  • This 'Bliss' glitch, when combined with the PC hijack glitch, allowed for arbitrary code execution in supervisor mode, bypassing all security restrictions.
Disabling the MPU is crucial for achieving full system control, as it removes the barriers that isolate different parts of the system and prevent unauthorized access.
A glitch targeting the MPU initialization loop caused the system to skip the MPU enablement, effectively disabling memory protection.
  • The 'Bliss' hack involves two glitches: one to skip MPU enablement and another to hijack the program counter.
  • This allows for arbitrary code execution as supervisor, before critical key transformations and revocation checks occur.
  • The compromise enables decryption and execution of any code at all system levels, including firmware, hypervisor, and operating systems.
  • This breakthrough has significant implications for game preservation, console repairability, and potentially future research into other secure systems.
Achieving unpatchable, low-level code execution grants complete control over the console, opening doors for preservation and repair efforts previously impossible.
The hack allows for dumping all fuses, decrypting later stages of the boot process, and executing unsigned code at every level of the system.

Key takeaways

  1. 1Even the most secure systems can be vulnerable if fundamental hardware principles are exploited.
  2. 2Persistence and creative problem-solving are crucial when facing seemingly insurmountable security challenges.
  3. 3Hardware introspection, even without traditional tools, can be developed through careful observation of power traces and side channels.
  4. 4Randomized stalls and memory protection units are advanced security measures, but they can be bypassed with precisely timed fault injection.
  5. 5Achieving control at the boot ROM level provides the highest level of system compromise, enabling deep access and modification.
  6. 6This hack has profound implications for digital preservation, allowing access to historical data and content that might otherwise be lost.
  7. 7The 'Bliss' hack demonstrates that even complex, multi-layered security can be defeated by targeting the earliest stages of the system's boot process.

Key terms

Boot ROMPlatform Security Processor (PSP)System on Chip (SoC)Fault InjectionVoltage GlitchingPower TracesRandomized StallsMemory Protection Unit (MPU)User JailsProgram Counter (PC)Arbitrary Code ExecutionChain of TrustSide Channel AttackPostcodesE-fuses

Test your understanding

  1. 1What is the primary reason the Xbox One was considered exceptionally secure, and how did the presenter's approach challenge this perception?
  2. 2How did Microsoft's implementation of 'randomized stalls' and the absence of traditional debugging interfaces complicate the hacking process?
  3. 3Explain the significance of enabling the fused-off postcodes and how this was achieved through hardware manipulation.
  4. 4What is the 'Bliss' hack, and what are the two key glitches that enable it?
  5. 5What are the main implications of achieving unpatchable code execution at the Xbox One's boot ROM level, particularly concerning game preservation and system security?

Turn any lecture into study material

Paste a YouTube URL, PDF, or article. Get flashcards, quizzes, summaries, and AI chat — in seconds.

No credit card required

RE//verse 2026: Hacking the Xbox One by Markus 'doom' Gaasedelen | NoteTube | NoteTube