Downgrading..

[uberfry]

surrido...you're proving a point there...
maybe they're blowing an efuse to change the encryption? and therefor 4552 cannot boot?
hmmm...interesting idea...

and also, like robinsod mentioned, they only change parts of the nand flash in an update...so it could be that they changed the efuse to only be able to run kernels "based" on 4552 to not run 1888 (because 1888 is then encrypted with a different key)

so maybe we could get 4552 (I know it's useless but still...) to run on a box with no efuse blown by reencrypting the 4552 kernel?

[Surrido]

if we are able to get a dump of  the DEcrypted 4532 or the 4548, maybe we can find the encryption by comparing it to the dump of 4532 / 4548.

at least to understand the encryption.

we cannot decrypt a kernel with 4552 that comes from a console with the fuses blown, because we cant get the decrypted version (because linux doesnt boot...). thats useless.

the only thing i can think of is to find out how it is enrypted.

If we know that, maybe there is a way to use a decrypted 4532 and reencrypt this with the changed fuse settings/changed encryption of the 4552. THAT one should boot in my opinion. but i have no idea if we can find out the encryption by comparing a decrypted 4532 with an encrypted 4532.

i doubt that.

EDIT: i dont like the expression "blown" efuses. i believe it is a key, not more

[caster420]

surrido...you're proving a point there...
maybe they're blowing an efuse to change the encryption? and therefor 4552 cannot boot?
hmmm...interesting idea...

Dr. Matrix said a long time ago that he belives if we could extract the fuseset from an upgraded box with 4552, that we could, in theory, re-encrypt an older kernel to work with that console.  The fuseset is used to encrypt your keyvault (if i understand correctly), which is why one kernel dump will not boot on another 360. 

I agree with Surrido, i dont like the term 'blown'.  I think they simply change the value(s), resulting in different encryption, and thus, the inability to reuse a lower kernel without re-ecrypting it with the new fuseset values.

Caster.

[uberfry]

I agree with Surrido, i dont like the term 'blown'.  I think they simply change the value(s), resulting in different encryption, and thus, the inability to reuse a lower kernel without re-ecrypting it with the new fuseset values.

that's exactly what I meant
but how do we get the decrypted kernel from a 4552 then? we'd have to reverse the update :S

[Surrido]

but how do we get the decrypted kernel from a 4552 then? we'd have to reverse the update :S

i want to try to use my dual kernel mod for that. I have no idea if this works, but i want to try to do this:

I have two NANDS. A and B.
A is 4532
B is 4552 (R6T3 removed!)

I boot into linux using A. i switch to B while linux is running. (ugly NAND hotswap ;-)  )

now here comes the point where i have NO idea if this is possible or not. Will the xbox decrypt B? and can i load it and dump it to a file?
thats where i will need help...

In my opinion the best option we have so far to get a decrypted 4552...

suggestions?

[ForSwitch]

but how do we get the decrypted kernel from a 4552 then? we'd have to reverse the update :S

I don't think so...

I boot into linux using A. i switch to B while linux is running. (ugly NAND hotswap ;-)  )

now here comes the point where i have NO idea if this is possible or not. Will the xbox decrypt B?
...

In my opinion the best option we have so far to get a decrypted 4552...

suggestions?

Probably not.


As I understand the situation, one does not need the fuses to decrypt the firmware, only the "keyvault."

Only the key section is related to the fuses. All the other sections are not and can be decrypted without having any 'per box' key/fuse info. Also, since we're now able to unpack the CE section (thanks to " Paul Bartholomew" who wrote the xbox 1 kernel unpacker and thanks to 'derived' for posting it), you can now decrypt and unpack any kernel+hypervisor you'd like, if you have a TSOP dump, so also kernel 4552.

Unless I've missed something....

I'm currently working on obtaining a vulnerable box of my own to play with.  I've got a vulnerable box, I just haven't got around to modifying the DVD drive on it yet.

[warpjavier]

