Downgrade Kernel of 'eFused' Xbox 360 Possible if CPU Key is Known>> Some nice progress by several people has been made over at the XboxHacker forums where they found a way to downgrade a kernel even when the eFuses were burned to prevent this. The bad news is that you'll need the CPU key (also 'hidden' in the eFuse data) to do so.
Originally downgrading kernel was possible but Microsoft blew eFuses during the upgrade from kernel 4548 to 4552 as that's where they fixed the Hypervisor Vulnerability (which only works on kernel 4532/4548 and allows to run unsigned code / linux). It was already known that by removing the r6t3 resistor from the motherboard before the upgrade you could prevent MS from blowing eFuses and thus still be able to downgrade from a 4552+ to pre-4552, but I don't know how safe this is for future kernel updates.
MS doesn't blow new eFuses (located on the CPU dye) on each upgrade because they only have a limited amount available: 768 (12 'fuselines' of 64 fuses each) in total and only a part of these (5 'fuselines'(= 320 fuses)?) can be used to prevent kernel downgrading (= 80 possible downgrade bans? - once blown it can't be undone}. The eFuses also contain other data like a unique 'CPU Key'.
According to tmbinc, this key is used for:
* Encryption of the *keyvault* (that stores: console certificate(s), per-box private keys, DVD key, however NOT any code-related encryption keys)
* Encryption of an imported console revocation table (CRLL, that stuff which recently hit 360gamesaves.com, and no, this isn't live-related),
* "Encryption" of the pairing information of the 'CB' and 'CF' (for exact details, please reverse that code, it's a bit hard to describe.)
'CB' (2nd bootloader?) and 'CF' (kernel patches) are located on the Xbox 360 on-board flash in the "CPU data" section (data which is read when the power is switched on. If invalid, console might blink red etc.).
To make sure I don't say anything silly/wrong, I'm gonna quote some of the guys themselves for the rest of the info about this hack.
Quoting tmbinc and TheSpecialist:
All which is different from pre-4552 to 4552 and up are the G/H bits [part of eFuses]. They encode a "sequence" number, which is also stored in the CF "pairing" data, and one bit here is burnt to "increment" the sequence.
That means: If you know how to calculate the CF pairing data, you could modify the "expected sequence" value there (this, however, should be verified by someone.) And to be able to calculate that data, you need the "per-box-key". But if you have that, you could set the number of a 4532 to those of a 4552, and it should boot again.
At byte 0x21F in CF is the number that is incremented when a fuse is burned (thanks to Robinsod). This byte and ONLY this byte causes that you can't downgrade. We wanted to try to decrement that number again, but I just found that that's not possible without knowing the fuse data: byte 0x0 to 0x220 in CF are hashed (hash stored at 0x220). The hash routine uses the cpu key as input and verifies the calculated hash to the one stored at 0x220. So no downgrading without CPU key ...
So the 'sad' part is that you need this CPU Key if you wanna downgrade to a pre-4552 kernel ... and on kernel 4552+ there's no known way to get this key (yet). On kernel 4532/4548 you can use the Hypervisor Exploit to retrieve this data (like the Xell Linux Loader does) - but if you have one of these kernels you can already run unsigned code. However, if you're still on 4532/4548 this new hack will allow you to retrieve your unique CPU key, upgrade to a newer kernel and you'll be able to downgrade back to a pre-4552 kernel again even if eFuses got burned.
Robinsod tested this out successfully:
In the decrypted CF there is a "version lockdown counter" at 0x21F. Every time an update is applied (since version 4532) an eFuse is blown and the counter is incremented by 1 before it is written into the new CF. When booting, a check is made to ensure that the lockdown counter in the selected CF >= number of blown eFuses.
The good news is that we can modify the lockdown counter byte and re-encrypt the CF section. The bad news is that a hash of the first 0x220 bytes requires the CPU Key. So as long as we know our CPU Key we can downgrade to a vulnerable kernel.
1) Brand new XBox with 1888 & 2241
The Version Lockdown Counter in my 2241 CF is 0
2) Applied 4532
The Version Lockdown Counter in my 4532 CF is 1
Also fuseset 07: f000000000000000
3) Applied 4552
The Version Lockdown Counter in my 4552 CF is 2. Confirmed that I cant downgrade to unpatched 4532 dump
4) Fixed up a dump of 4532 with CF Lockdown Counter = 2. Boots!
Now when I dump my fuse data
fuseset 07: ff00000000000000
A second fuse was blown by 4552
Robinsod also released v0.6 of his 360 Flash Dump Tool(info) that will allow you to fix the 'version lock' in pre-4552 kernels (again - only if you have your unique CPU key) so it'll boot even on a Xbox 360 with eFuses blown by the 4552 update.
What's new/fixed:
* (v0.5) Now decrypts and extracts the Key Vault. You will need your CPU Fuses as dumped by Xell. The CxKey.txt file has changed, you need to add a ',' and your CPU Fuse data
* (v0.6) This release supports downgrading if you know your CPU key. Right click on a CF section and choose "Fix Version Lock", enter the new lock down number, click ok & then click "Patch" and choose the directory/filename for your patched flash image. The file produced is all fixed up and ready to be flashed into your 360.
So ... conclusion, if they somehow manage to find a way to get the 'CPU Key' out of your Xbox 360 - it looks like it's "game over" for our friends at Microsoft. 
