Xbox 360 Timing Attack

The timing attack is used allow machines with kernel 4552 or higher to downgrade to a vulnerable kernel. The purpose is to find the required hash values for the altered CB section in a base kernel (1888). The lockdown counter in the CB section is changed to a higher value to allow the base kernel (1888) to bypass the restrictive lockdown counter check. The check is what makes it impossible to just flash the NAND and downgrade to a vulnerable kernel.

Foreword

A good explanation by arnezami [1]:

[With the CPU key] can we not resign the essential parts of the HV, or anything else, with a modified bootloader?
All executable code on the xbox is (one way or another) signed by a RSA key. MS has the private RSA key and thats
why we will never be able to sign our own executable code. This is what prevents us from running anything different
than what MS has build (like the kernel and bootloaders). This has nothing to do with the cpu key. The only thing we
can do with the cpu key is choose which version of the kernel/bootloader we want to run. But we cannot make changes
to any of these versions themselves. 

Then why downgrade?
Because two kernel versions MS build (4532,4548) have a tiny flaw. And when we have our cpu key we can choose to
run these (old) kernels and exploit them by running a patched KK game. After running the exploit we have complete
control over the xbox (but not before that). This means to be able to run homebrew or linux we now have to start the
game, press ok, insert a disc etc. More

Flaw

The memcmp function used to check the CB-auth value is 16 bytes long and done byte-by-byte. Changing one byte will to something false will take a few microseconds longer than a true value. Doing this for each byte will reveal the correct hash. Possibilities: 16 bytes * 256 different possibility for each byte, total 4096 tries.

Possible MS Updates

arnezami:

MS cannot fix this problem by simply changing the memcmp function in a future kernel version. Thats not
gonna help them. The weakness is that the byte-wise memcmp function is in the 1888 kernel/bootloader
(and they cannot change that one anymore of course). [2]

tmbinc:

sure, microsoft can change the 2BL, and burn a fuse (of the fuseline 2) so that an old 2BL doesn't work anymore... [3]

arnezami:

Ah. Right. If they can indeed burn these fuses at row 2 than you wouldn't be able to run any of the lower 
kernel versions anymore. [4]

Been thinking about this. I'm now pretty sure when row 2 of the fuses is burned your xbox won't be able to 
downgrade or run homebrew anymore (it appears the fuse count number is indeed RSA signed). [5]

surrido:

you could if it makes you happy wire a switch to the R6T3 and keep it on while being in live and turn it 
of when you receive an update. [6]

tmbinc:

No, a switch at R6T3 doesn't help. It's not the resistor which presence can be detected, but the result 
to the fuse (burned or not).

So his question is completely valid: If you remove the resistor, you could end up with an unbootable box 
after the next update. But at least you could restore a previous flash. (If you want, you could *then* 
re-attach the resistor, and update again, of course loosing the possibility to downgrade). [7]

Proceedure

Dump NAND

Use Infectus or custom hardware to make a valid dump of the current NAND.

Patch CB

Get a plain 1888 base kernel and patch the CB lockdown counter with the value from the CF section in the NAND dump.

Attack Hash

Attack the HMAC hash value using the timing hardware.

Upgrade Kernel

Once you have the base kernel you can apply the 4543 or 4548 kernel to use the King King exploit and getting the CPU Key.