Free60-Wiki

The Xbox 360 reset glitch hack

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:

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:

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:

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:

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:

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:

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 !

Caveats

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

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.

Finding the right timing

Getting memcmp POST length in ticks

First step is to know how long the memcmp POST will last while slowed down. No reset pulse should be sent for this. Using hardware that can read the POST bus and measure time in a precise way, measure the time between memcmp POST start and ‘hash compare failed’ final POST (eg on fats, between POST 39 and POST AD) with the next bootloader failing hash check.

An ARM7 based Olimex LPC-H2148 was used for this task.

It could look like that:

for(;;) {   post = post_read();   if (post == prev_post) then continue;

  if(post == MEMCMP_POST)   {     t_start = get_tick();

    while( post_read() == MEMCMP_POST );          memcmp_post_length=get_tick()-t_start;

    print(memcmp_post_length);   }

  prev_post=post; }

Make sure you note memcmp post length ;)

Using random timing over the full POST length

Now you need the hardware to send a reset pulse after a random amount of time in memcmp POST, but no more than previously found memcmp POST length.

It could look like that:

for(;;) {   post = read_post();   if (post == prev_post) then continue;

  if(post == MEMCMP_POST)   {     t_start = get_tick();     t_rand = rand() % MEMCMP_POST_LENGTH;

    while( get_tick()< t_start+t_rand );

    ppc_send_reset_pulse();

    print(t_rand);   }

  prev_post=post; }

Using a hacked smc that reboots infinitely it will take a good amount of time, but it should end up glitching properly.

Make sure you note the timing that glitched ;)

Refining the timing, accounting for bell-like curve

So now we have one timing that glitches, but we don’t know if it’s really the ‘sweet spot’ or if we were just lucky. What needs to be done now is to get the timing of some more successes, I think it’s safe to use a smaller random range around previously found glitch timing. my get_tick() function runs at 60Mhz, I found it was safe to make the range -+50 ticks around previously found glitch timing

It could look like that:

for(;;) {   post = read_post();   if (post == prev_post) then continue;

  if(post == MEMCMP_POST)   {     t_start = get_tick();     t_rand = PREV_GLITCH_TIMING - 50 + (rand() % 100);

    while( get_tick()< t_start+t_rand );

    ppc_send_reset_pulse();

    print(t_rand);   }

  prev_post=post; }

You’ll need the timing of at least 20-30 successes. Averaging those timings should give you the sweet spot (aka final timing), because empirically we found that success rate vs timing is a bell-like curve.

Make sure … you got it ;)

PS: Those pseudo-code examples don’t show the slowdown code for the sake of clarity.

Conclusion

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.

HowTo (for slims)

Required Software and Hardware

Prerequisites

Software

Hardware

Dumping NAND

XBOX360_Slim_NandPro_LPCH2148_PIC18F2455_Diagram.png

nandpro usb : -r16 nanddumpname.bin

fc /b  nanddumpname.bin nanddumpname2.bin 

H-Slim6.png

You should see something like FC : No difference found. If the two dumps don’t match, do a new dump and check again.

Installation of Python and Python Crypto

H-Slim7.png H-Slim8.png H-Slim9.png H-Slim10.png

H-Slim11.png H-Slim12.png H-Slim13.png

To enable python in windows’ command prompt, we will have to modify the environment variables .

H-Slim14.png

H-Slim15.png

H-Slim16.png

PYTHONPATH %PYTHONPATH%;C:\Python2.7 ;

H-Slim17.png

Creating the Hackimage

H-Slim18.png

python common\imgbuild\build.py nanddumpname.bin common\cdxell\CD common\xell\xell-gggggg.bin

H-Slim19.png

You should see the following

H-Slim20.png

The file image_00000000.ecc is located in the output folder now.

H-Slim21.png

nandpro usb : +w16 image_00000000.ecc

/!\ Pay attention that you have to use the +w16 switch and not the -w16 one /!\

H-Slim22.png

The flashed file has a size of 50 blocks so you should see 004F when the flashing is done.

Programming the CPLD

Power your CPLD with 3.3V on pin 20 and GND on pin 21. There are many solution to do this … here are some of them :

H-Slim23.gif H-Slim24.png

(If you don’t have one, you can use GliGli’s schematic to build a LPT JTAG Programmer)

H-Slim25.png H-Slim26.png

(You have to setup the compatibility mode only if your Programmer does not get detected right away)

H-Slim27.png H-Slim28.png H-Slim29.png H-Slim30.png H-Slim31.png H-Slim32.png H-Slim33.png H-Slim34.png H-Slim35.png H-Slim36.png H-Slim37.png

Wiring

H-Slim38.png H-Slim39.png

H-Slim40.png

H-Slim41.png H-Slim42.png H-Slim43.png H-Slim44.png H-Slim45.png

ENJOY

H-Slim46.png

CREDITS / THANKS

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

Category:Xbox360 System Software Category:Xbox360_Hardware