RGH

The steps on this page are considered risky for your console, as there is a chance you can brick it. Please have someone else mod your console if you are not experienced in soldering!

Reset Glitch Hack (RGH) is a hardware modification which allows you to run unsigned code, mods, game backups, and homebrew. The hack relies on a vulnerability in the hardware found by GliGli that is triggered by sending a reset pulse to the processor at a specific moment, resulting in a power glitch that causes a bootloader hash check to return "valid" no matter what you have flashed in place of the stock bootloader. The timing of when and how long the pulse should be sent is dependent on the console and it may take some tweaking until it "glitches" and boots.

Technical writeups on the Reset Glitch Hack exploit include the original RGH1/RGH2 method by GliGli, a logic analyser analysis of the Muffin/Mufas & S-RGH methods by kooscode, & "Xbox 360 security in details: the long way to RGH3" by Alexy Shalpegin, also known as 15432 (the creator of this exploit method)

The RGH variants are as follows:

• RGH1 is compatible with Phat consoles on dashboard 14699 or lower. It uses CPU_PLL_BYPASS to slow down the CPU by 128x in order to precisely power glitch during a hash check on a bootloader.
• RGH2 is for Slims (but also works for Non-Xenon Phats), which uses I2C slowdown instead of PLL slowdown, and works on any dashboard. However, it is considered more difficult to tune, and less consistent.
  • RGH2+ is the same as RGH2, except that the slowdown is sent by the southbridge, instead of the glitch chip. The glitch chip asserts a remapped GPIO pin to tell the southbridge when to send slowdown/speedup. It is exclusive to some Team Xecuter chips such as the CR4XL.
• RGH1.2 combines RGH1-like PLL slowdown with Glitch2 images to allow reliable glitching of Falcon/Jasper consoles with split CB (post 14699 kernel) and works on any dashboard.
  • RGH1.2 V2 ports this hack to Slim consoles, as well as fixing a few issues on Jaspers. It is also tuned better than the original RGH 1, thus being preferrable.
• S-RGH (Speeded-Up RGH) is a tweaked and better version of RGH2, which is far more consistent and quick.
  • Project Muffin is similar to S-RGH, but i2C slowdown is handled by the south bridge instead of the glitch chip. It is not recommended, as it is essentially a less consistent method of glitching and does not boot as fast or consistently as S-RGH or Mufas.
  • Project Mufas is essentially a significantly tweaked and better version of Muffin to have more optimized and more reliable glitching.
• EXT_CLK is similar to RGH 1.2, but uses the EXT_CLK_EN point instead of CPU_PLL_BYPASS to slow the CPU by roughly 10.6x. It is the best method for Xenon and Zephyr boards that have PLL-crash issues.
• RGH3 is the newest RGH variant, and the first to work without a glitch chip by using the SMC in the south bridge to do the glitching instead. Works with Falcon/Jasper Phats and Slims, however it appears to be more reliable with Slims.

Requirements

Below are the minimum requirements to RGH your Xbox 360. It’s recommended to read ahead and choose the NAND reading method and glitch chip specific wiring method that’s right for you, as you will need a NAND programmer and potentially more equipment depending on which methods you choose.

1. Be experienced in soldering. The Xbox 360 is not a good place to learn to solder. Regardless of which reading method you choose, you will need a soldering iron, solder, flux, and 28 AWG or 30 AWG wire (Solid core preferred). Specific recommendatons can be found on this page.
2. Determine your motherboard model. All models are compatible except the Barracuda (Winchester) motherboard. You can use Octal’s Identification Wizard or use the methods mentioned on the Getting Started page to determine your model .
   • Corona: Determine if 16 MB or 4 GB NAND model by turning on the console, navigating to System Settings > Storage, and checking whether the onboard storage unit is 16MB or 4GB. Also determine if you need to buy a postfix adapter using this diagram.
3. Use the recommended exploit chart to determine what RGH version is best for your console.

Recommended RGH/JTAG methods

The below chart highlights the recommended hack to use on each console. Exploit Chart has a more detailed chart that shows many more RGH methods.

¹ Opus is just Falcon without HDMI, so they are grouped togeather.

² Must check CB via NAND dump to see if it is JTAGable. Most - but not all - consoles under 7371 and some on 7371 have an unpatched CB. This mainly effects Jasper systems, as some were manufactured with a patched CB when brand new.

³ Requires scraping solder mask off of a tiny point (more difficult). S-RGH is a viable alternative that has easier soldering.

