Reset Hack Glitch

The 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.

---

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.
-

Nice post bro,keep up the good work and this post will help alot of people out with that