PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

August 28, 2011 // 1:59 pm - Today XBox 360 hackers GliGli and Tiros have released an XBox 360 Reset Glitch Hack for both the Fat and Slim models, which includes source code and a demo video below courtesy of Razkar2011 via YouTube.

Download: XBox 360 Reset Glitch Hack v1.0 / GliGli Tools Source Code‎ / XBox 360 Reset Glitch Hack Guide / ECC Glitch Generator v1.0 / Xell Reloaded 2Stage 28-08-11 / GIT / Wiki

To quote: The XBox 360 reset glitch hack - Introduction / some important facts: tmbinc said it himself, software based approaches of running unsigned code on the 360 mostly don't work, it was designed to be secure from a software point of view.

The processor starts running code from ROM (1bl) , which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).

CB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The crypto is different each boot because it is seeded at least from:

  • A hash of the entire fuseset.
  • The timebase counter value.
  • A truly random value that comes from the hardware random number generator the processor embeds. on fats, that RNG could be electronically deactivated, but there's a check for "apparent randomness" (merely a count of 1 bits) in CB, it just waits for a seemingly proper random number.

CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it.

Basically, CD will load a base kernel from NAND, patch it and run it.

That kernel contains a small privileged piece of code (hypervisor), when the console runs, this is the only code that would have enough rights to run unsigned code. In kernel versions 4532/4548, a critical flaw in it appeared, and all known 360 hacks needed to run one of those kernels and exploit that flaw to run unsigned code. On current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them. The hypervisor is a relatively small piece of code to check for flaws and apparently no newer ones has any flaws that could allow running unsigned code.

On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and "glitching". Glitching here is basically the process of triggering processor bugs by electronical means. This is the way we used to be able to run unsigned code.

The reset glitch in a few words

We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.

Details for the fat hack

On fats, the bootloader we glitch is CB, so we can run the CD we want.

cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted.

So it goes like that:

  • We assert CPU_PLL_BYPASS around POST code 36 (hex).
  • We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
  • When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
  • We wait some time and then we deassert CPU_PLL_BYPASS.
  • The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.

The NAND contains a zero-paired CB, our payload in a custom CD, and a modified SMC image.
A glitch being unreliable by nature, we use a modified SMC image that reboots infinitely (ie stock images reboot 5 times and then go RROD) until the console has booted properly. In most cases, the glitch succeeds in less than 30 seconds from power on that way.

Details for the slim hack

The bootloader we glitch is CB_A, so we can run the CB_B we want.

On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS. Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.

We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs. Apparently those registers are written by the SMC through an I2C bus.
I2C bus can be freely accessed, it's even available on a header (J2C3).

So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus

So it goes like that:

  • We send an i2c command to the HANA to slow down the CPU at POST code D8 .
  • We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
  • When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
  • We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
  • The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.

When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:

  • Always activate zero-paired mode, so that we can use a modified SMC image.
  • Don't decrypt CD, instead expect a plaintext CD in NAND.
  • Don't stop the boot process if CD hash isn't good.

CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
RC4 is basically: crypted = plaintext xor pseudo-random-keystream

So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:

  • guessed-pseudo-random-keystream = crypted xor plaintext
  • new-crypted = guessed-pseudo-random-keystream xor plaintext-patch

You could think there's a chicken and egg problem, how did we get plaintext in the first place? Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!

The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image. The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.

Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !


Nothing is ever perfect, so there are a few caveats to that hack:

  • Even in the glitch we found is pretty reliable (25% success rate per try on average), it can take up to a few minutes to boot to unsigned code.
  • That success rate seems to depend on something like the hash of the modified bootloader we want to run (CD for fats and CB_B for slims).
  • It requires precise and fast hardware to be able to send the reset pulse.

Our current implementation

We used a Xilinx CoolRunner II CPLD (xc2c64a) board, because it's fast, precise, updatable, cheap and can work with 2 different voltage levels at the same time. We use the 48Mhz standby clock from the 360 for the glitch counter. For the slim hack, the counter even runs at 96Mhz (incremented on rising and falling edges of clock) The cpld code is written in VHDL. We need it to be aware of the current POST code, our first implementations used the whole 8 bits POST port for this, but we are now able to detect the changes of only 1 POST bit, making wiring easier.


We tried not to include any MS copyrighted code in the released hack tools. The purpose of this hack is to run Xell and other free software, I (GliGli) did NOT do it to promote piracy or anything related, I just want to be able to do whatever I want with the hardware I bought, including running my own native code on it.


GliGli, Tiros: Reverse engineering and hack development.
cOz: Reverse engineering, beta testing.
Razkar, tuxuser: beta testing.
cjak, Redline99, SeventhSon, tmbinc, anyone I forgot... : Prior reverse engineering and/or hacking work on the 360.

Video: XBox 360 Reset Glitch Hack on Fat and Slim Models Arrives

Follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 CFW forums for the latest PlayStation 3 scene and PS4 Hacks & JailBreak updates with PlayStation 4 homebrew.

