Breaking The “Unhackable” Xbox One

For more than a decade, the Xbox One stood out as one of the most resilient consumer devices ever built. While other consoles from the same era were eventually jailbroken or modified, the Xbox One remained largely untouched. Its layered defenses, hardened boot process, and strong cryptographic foundations earned it a reputation as effectively “unhackable.”

That assumption changed at RE//verse 2026, where security researcher Markus “Doom” Gaasedelen presented Hacking the Xbox One. Markus’s talk introduced the Bliss exploit, a hardware fault injection attack targeting the original Xbox One boot ROM. This marks the first successful boot ROM–level compromise of the platform after roughly 12 years.

The research serves as a clear real-world reminder that fault injection remains a critical security risk, even for systems built with advanced, modern security architectures.

A highly protected target by design

At the core of the Xbox One security architecture is the Platform Security Processor (PSP), an ARM-based component that acts as the hardware root of trust. The PSP is responsible for enforcing secure boot before the rest of the system is released.

Image credits: Markus “Doom” Gaasedelen, Hacking the Xbox One, presented at RE//verse 2026.

The Bliss attack targets the PSP’s immutable boot ROM — the very first code executed on the device. This ROM is small (approximately 64 KB, with ~19 KB of executable code), heavily reviewed, and burned into silicon.

Microsoft designed this layer with strong security assumptions, reinforced by multiple protections:

• Strong cryptographic validation, including dual signatures
• Hardware-enforced memory isolation via a Memory Protection Unit (MPU)
• ECC-protected instruction fetches
• Disabled debug interfaces (no UART, JTAG, or usable POST)
• Randomized execution delays to complicate timing attacks

The security model depended on one core assumption: if the boot ROM remains secure, the rest of the system can be trusted. That is exactly what the Bliss attack targeted: the foundation of the Xbox One’s chain of trust.

How the Bliss exploit works

To gain visibility into an intentionally opaque system, the attacker uses hardware side channels (power traces, I/O signals, and e‑fuse reads) to create reliable timing anchors. Voltage glitching (crowbar attacks) is then applied to the North Bridge power rail with precise timing, guided by the side channel signals and repeated over very large campaigns (≈100k–millions of reboot attempts) to explore the timing space.

Image credits: Markus “Doom” Gaasedelen, Hacking the Xbox One, presented at RE//verse 2026.

The exploit itself is a two-stage (“double glitch”) attack. First, a carefully timed glitch early in boot skips the loop that configures and enables the Memory Protection Unit (MPU), effectively disabling memory isolation and allowing read-write-execute access across normally protected regions. This glitch succeeds with low probability (on the order of ~1%). Second, a later glitch targets a memcpy operation used to copy the SP1 bootloader header from flash; because this routine handles attacker-controlled data, a fault in its execution corrupts register restoration and enables program counter hijacking (e.g., jumps to addresses like 0x5858xxxx derived from injected patterns). This PC control also has a similarly low success rate (~1%), and combining both glitches yields a compounded success probability of ~1 in 10,000 attempts per parameter set. Note that to arrive at a reliable parameter set, millions of tuning runs are required.

When both glitches land, the attacker escapes the boot ROM’s security protections entirely. With the MPU disabled and PC hijacked, execution jumps into attacker-controlled data in memory (the SP1 header), effectively becoming shellcode. The attack additionally corrupts saved supervisor registers, escalating from user-mode “jail” execution into full supervisor control of the PSP. This occurs before any key derivation or signature enforcement, allowing complete compromise of the chain of trust: arbitrary code execution in boot ROM context, decryption of all firmware stages, bypass of signature checks (including dual RSA/ECC validation), and control over all subsequent system layers. Because the vulnerability resides in immutable silicon ROM and hardware behavior, it is fundamentally unpatchable, impacting early Xbox One hardware at the root-of-trust level.

From research to practice: Why FI testing matters

Despite the lack of debug interfaces or visibility, the researcher reconstructed internal execution using indirect signals, like power consumption, flash access patterns, and GPIO behavior. These side channels provided just enough insight to synchronize fault injection with critical execution points.

Replicating an attack like Bliss is far beyond the scope of most development teams. The original research required deep reverse engineering, custom hardware setups, and large-scale automated glitch campaigns.

At the same time, the exploit demonstrates the level of effort a determined attacker may invest when sufficiently motivated.

Conclusion

The Xbox One was not poorly designed. It implemented strong cryptography, secure boot, memory isolation, and multiple anti-tamper measures.

The Bliss exploit shows why physical attack resistance must be validated, not assumed.

Fault injection can bypass even well-designed protections by manipulating how a device executes them. Structured FI testing allows teams to uncover these weaknesses early, before attackers do.