Hi all,
I got this from "Analysis of the HV" Thread.

Hi,
Maybe this is off topic but anyway I'll post it here. I also don't have the skill to do it myself.

Having the efuses of a vulnerable kernel, we can dump the flash and decrypt all the sections because all the encryptions are related to the efuses, if I'm not wrong this is a fact.

Only the key section is related to the fuses. All the other sections are not and can be decrypted without having any 'per box' key/fuse info. Also, since we're now able to unpack the CE section (thanks to " Paul Bartholomew" who wrote the xbox 1 kernel unpacker and thanks to 'derived' for posting it), you can now decrypt and unpack any kernel+hypervisor you'd like, if you have a TSOP dump, so also kernel 4552.

Will the xbox decrypt B? and can i load it and dump it to a file?
thats where i will need help...

I believe the dump you get from linux, is the same dump you can get with Infectus or any other NAND programmer but you dont have a RAW dump that way, so you will be missing the extra 16 bytes of the nand. So does not maka sense to do that if you are gonna end up with an unusable dump.
Also, to decrypt the NAND sections (kernel/HV), you will need the key that is in the boot loader as far as I know, and nothing it's been released so far (tools).

I think that having a dual kernel box will be more interesting if, apart from having a Vulnerable kernel and a kernel that let you play the latest games, would be great to have a kernel that let you load games from the hard drive and run homebrew. 

warpjavier

[ForSwitch]

i think the most interesting thing to do would be reversing the update to get the new fuses :/ that way we can maybe reencrypt 4532 infectus dump try if that works :/

As I understand it, the fuses are generated randomly by a syscall, and stored.  They are not "static" in any update.

All keys are "per box", or rather, "per write". syscall 0x34 re-encrypts a flash image, and will randomize all keys.

The real "per box" stuff are the fuses, which are verified in the CB against the first 0x20 bytes or so (0x20..0x3f, directly after the key). That makes one image unbootable on another board.
...

My only question is the relationship between the fuses and the encryption is, which fuse is used?  I've never actually seen a fuseset, so I don't know what their length is.  However, Xell seems to print 12 fuses.

   for (i=0; i<12; ++i)
      printf("fuseset %02d: %016lx\n", i, *(unsigned long*)(0x8000020000020000 + (i * 0x200)));

I'm assuming sizeof(long) on the 360 is 64 bits, making each fuse 64 bits long?  Are the fuses concatenated together and used for encryption?  Some other mathy voodoo?

[tmbinc]

There are 64*12 fuses. 64 fuses form a (i call it) "fuseline".

The fuses (one char is one nibble) have the following form:

ABCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDD
EEEEEEEEEEEEEEEE
FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF
GGGGGGGGGGGGGGGG
HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH

A is pretty fixed, and seems to configure the CPU boot behaviour or something.  I think it's production-burned. It's 0xC, usually, and needs to be that value, or 'CB' will refuse to boot.
B is unknown to me (and is usually zero),
C is set by the "burn fuses" syscall with bit=8, and is all ones, for me.
D is a bitfield, a "f0" is being decoded as '1', a "0f" is being decoded as '0'. After that, it has to match a certain value which is stored in 'CB'. My guess is that this a post-production configuration byte. It's initialized with "burn fuses, bit=1"
E is encoded similiar to the G/H fields (see below), and also has to match a minimum value in 'CB'. Maybe this is some (yet unused?) revocation algorithm? It's however unrelated to the upgrade. It's set with bit=2
F is what we call "per-box key". It's decoded into a ~90 bits value, which is then used for decrypting the keyvault, checking the pairing of 'CB' and 'CF'. It's initialized (from a random value) with bits=4.
G (and also H) is used for the upgrade revocation stuff. (and set with bits=0x20)

Basically, these lines (G/H) store a number from 0 to 16 (I think it is supposed to actually store a number from 0 to 5*16, but this seems either buggy or I have misunderstood this code). Now the 'CF' has a value (as part of the pairing information) which must be less-or-equal the fuse-stored number. However i don't know exact details yet. I haven't seen any fuseset from an updated box.
Additional bits can be set, to increase (but not decrease) this number.