#42 - moja - October 23, 2011 // 12:22 am
moja's Avatar
Yup, they've released nand image builders to allow homebrew like Freestyledash and enabling backups from the hard drive now. All 360s can be jtagged now (except the new ones coming out without the Hana chip).

#41 - cfwprophet - October 10, 2011 // 11:49 pm
cfwprophet's Avatar
Thats so much great. Beside the XGDR3 we now also can hack the hardware of all x360. This will be a great christmas.

#40 - buffaoo monty - October 2, 2011 // 9:02 am
buffaoo monty's Avatar
Quote Originally Posted by HeyManHRU View Post
If I get a 360 and hack it will it be safe for me to play on XBL?

Nothing is ever safe, but as long as check everything with abgx & its all clear then you'll be as safe as can be expected. I had a modded xbox for three years & didn't a ban. But friend who burnt me a game got banned so checked it & it failed all security checks, then i got rrod so bought new one & been legit ever since!

But I am gonna be buying the kit again soon, its all cheaper & more user friendly now.

#39 - HeyManHRU - October 2, 2011 // 5:39 am
HeyManHRU's Avatar
If I get a 360 and hack it will it be safe for me to play on XBL?

Also thanks for the news boss.

#38 - PS4 News - October 2, 2011 // 5:36 am
PS4 News's Avatar
This is the console news section, where we've posted non-PS3 (360, Wii, etc) news for the last 4+ years.

#37 - ZerotakerZX - October 2, 2011 // 5:34 am
ZerotakerZX's Avatar
Wrong site, I s'posse.

#36 - NTA - October 2, 2011 // 2:34 am
NTA's Avatar
Lol I thought I saw PS3 in the title... I'm losing it

It's incredible how people find out how to do these kinds of things...

#35 - elser1 - October 2, 2011 // 1:11 am
elser1's Avatar
thats kool.. thanks for the news boss.. i gotta get an xbox now.

#34 - PS4 News - October 2, 2011 // 12:57 am
PS4 News's Avatar
Just over a month back we reported on an XBox 360 Reset Glitch Hack for Fat and Slim models followed by news that XGD3 has been defeated, and today XBox 360 scene release group RRoD has began releasing the first XGD3 iSO files alongside a guide on how to burn them for end-users.

For those curious, current XGD3 0800 XBox 360 released from RRoD include:

  • Warhammer_40000_Space_Marine_READNFO_XGD3_0800_USA_RF-XBOX360-RRoD
  • X-Men_Destiny_READNFO_XGD3_0800_USA_RF-XBOX360-RRoD
  • Rise_of_Nightmares_READNFO_XGD3_0800_USA_RF-XBOX360-RRoD
  • Gears_of_War_3_READNFO_XGD3_0800_USA_RF-XBOX360-RRoD

To quote from the Gears_of_War_3_READNFO_XGD3_0800_USA_RF-XBOX360-RRoD release NFO file:


Playable Regions: ALL (REGION-FREE)

SplitVid, SSv2, and verified with abgx360!

RRoD is proud to bring you the very first official XGD3 0800 ISO releases made with c4eva's new 0800 v3.0 ripping fw for BenQ VAD6038 and Lite-On DG-16D2S.

These ISOs are fully compatible with the new LT+ v2.0 for Phats and Slims, are burnable to regular DVD+R DL discs, include full & correct AP2.5 data, and are verified in the abgx360 database. Please refer to the status table on for a breakdown of which drives support LT+ v2.0.

The LT+ v2.0 release for Phat models is imminent, and it was requested that we release these in advance in order to give everyone time to have them downloaded and ready to play for once the fw goes public.

Our thanks and congratulations to c4eva, Team Xecuter/k3rn3l, the JungleFlasher team, Redline99 for Xbox Backup Creator, Seacrest for abgx360, the core testing team, and all the other individuals involved who came together to make this possible!


To end the confusion once and for all, *yes*, original XGD3 discs have a higher linear/track density and therefore a higher physical capacity than XGD2 and regular DVD+R DL media. As a result, XGD3 ISO backups are larger as well.

For XGD3 backup support, c4eva has introduced in LT+ v2.0 the LT-MAX feature, which allows for XGD3 backups to use the maximum possible layerbreak for regular DVD+R DL media, and therefore all of the available space (8,547,991,552 bytes) of a regular DVD+R DL disc.

Since there is still not enough space on a regular DVD+R DL disc to hold the entire XGD3 game partition, not to mention the Layer 1 Video partition, this is not at all recommended as being "safe" for Xbox LIVE.

XGD3 backups will still boot and play fine on LT+ v2.0 as long as the last approximately 1.7% of the game partition does not contain any of the actual game assets, which it usually won't because the end of the game partition is near the inner edge of the disc, and developers will try to keep their game data near the outer edge (middle of the game partition) to maximize read performance.

Another necessary condition to booting and playing XGD3 backups on regular DVD+R DL media is that the kernel or game code itself must not perform any CIV (Content Integrity Verification) checks on any part of this last approximately 1.7% of the game partition (or at least it must not take any action after CIV failures). Even if there are no actual game assets in this area, there is still pseudo-random padding data which can be checked through CIV, and such checks can even be added later to the game code through title updates, or to the kernel through system updates.