⁴ Most Tonasket consoles are more commonly known as Jaspers with Kronos GPUs. RGH methods are the same, but are never JTAG exploitable.

RGH Methods

RGH1

• Historical
• Slowdown method: PLL bypass
• Glitch image type: Glitch1
• Targets phat consoles with single CBs (dashboards 14699 and earlier)

RGH1.2

• Modern
• Slowdown method: PLL bypass
• Glitch image type: Glitch2
• Targets both phat and slim consoles using split CBs
• Instaboots Falcons and slims, tends to have issues on Jaspers

RGH2

• Historical
• Slowdown method: I2C
• Glitch image type: Glitch2
• Primarily targets slim consoles
• Uses I2C slowdown, as the CPU_PLL_BYPASS test point wasn't known about at the time

S-RGH

• Modern when including the most recent timing files.
• Slowdown method: I2C
• Glitch image type: Glitch2
• "Sped-up RGH" which significantly improves RGH2 boot times. It can also work as a viable alternative for slims where the PLL bypass point can't be accessed.

Project Mufas

• Modern
• Slowdown method: I2C, controlled via the SMC
• Glitch image type: Glitch2
• Basically RGH2/S-RGH, but the SMC is used to apply or remove the I2C slowdown instead of the glitch chip. It can also work as a viable alternative for slims where the PLL bypass point can't be accessed.
• Open source and significantly improved version of Project Muffin

EXT_CLK

• Modern
• Slowdown method: CPU_EXT_CLK_EN
• Glitch image type: Glitch2
• Currently the only stable glitching method for Xenon and Zephyr boards

RGH3

• Modern
• Slowdown method: PLL bypass + I2C
• Glitch image type: Glitch2 variant using a modified CB_B boot chain (intermediate stage called CB_X that loads the patched CB_B)
• Combines PLL bypass and I2C slowdown to allow the SMC to glitch the CPU - no glitch chip required
• Instaboots Trinity and Corona boards
• Typically boots Falcons and Jaspers within 10 seconds but has problems as the timing is a lot more precise and the SMC can't reliably time the reset glitch

Slowdown methods

The reset glitch pulse needs to be sent to the CPU at a specific moment, or the CPU will fail to glitch or crash soon after. As such, the CPU is usually slowed down before the glitch pulse is sent.

PLL bypass

• Used by: RGH1, RGH1.2, RGH3

The CPU contains a phase-locked loop (PLL) that essentially acts as the CPU's internal clock multiplier. The CPU receives an external 100 MHz clock, which is then multiplied by 32 to get the 3200 MHz core clock.

The PLL likely has a reference oscillator which it uses for generating the clock. By placing the PLL into bypass mode, the PLL will output this reference clock to the CPU, thus slowing down code execution by a significant margin. On Waternoose and Loki CPUs, this is approximately a 128x slowdown; on Veije CGPUs this slowdown is 640x.

I2C

• Used by: RGH2, S-RGH, Project Mufas, RGH3

The CPU receives the 100 MHz base clock from an external clock generator. On most systems, this is the HANA (Zephyr, Falcon, Jasper, Tonkaset and Trinity) or the KSB (Corona and Barracuda).

The clock generators are accessible over I2C, a simple but tried-and-true serial bus. Several registers directly control the parameters used to generate the 100 MHz clock. By writing other values, it's possible to substitute a much lower base clock to the CPU, thereby slowing it down.

The issue with I2C is that the SMC program may also be using the I2C bus at the same time as the glitch chip, and if both the SMC and glitch chip try to send messages on the bus at the same time, there is a chance that the system will hang or an RRoD will result. Project Muffin and Mufas work around this issue by having the glitch chip signal to the SMC when it's time to apply the slowdown.

I2C slowdown is not possible on Xenon and Elpis boards as they instead use the Cypress CY28517ZXC, which can only have its clock outputs toggled on or off.

CPU_EXT_CLK_EN

• Used by: EXT_CLK

The CPU's internal clock source can also be placed into external clock mode. This switches the CPU's base clock speed from the PLL to a clock source derived from the CPU's core clock, slowing it down by approximately 11x.

This slowdown method is used for EXT_CLK, and is an alternative, but far less precise way of slowing down the CPU. It is only used because the Waternoose CPU used on Xenon, Zephyr and Elpis boards has instability issues when PLL bypass mode is used.

It is not possible to combine PLL bypass and external clock mode. If both CPU_PLL_BYPASS and CPU_EXT_CLK_EN are asserted at the same time, PLL bypass will be ignored and external clock mode will be enabled instead.

Comparison

Using a Glitch2 image: