At RE//verse 2026, Markus “doom” Gaasedelen presented a significant hardware security talk detailing a successful attack against the Xbox One boot ROM. The boot ROM has long been considered invulnerable as it constitutes the console’s hardware root of trust. According to Microsoft’s security model, the integrity of all higher-level components depends on the boot ROM; if it is compromised, the entire platform’s security is undermined.
Gaasedelen’s research demonstrated that this assumption is incorrect. Utilizing a carefully engineered double-glitch attack termed Bliss, supervisor-mode code execution was achieved within the Xbox One boot ROM. This capability enabled decryption, modification, and execution of subsequent boot stages, ultimately granting control over the entire platform.
Significance of the Boot ROM
The subject of the attack was the original 2013 “fat” Xbox One. Its system-on-chip, co-designed by Microsoft and AMD, incorporates the Platform Security Processor (PSP), an ARM Cortex-R4 core responsible for early secure boot functions. Microsoft’s security architecture relies on key principles including compartmentalization, virtualization, revocation, and a robust chain of trust. Central to this chain is the boot ROM, previously characterized as the single point of no recovery.
The boot ROM is compact yet heavily protected, approximately 64 KB in size with around 19 KB of executable code written in Thumb-2. It executes primarily in a linear, one-shot manner and employs error-correcting code (ECC) protection on every fetch. Additionally, it implements extensive integrity checks and dual-signature verification, utilizing both RSA and ECC before permitting execution of subsequent boot stages.
Furthermore, Microsoft implemented practical hardening measures. The platform lacked public debug interfaces, UART, JTAG, reset pins, and postcodes were fused off. The ROM incorporated 37 randomized stalls distributed throughout execution to introduce timing uncertainty, alongside security checkpoints that maintained a running hash and ECC validation. Potentially vulnerable logic was isolated within user-mode “jails” enforced by a 12-region Memory Protection Unit (MPU). Collectively, these features aimed to deter both software and physical attacks.
Initial Conditions and Constraints
A notable challenge in the project was the limited initial visibility. No vendor documentation, developer boards, or debug hooks were available. Consequently, the attack commenced through traditional methods: probing power rails, tracing signals, and identifying patterns within noise.
Initial power traces on the 1.8 V rail yielded limited information. Over time, several useful signals were identified. A Power-OK line offered a rough indication of the boot window but was too jittery for precise triggering. More valuable data originated from I2C diagnostics output, revealing information such as SoC ID, thermal and voltage indicators, violation flags, and fatal error codes. Despite postcodes being fused off, these error codes continued to leak useful system state.
The North Bridge core rail was identified as the probable PSP rail, leading to the construction of a shunt-based power side channel combined with a low-noise supply. This setup provided enhanced insight into processor activity during reset. Periodic power features corresponding to RNG seeding events, likely generated by ring oscillators firing every millisecond, were observed. These features served as valuable timing anchors for locating boot ROM cryptographic and RNG initialization routines.
This approach was critical because the ROM’s 37 randomized stalls rendered fixed-delay glitching unreliable. Therefore, timing required anchoring to actual signals rather than estimations based solely on reset.
Enhancing Console Visibility
A significant breakthrough occurred upon realizing that the boot ROM configured GPIO for postcode output early in the process, although fuses typically prevented visibility. By applying a brief crowbar voltage glitch, approximately 100 to 200 nanoseconds in duration, on the North Bridge core rail at a precise moment, transient postcode visibility was achieved.
This success fundamentally altered the project by providing fine-grained visibility into the ROM’s execution progress for the first time. This enabled correlation of glitches with specific execution stages rather than operating with limited information.
Exploiting memcpy as an Attack Surface
Improved visibility allowed focus on the transfer of the SP1 header, the initial external bootloader header approximately 900 bytes in length. This header is read from eMMC via MMC and PCIe into PSP memory in 64-byte bursts. The copy operation presented a notable fault injection window.
Memcpy-style routines are attractive targets for fault injection as they transfer attacker-controlled data through registers. A precisely timed glitch can corrupt control flow, causing the routine to restore or branch using values influenced by attacker-controlled data.
Patterned bytes were flashed into eMMC while monitoring fatal error codes on the I2C bus. ARM abort handlers on this platform encode IFAR and IFSR into a 32-bit code, allowing crashes to indicate execution faults. During glitch sweeps, prefetch aborts with top-byte patterns matching the injected data were observed, confirming program counter hijacking. A glitch skipped a final pop instruction in the memcpy routine, resulting in restoration of attacker-controlled register state and execution branching to a pattern such as 0x58585858.
This represented a significant advancement; however, it remained insufficient for full compromise.
Memory Protection Unit as a Remaining Barrier
Even after achieving the first hijack, the attack remained trapped inside Microsoft’s containment model. The boot ROM uses around 13 security checkpoints to report progress, maintain a running hash, and verify ECC state. Executing out of order typically causes an immediate reset. On top of that, the risky logic was running in a user-mode jail enforced by the MPU, which sharply limited the accessible regions and reduced the available gadgets.
Return-oriented programming (ROP) was demonstrated within the jail, including emission of 0x41414141 on I2C; however, this did not confer full control. Complete compromise of the root of trust required disabling the MPU.
Second Glitch: Disrupting MPU Initialization
The MPU is configured early during boot, with its 12 memory regions initialized in a loop prior to enabling the MPU. Attacking this sequence required a stable timing reference preceding the availability of GPIO and postcodes.
A novel side channel was employed using the efuse rail. Inserting a small shunt on the efuse sense and burn rail converted minor voltage dips, approximately 50 mV, into clean digital timing pulses. These pulses revealed pre-boot efuse reads associated with lockdown, entitlements, cryptographic key sensing, and revocation checks. Crucially, they provided a reliable timing marker for inducing a glitch during MPU initialization.
Approximately 268 microseconds elapsed between early efuse reads and GPIO initialization, with jitter limited to approximately 175 nanoseconds. This precision was sufficient to target the MPU setup window.
The glitch successfully exited the MPU region-configuration loop prematurely, and analysis confirmed that MPU enablement was also bypassed. With the MPU disabled, the separation between user and supervisor memory effectively collapsed, allowing code in the previously constrained environment to directly manipulate privileged memory.
Bliss: Integration of Dual Faults for Complete Compromise
The final exploit, called Bliss, combined the The final exploit, termed Bliss, integrated the two glitches into a single attack chain.PU initialization and enablement. That left the boot ROM without meaningful memory protection, making the environment effectively RWX and allowing user-controlled code to interfere with supervisor memory.
The subsequent glitch, applied during the SP1 header memcpy, hijacked program flow and redirected execution to attacker-controlled bytes previously loaded into secure SRAM. This exploit corrupted saved supervisor registers and resumed execution in supervisor mode.
The outcome was supervisor-mode code execution within the Xbox One boot ROM, occurring prior to irreversible key derivations and revocation checks that secure the platform.
The demonstration included actions previously considered impossible on a retail console: toggling GPIO directly from the ROM, repurposing postcode pins into a UART, dumping efuses, and decrypting SP1, SP2, 2BL, and SCP firmware. Practically, this conferred full control over the PSP, the secure coprocessor, and the downstream x86 environment, encompassing the hypervisor, operating systems, and game OS.
Significance of the Attack
This attack is significant because it targets immutable silicon. Software updates cannot remediate boot ROM vulnerabilities post-manufacture. Consequently, if the exploit is effective on a specific hardware revision, it remains permanently exploitable.
This vulnerability enables extensive capabilities. An attacker with such access could decrypt, modify, and execute unsigned code at all system layers. The console’s cryptographic hardware could be exploited to decrypt games, firmware, and protected content across generations. For preservationists, this may facilitate archiving otherwise inaccessible titles and firmware. Repair communities might also benefit by enabling unpairing or restoration of hardware components such as NAND or failing optical drives.
The affected hardware includes the original 2013 Xbox One SoCs. Later 2014 “fat” revisions reportedly incorporated on-die anti-glitch monitors, including voltage and clock sensors, although the technique may remain applicable with sufficient refinement. The Xbox One S and One X were not the primary focus, with noted architectural evolutions. The Series S and Series X were not examined in this research.
Potential for Modchip Development
Despite the research setup employing extensive probes and instrumentation, a practical implementation may be considerably simpler. A streamlined configuration could require only a few connections, such as an efuse side-channel line, one GPIO, DAT0, and a crowbar on the North Bridge core rail. Removal of capacitors beneath the APU facilitated laboratory testing but may not be essential in all implementations.
This does not imply that a public mod solution is imminent. The work is explicitly framed as technical disclosure and preservation-oriented research rather than a commercial or public modding initiative.
Contemporary Insights in Hardware Security
A key insight from the research is that the exploit was not a fortuitous glitch but the product of disciplined reverse engineering, side-channel development, emulation, and iterative experimentation. AI-assisted tools were employed to construct a boot ROM emulator, stub peripherals and MMIO, generate visualizations, and evaluate fault models. The research incurred significant hardware costs, including multiple lost boards and substantial wear on eMMC devices due to extensive logging and repeated boot attempts.
Ultimately, the principal lesson is that even the most hardened root of trust can fail when hardware-level fault injection is applied with sufficient precision. The Xbox One boot ROM was intended as a final line of defense; the Bliss exploit demonstrated that this boundary can be breached.
Conclusion
The RE//verse 2026 presentation by Markus “doom” Gaasedelen underscores that “unpatchable” does not equate to “unbreakable.” By combining innovative side-channel analysis with two precisely timed voltage glitches, full compromise of the Xbox One’s root of trust was demonstrated. This represents a significant advancement in hardware security research and is likely to influence future approaches to console security, secure boot design, and digital preservation.