Just like XGD2, XGD3 backups still require the correct dashboard version-specific AP2.5 replay data. As they've done previously, MS has the ability to change the DAE.bin by way of a system update, meaning you may need to re-patch/re-burn at some point. The abgx360 application and database will be updated accordingly to support XGD3.


The P2P XGD3 ISO rips that were floating around before this point are for ODDEs and are not compatible as-is with LT+ v2.0. Their PFI, DMI and SS sectors are in the wrong PSN (Physical Sector Number) locations and they are missing the critical AP2.5 replay sector and SS replay table. If you intend to play XGD3 backups on a firmware-flashed 360, it's up to you to make sure you're using proper ISOs made with 0800 v3.0, and to double-check by running them through abgx360 before burning.

Keep in mind that this is the first of several potential disc-based backup solutions for XGD3. As such, it's recommened that all subsequent releases maintain the full ISO size and associated layerbreak (2133520) in the .dvd, which will help to ensure that they will be forward-compatible should any media manufacturers step up with new larger-capacity discs (which will be necessary in order to make XGD3 backups as safe as possible on Xbox LIVE).

The actual layerbreak for XGD3 ISOs is 2133520. However, when burning XGD3 ISOs to regular DVD+R DL, ImgBurn will automatically reposition/limit the layerbreak to 2086912 in accordance with the disc's maximum Layer 0 data zone capacity (2,086,912 [LBA: 0 - 2086911]). The LT-MAX feature in LT+ v2.0 will compensate for this and allow you to play XGD3 backups with this wrong layerbreak, and therefore wrong game partition data PSN locations.

In the case of growisofs as instructed below, in order to avoid errors when burning XGD3 to regular DVD+R DL, you may choose to first truncate the ISO to 8,547,991,552 bytes, and burn using a reduced associated layerbreak of 2086912. This should give you exactly the same end result as if you followed the instructions below for ImgBurn on Windows.


We recommended that you use the latest version of ImgBurn (v2.5.5.0 at the time of writing, downloadable at Older versions may handle this process differently and/or give a different set of errors.

Although it is set by default in ImgBurn, please ensure that under Tools > Settings > Write, you have "Layer Break (For DL Media)" set to "Calculate Optimal".

Please ensure that the layerbreak is set as 2133520 in the .dvd file. If you already have the XGD2 (or other) layerbreak value set in ImgBurn, the .dvd of the XGD3 ISO will override that setting and use the proper layerbreak.

As mentioned above, ImgBurn will automatically reposition/limit the layerbreak to 2086912 when burning to regular DVD+R DL discs.

Please see the included imgburn-xgd3-errors.png image for screenshots of the errors you'll encounter in ImgBurn and what to click on in each dialog that pops up.

Step by Step:

1. Choose "Write image file to disc", and after loading the .dvd file, click "Write".

2. ImgBurn will pop up a notice saying that there is not enough space on the disc to burn the image, and asks if you would like to continue anyway. Click "Yes".

3. Another message might pop up saying that optimal layerbreak position exceeds L0 capacity. Click "Yes".

4. An error will then pop up noting that "Set L0 Data Zone Capacity Failed". Click "Continue".

5. The image will begin writing to the disc.

6. Nearing the end of the write process, ImgBurn will pop up an error at around 97% or 98% (this is what we want -- it's intentional!). Click "Cancel".

7. A notice will then pop up asking if you would like ImgBurn to try and perform the "'Close Track/Session/Disc' functions". Click "Yes".

8. Let the disc finalize, and you're done!


truncate --size=8547991552 xgd3game.iso
growisofs -use-the-force-luke=dao -use-the-force-luke=break:2086912
-dvd-compat -speed=4 -Z /dev/dvd=xgd3game.iso

More PlayStation 3 News...

#33 - PS4 News - September 25, 2011 // 4:10 am
PS4 News's Avatar
For those following, XGD3 was also recently defeated. Below are some details from C4E on IRC:

[2011-09-25 02:52AM UTC] #c4e [c4eva] Successful testing of LT 2.0 with new LT-MAX feature for DVD R DL. XGD3 ixtreme isos playing fine from DVD R DL disc and/or install to HD
[2011-09-25 02:57AM UTC] #c4e [EnigmaFX] does this Mean we can use or regular dual layer media / burners and layer break 1913760? Or has that changed ?
[2011-09-25 02:58AM UTC] #c4e [c4eva] regular DL media, yes!
[2011-09-25 02:59AM UTC] #c4e [supakilla] c4eva is the layer break still the same
[2011-09-25 03:00AM UTC] #c4e [c4eva] more details soon!
[2011-09-25 03:01AM UTC] #c4e [c4eva] normal blanks, normal burner!
[2011-09-25 03:03AM UTC] #c4e [c4eva] XGD3=defeated!
[2011-09-25 03:59AM UTC] #c4e [c4eva] LT Max=Maximum capacity!