Inside the Xbox 360 RGH hack

In my opinion, the Reset Glitch Hack (RGH) on the Xbox 360 stands as one of the most elegant, and great achievements in the history of console reverse engineering. In this article I will explain in details each phase of the exploit and what is happening under the hood. Notice this is NOT a step-by-step practical tutorial (there are already plenty online). Instead, this article is an explanation of those steps, so if you are curious to fully understand how was possible to mod the xbox360, this article is for you!

Before we start, let’s get the standard legal disclaimer out of the way:

• This article is strictly for educational purposes. Do not use this knowledge to hurt poor consoles.
• I have only ever observed this exploit from a safe, theoretical distance and I have never ever ever actually performed it myself (I may recall a friend of a friend of a friend that did it)
• I hold a deep, unwavering reverence for the flawless, totally-not-sloppy security architectures of massive mega-corporations like Microsoft.
• «PLACEHOLDER FOR OTHER BS»

I hope that this suffices. Now lets start with an overview.

Some History

Launched in 2005, the Xbox 360 was built like a digital fortress, with an innovative secure-boot chain and hypervisor architecture designed to make homebrew impossible. For the first few years, the only available hacks were software exploits that Microsoft quickly patched through system updates.

Then in 2011, French researcher GliGli discovered an hardware vulnerability (called Reset Glitch Hack) baked into the CPU. This new vulnerability was purely hardware related, and completely unpatchable by Microsoft. For the next years, people started to exploit this vulnerability by using external modchips.

After several iterations like RGH1.2 and S-RGH, in late 2021, user 15432 presented the RGH3, a new exploit that skipped external chips entirely by hijacking the console’s internal standby processor. Because the RGH3 is the most complete hack, we will focus on that.

General Overview: The RGH Workflow

The Xbox 360 stores its operating system, bootloaders, and system-specific data (such as the console’s unique Keyvault) inside a physical flash memory chip on the motherboard, known as the NAND. The content of this memory is encrypted with encryption keys that are baked into the CPU and are unique for each console. This means that you cannot just clone nand data to a new console, because it would not be able to decrypt the nand content.

So for the RGH, the first thing to do is to read and dump the encrypted nand content. This is done by soldering an external SPI reader (or rpi-pico) to the motherboard to extract a exact image of this storage. It is extremely important that you make several backups of this file since, if something goes wrong, you can always restore the console with this (console-tailored) image.

Once you have the NAND dump extracted you can feed it into the J-Runner software. This software replaces the console’s factory second-stage bootloaders with XeLL (the Xenon Linux Loader), a bare-metal, open-source bootloader. At the same time, if selecting RGH3 tickbox, the software alters the firmware of the console’s SMC (System Management Controller) (a separate stand-by chip processor) to inject custom glitch-timing loops (more details in the section below). This modified image is then written back to the physical flash chip.

When the console is powered on, the modified SMC code activates. It synchronizes with the motherboard’s clock (The POST Wire) and drops the voltage to the CPU (The RST/PLL Wire) at a precise microsecond to bypass security verification, allowing unsigned XeLL binary to run. This binary is basically another OS similar to when you boot your PC from a usb stick.

Once Booted, the only thing that XeLL does is to sends direct instructions to the CPU to read its internal eFuses, displaying the unencrypted 128-bit CPU Key onto the screen.

With the CPU Key successfully recovered, they are entered to the J-Runner program. The software uses this key to fully decrypt the original NAND backup, extracting the system’s unique serial number and pairing data. It then takes a clean, official Microsoft Dashboard update, strips out its core security restrictions, re-encrypts the package using the console’s specific CPU Key, and generates a final custom image called a XeBuild Image. This new image can be written back to the console. The console is now cured, and you may proceed to install custom Dashboard such as Aurora.

Here is a quick overview of those steps:

+------------------+     +--------------------+     +---------------------+
| 1. Dump NAND     | --> | 2. Patch & Write   | --> | 3. Execute Glitch & |
|    (Raw Backup)  |     |    XeLL image      |     |    Boot XeLL        |
+------------------+     +--------------------+     +---------------------+
                                                               |
+------------------+     +--------------------+                v
| 6. Flash Custom  | <-- | 5. Build XeBuild   | <-- | 4. Read CPU Key     |
|    (Dashboard)   |     |    Custom Image    |     |    From eFuses      |
+------------------+     +--------------------+     +---------------------+

---

The Mechanics of the Glitch

To appreciate why RGH is so remarkable, one must look at how the physical exploit forces the CPU to run unauthorized software.

Voltage Fault Injection Attacks

The Xbox 360 utilizes a secure boot chain overseen by a hardware-level Boot ROM embedded in the CPU. When the console starts up, it runs a memory comparison loop (memcmp) to verify that the digital signature of the next bootloader matches Microsoft’s private RSA keys. If the signature doesn’t match, the CPU panics and halts immediately.

