This is the way we used to be able to run unsigned code. Glitching here is basically the process of triggering processor bugs by electronical means. On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and 'glitching'. 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 current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them. 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. 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. 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.ĬB 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.īasically, CD will load a base kernel from NAND, patch it and run it. A truly random value that comes from the hardware random number generator the processor embeds.The crypto is different each boot because it is seeded at least from: From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The processor starts running code from ROM (1bl), which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).ĬB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. 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.

Xbox 360 rgh console ip grabber