Back to the "per box key": It's used in the following things:
 - 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.)

So, if we have the fuse-values, everything could be great (as we can encrypt keyvault, pairing, ...). If we don't have them, we are screwed.

(There is another option with regard to the MfgBootlauncher but i'm currently to lazy to explain this and it's implications)

[fickdiach]

i think they got an debug method to retrieve that keys for repairing the boxes.
we should figure out where it is and how to use, would be really great to get the 4552 fuses :|
can anybody think of another method of retrieving the fuses?

[ForSwitch]

There are 64*12 fuses. 64 fuses form a (i call it) "fuseline".

The fuses (one char is one nibble) have the following form:

::lots of technical information, for which I am greatful, goes here::

Thanks for that info.

Back to the "per box key": It's used in the following things:
 - "encryption" of the pairing information of the 'CB' and 'CF' (for exact details, please reverse that code, it's a bit hard to describe.)

So then this is what was "blown" with the January update?  The (freshly encrypted, with fresh keys) pairing area is what kept Robinsod from reverting to his backed up flash?

As much as I would love to reverse the code, I haven't yet got my hands on a vulnerable box.  My last hopes at one were dashed due to an impatient friend ("DUDE!  I can play Mortal Kombat 3 on live!  Fsck waiting until the morning.").  I've recently found another one in my area, and am trying to swap out a 3rlod repair for it, but the chances are looking low.

(There is another option with regard to the MfgBootlauncher but i'm currently to lazy to explain this and it's implications)

I remember Dr. Matrix talking about this function.  However, as far as I recally, he stated that a downgrade wasn't possible from this mode.  It also required writing zeros a part of CB.  This requires the fuses, though, does it not?  I know it must be re-encrypted, I guess I'm just unclear as to if it must be re-encrypted with the fuses, or with that "not-so-secret" key found elsewhere.  And isn't that section hashed/signed anyway?

i think they got an debug method to retrieve that keys for repairing the boxes.
we should figure out where it is and how to use, would be really great to get the 4552 fuses :|
can anybody think of another method of retrieving the fuses?

GaryOPA seems to believe he knows how they're doing this.  Details (though they are incredibly scarce at the moment) here.

[vax11780]

Sorry for jumping into the middle of this, I haven't been following the forum for a while.

A few assumptions:

1) A fuse, once burned, cannot be unburned
2) MS wouldn't want to waste fuses on a single update because they may need to lock in future updates

Conclusion:

The 4552 fuses are VERY similar to the previous fuses.

So, the following process should work:

1) Dump the fuses from an exploited box
2) Upgrade to 4552 with R6T3 installed (This may not be required)
3) Remove the flash and dump it
4) Take the fuse dump previously made and toggle a single bit and attempt to decrypt the flash
5) Repeat all 64 combinations
6) Toggle two bits and attempt to decrypt
7) Repeat for all 64*63 combinations
Repeat for three bits, four bits, until you lose your mind

It is possible the effort can be reduced by assuming unblown fuses are '0' so try '0' -> '1' keys only
It can also be assumed unblown fuses are '1' so the inverse is also true.

VAX

[TheSpecialist]

Sorry for jumping into the middle of this, I haven't been following the forum for a while.

A few assumptions:

1) A fuse, once burned, cannot be unburned
2) MS wouldn't want to waste fuses on a single update because they may need to lock in future updates

Conclusion:

The 4552 fuses are VERY similar to the previous fuses.

So, the following process should work:

1) Dump the fuses from an exploited box
2) Upgrade to 4552 with R6T3 installed (This may not be required)
3) Remove the flash and dump it
4) Take the fuse dump previously made and toggle a single bit and attempt to decrypt the flash
5) Repeat all 64 combinations
6) Toggle two bits and attempt to decrypt
7) Repeat for all 64*63 combinations
Repeat for three bits, four bits, until you lose your mind

It is possible the effort can be reduced by assuming unblown fuses are '0' so try '0' -> '1' keys only
It can also be assumed unblown fuses are '1' so the inverse is also true.

VAX

Not sure what you want to attain here. The only box specific encrypted section is the key section and since, like Tmbinc says, that's the 'F' type, it seems to me that that won't change after 4552 but always stays the same and it's only due the G/H number that a specific kernel does or does not boot (correct me if I'm wrong here, tmbinc )

[vax11780]

Dr. Matrix said a long time ago that he belives if we could extract the fuseset from an upgraded box with 4552, that we could, in theory, re-encrypt an older kernel to work with that console.  The fuseset is used to encrypt your keyvault (if i understand correctly), which is why one kernel dump will not boot on another 360. 

I agree with Surrido, i dont like the term 'blown'.  I think they simply change the value(s), resulting in different encryption, and thus, the inability to reuse a lower kernel without re-ecrypting it with the new fuseset values.

Caster.

Not sure what you want to attain here. The only box specific encrypted section is the key section and since, like Tmbinc says, that's the 'F' type, it seems to me that that won't change after 4552 but always stays the same and it's only due the G/H number that a specific kernel does or does not boot (correct me if I'm wrong here, tmbinc Smiley )

In theory you would now have the fuseset the 4552 kernel is using, thus be able to re-encrypt the exploitable kernel to run with new fuses and upgrade/downgrade at will.

It doesn't help the people with 4552 boxes who didn't have the foresight to dump their fuses before upgrading.

VAX

[TheSpecialist]

In theory you would now have the fuseset the 4552 kernel is using, thus be able to re-encrypt the exploitable kernel to run with new fuses and upgrade/downgrade at will.

No, if you can decrypt the key section, that only means that you have the correct 'F' bytes. To encrypt the kernel itself, no box specific keys are necessary, only the (known and not box specific) key from 1BL. However, it won't run, even with modded 'pairing' data, because of the mismatch between the CF and the G/H fuse data. And of course we can't modify CF because that would break the signature.

[tmbinc]

as already correctly stated:

The "per-box" key is never modified. It cannot be modified, as the bits are one-time-programmable, and enough bits are already set so you cannot modify this number without breaking important properties (no of set bits, ECC) of the serial numer.

All which is different from pre-4552 to 4552 and up are the G/H bits. 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.

(Everything beyond the pairing data is of course signed with the private key.)

[TheSpecialist]

Damn. It seems you can't downgrade without knowing the fuse data.

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

[Surrido]

maybe the infectus guys give us a way to dump those keys...

did you post a "howto" for getting the CPU keys? did i miss that?

[TheSpecialist]

maybe the infectus guys give us a way to dump those keys...

did you post a "howto" for getting the CPU keys? did i miss that?

What we call the 'cpu key' is the 16 bytes, formed by fuseline 4 + fuseline 5.

Fuseline n can be dumped by dumping 0x8000_0200_0002_0000 + n*0x200 (or by using the XELL loader, which does this for you).

If you can dump the fuses, you can downgrade your kernel and therefore run unsigned code.

[torne]

Apologies if this is a n00b question... but is it still possible to downgrade by corrupting the patches (the way it was done pre-4552) if you removed R6T3 before upgrading?

I got the box with 1888, and removed R6T3 immediately before playing any games or connecting to Live. Since then it's been upgraded to the latest. Sadly, I neglected to be patient enough, and don't have a dump of the flash or the fuseset from any point. If I dumped the flash and corrupted the patches in the way robinsod did back on 2868, would I be able to revert to 1888 that way? (and then upgrade to an exploitable kernel and run XELL to dump the fuseset) If not, can someone actually explain why, since it's confirmed that post-4552 versions are still 1888+patches, and my fuses should've been untouched since 1888...

Thanks for any hints