RGH breaks this mechanism via voltage fault injection:

1. Clock Slowdown: To widen the window of opportunity, the modded SMC code or an external modchip forces the motherboard’s clock generator to slow down the CPU’s operating frequency by a factor of 128.
2. The Timing Loop: The SMC counts individual clock cycles from a known hardware trigger (such as traffic on the POST or I2C buses) to track the exact nanosecond the signature check loop begins.
3. The Glitch Pulse: At the precise microsecond the CPU processes the branch instruction determining if the signature check passed or failed, the SMC drops the voltage on the CPU’s reset or PLL lines.
4. The Gate Flip: This intentional electrical instability starves the processor’s logic gates of power for a fraction of a clock cycle. Instead of evaluating the mismatched signature and executing a jump to the “shutdown” subroutine, a logic gate miscalculates and slips directly into the “success” pathway. The CPU is tricked into believing the unsigned code is completely authentic.

Because subtle factors like ambient temperature, wire routing, and silicon variances can shift the exact cycle the CPU processes this data, the glitch can occasionally miss. If it misses, the CPU panics, the SMC detects the failure, instantly triggers a hard reset of the system, and tries the exact sequence again on a brand-new boot loop.

Normal Boot Check:   [Verify Signature] ---> (Invalid) ---> [System Panic/Halt]
Glitched Boot Check: [Verify Signature] --(Voltage Drop)--> [Logic Error: Pass] ---> [Boot Code]

External Modchips vs. RGH3 (Internal Microcode Exploitation)

Historically, older RGH methods (RGH 1, 2, and S-RGH) relied on an external CPLD microchip (like the CoolRunner, Matrix or Ace) to perform a precise timing attack. This chip was listening to the motherboard’s signals and injecting the glitch, but because the timing had to be absolutely perfect, the chip often missed its tiny window of opportunity. Whenever a glitch failed, the CPU would panic and halt, forcing the chip to completely reboot the console to trigger a brand-new boot cycle and try again. This constant cycle of crashing and restarting meant users often had to wait minutes for the console to successfully boot. If you ever had the chance to observe one of those chip modded consoles, you would see a flashing LED on the modchip blinking at every single failed attempt.

RGH3 eliminated external silicon entirely. Instead of an external chip listening for signals, developers patched the firmware of the built-in System Management Controller (SMC) inside the NAND. Because the SMC lives natively on the motherboard architecture, it already has flawless synchronization with the master clock line. Only two basic connection wires are needed:

• The POST Wire: Connects the CPU’s boot status line (POST1) to the SMC’s monitoring point (SMC_POST1). This lets the SMC listen in and know exactly what stage of the boot sequence the CPU is in.

• The RST/PLL Wire: Connects a CPU control line (PLL_BYPASS on Slim models) directly to the SMC’s pulse point (SMC_PLL). This is the line SMC uses to drop the voltage and trigger the glitch loop.

The Patched Hypervisor

As we saw earlier, J-Runner uses the unique CPU key to decrypt, patch, and rebuild a completely custom version of the NAND image. Without this permanently modified system kernel, the console would immediately reject anything that lacks Microsoft’s official digital signature; you wouldn’t even be able to boot custom dashboards like Aurora, because the operating system would still be strictly blocking unauthorized file execution.

To fix this we need J-Runner to patch the nand. The primary target of the XeBuild image is the Hypervisor (HV), the highest privilege level of the Xbox 360 software environment. The Hypervisor acts as a strict ring-0 security layer that polices system memory. XeBuild patches the Hypervisor’s assembly code inside the system RAM to disable three fundamental defense mechanisms:

1. RSA Signature Elimination

The original Hypervisor checks the digital signature of every executable file (.xex) before letting it run. XeBuild modify the signature verification function to return “always pass”. This modification allows the console to load homebrew dashboards, game backups, and emulators flawlessly.

2. Overriding the W^X Memory Policy

To block modern buffer-overflow exploits, the official Hypervisor strictly enforces W^X (Write Xor Execute) memory isolation. A memory segment can be modified (written to), or it can execute instructions, but it can never do both simultaneously. XeBuild modifies the Hypervisor’s page table allocation rules, allowing specific memory spaces to be writable and executable at the same time. This modification is what enables real-time game modding engines, custom plugins, and trainers to run concurrently in the background.

3. Removal of Hardware and Regional Barriers

XeBuild patches the subroutines handling area identifiers (NTSC, PAL, NTSC-J) converting the console into region-free device.

Conclusions

I hope you enjoyed this deep technical article and found it useful for diving into the brilliant engineering behind the Xbox 360 mod.