Xbox One Finally Hacked After 12 Years — What It Means for You
After more than a decade of standing firm against the security research community, the original Xbox One has finally been cracked. Security researcher Markus Gaasedelen presented his findings at RE//verse 2026, revealing a hardware-level exploit in the Xbox One’s boot ROM — and the implications for repairability, game preservation, and the wider modding scene are enormous.
The "Unhackable" Console Gets Cracked
The Xbox One launched in 2013 with what was considered state-of-the-art security for a consumer game console. Its Secure Boot chain, hardware-fused encryption keys, eFuse protections, and multi-stage boot ROM earned it a near-universal reputation as unhackable among security researchers. In 2020 — seven years post-launch — Microsoft publicly touted the Xbox One as the most secure product the company had ever engineered.
That streak is now over.
Gaasedelen’s exploit, named “Bliss,” targets a hardware flaw in the boot ROM itself — the very first code that executes when the console powers on. Because the vulnerability is baked into the silicon, Microsoft cannot patch it via a software or firmware update. Every original 2013 Xbox One “Fat” is permanently vulnerable.
Background: Why the Xbox One Was So Hard to Crack
To understand the magnitude of this, it helps to know what made the Xbox One so resilient in the first place.
At the heart of the console’s security is the Platform Security Processor (PSP) — a dedicated ARM Cortex R4 chip buried in the corner of the SOC die. The PSP wakes up before any x86 component of the console even powers on. It reads each subsequent boot stage, decrypts it, loads it into memory, and only then releases the main processor from reset.
Microsoft’s security architects understood a key truth: software can be patched, but silicon cannot. The boot ROM code was linear, one-shot, and subjected to exhaustive auditing. Every instruction was fetched directly from silicon, backed by Error Correction Code (ECC) bits literally burned into the die to prevent tampering. There were no debug interfaces, no UART, no JTAG, no available datasheets, and no reset pin available for manipulation.
On top of that, Microsoft engineered a hardware countermeasure called Randomized Stalls — 37 random pause loops peppered throughout the ~300,000-instruction boot sequence, with roughly half of all instructions being randomized pauses doing nothing. This acted as a hardware equivalent of ASLR (Address Space Layout Randomization), making precise timing attacks extremely difficult since the processor’s execution state is different on every single boot.
If software exploitation was effectively impossible, the only path forward was a physical hardware attack — and that’s exactly what Gaasedelen pursued.
How the Bliss Hack Works
Gaasedelen began his research in early 2024, operating completely blind with no datasheets, no debug output, and no prior experience performing hardware glitches.
Step 1 — Getting a foothold with power analysis
By placing a shunt resistor on the SOC power rails and removing surface-mounted capacitors from the board to reduce noise, Gaasedelen used Differential Power Analysis (DPA) to map the electrical signatures of the boot process. He isolated the North Bridge core rail as the power source for the security processor and began to make out structural patterns in the boot sequence on his oscilloscope.
Step 2 — Reanimating the postcodes
About 2,000 instructions into boot, the system initializes its GPIO pins and checks eFuses to determine whether diagnostic postcodes should be enabled. Gaasedelen used Crowbar Voltage Glitching — briefly pulling the North Bridge rail to ground for roughly 100–200 nanoseconds — to corrupt this initialization and trick the system into outputting postcodes it was supposed to keep silent. This gave him a real-time digital map of the boot ROM’s execution process.
Step 3 — Building a timing anchor
To glitch with enough precision to defeat the randomized stalls, Gaasedelen built a custom analog side-channel monitoring the eFuse read pulses — tiny ~50mV dips that occur during pre-boot. By amplifying these into sharp 3.3V digital pulses, he created a timing anchor accurate to within 175 nanoseconds, triggering his glitch exactly 268 microseconds after the pre-boot eFuses were read.
Step 4 — The Double Glitch
The “Bliss” exploit is a double glitch — two precisely timed voltage drops in a single boot cycle:
- Glitch 1 (MPU Bypass): The first drop hits as the processor loops through configuring its 12 Memory Protection Unit (MPU) memory regions. The glitch causes the loop to exit prematurely, skipping the instruction that formally enables the MPU. With the MPU disabled, the hardware “User Jails” that would normally confine any compromised code collapse entirely — the processor now has global Read/Write/Execute access.
- Glitch 2 (PC Hijack): Moments later, the second glitch targets the memcopy operation as the system reads the SP1 bootloader header from eMMC. Because the MPU is now disabled, this glitch corrupts the final
popinstruction in the memcopy routine, causing CPU registers — loaded with Gaasedelen’s custom patterned data — to redirect the Program Counter to his unsigned shellcode. The shellcode then corrupts saved Supervisor registers and fires a Supervisor Call, hijacking execution into Supervisor Mode.
Finding the exact timing for the second glitch after the MPU was disabled required millions of automated reboots — a process so intensive it burned out multiple commercial eMMC chips, forcing Gaasedelen to switch to industrial-grade NAND flash on his test boards.
Glitch timing: In Gaasedelen’s research environment, a successful boot currently lands within a range of roughly a minute to 30 minutes. He believes that with further community refinement of the glitch parameters, successful attempts could be brought down to just a few seconds.
What Hardware Do You Need?
Despite the complexity of discovering the exploit, executing it requires surprisingly minimal hardware. The sprawling wires seen in Gaasedelen’s research photos were for building side-channel introspection tools — not requirements for running the hack itself.
To execute Bliss, you theoretically need:
- A Raspberry Pi Pico, Teensy, or similar microcontroller
- 3–4 wires soldered to the motherboard (eFuse channel for timing, GPIO pin, eMMC DAT0 anchor)
- A basic MOSFET setup to pull the North Bridge core rail to ground
- Removal of a few specific SMD capacitors on the underside of the board
Gaasedelen also used AI extensively over two years to build custom Boot ROM emulators and simulate attacks without needing large arrays of physical test hardware.
What This Unlocks
Once Supervisor execution is achieved during SP0 — before any of Microsoft’s cryptographic key transformations or code revocation checks have run — the compromise is total:
- Full eFuse dump — All cryptographic keys baked into the hardware can be extracted
- Full boot stage decryption — SP1, SP2, 2BL, and full firmware have been decrypted
- CCP oracle access — The Cryptographic Co-Processor can decrypt any game, app, firmware update, or DLC — past, present, and future
- Unsigned code execution at every level — PSP, SCP, Hypervisor, HostOS, GameOS, and SystemOS
Because this is a physical attack against the 28nm silicon boot ROM, it is impossible for Microsoft to patch via any software update.
Game Preservation
This is arguably the most significant long-term impact of the hack. The Xbox One was the first major home console to go all-in on mandatory internet connectivity and digital DRM at launch — a large portion of its library exists only as digital releases with server-dependent DRM. When Microsoft’s servers eventually go offline, those games are gone unless preserved now.
With full CCP oracle access, every Xbox One game, DLC pack, patch, and system software update can be decrypted and archived. Gaasedelen explicitly acknowledged that he no longer plays games and has no interest in piracy, but that game preservation must be carried out by others who care about the library. This hack gives the preservation community the tools to do exactly that.
Repairability
Three specific repair scenarios now become possible:
Unbricking NANDs — Consoles with corrupted firmware, previously considered permanent paperweights, can now be fully restored and reprogrammed.
eMMC replacement — As internal eMMC chips die from age and wear, this exploit allows clean replacements and DIY upgrade paths, dramatically extending console lifespan.
Optical drive decoupling — Xbox One disc drives are cryptographically paired to their motherboards, making drive swaps for repairs a nightmare. The Bliss hack allows drives to be decoupled and swapped freely, or replaced with optical drive emulators.
Who Is Affected — and Who Isn't
Affected: Original 2013 Xbox One “Fat” units. Year 1 “Zorro” SoCs had hardware anti-glitching monitors turned off. Fall 2014 hardware revisions (-002 silicon) may be harder to glitch, but Gaasedelen believes the technique can be adapted to all Fat Xbox One consoles.
Not yet affected: The Xbox One S, Xbox One X, Xbox Series S, and Xbox Series X all feature hardened boot ROMs with active voltage glitch monitors and a dual-core security architecture separating the reset processor from the security processor. Gaasedelen has laid down a blueprint he believes is applicable to these platforms, but has no current plans to pursue them himself.
What This Doesn't Mean
Where We Stand
For 12 years, the Xbox One stood as one of the most secure consumer electronics products ever built. That era is now over. The security research community has everything it needs to fully reverse-engineer the platform — preserving its software library, extending the life of aging hardware, and opening the door for future homebrew development.
The road from Gaasedelen’s lab to a polished, accessible homebrew scene is still long. But the foundation has been laid, and the Xbox One preservation era can officially begin.
