Key Vault Contents

[robinsod]

Now we can decrypt the Key Vault it would be nice to know what all those entries do. TS found a key look up table at 00010BF0 which gives offsets into the Key Vault:

Offset	Purpose	Size	Common To All Boxes?
0x0078	Unknown	10	No
0x0088	Unknown	10	No
0x0098	Serial Number	0C	No
0x00A4	Unknown	0C	No
0x00B0	Unknown	08	No
0x00B8	Unknown	10	No
0x00C8	Unknown	10	No
0x00D8	Unknown	10	Yes
0x00E8	DVD Key	10	No
0x00F8	Unknown	18	No
0x0110	Unknown	10	No
0x0120	Unknown	10	Yes
0x0130	Unknown	10	Yes
0x0140	Unknown	10	No
0x0150	Unknown	10	No
0x0160	Unknown	10	No
0x0170	Unknown	10	No
0x0180	Unknown	10	No
0x0190	Unknown	10	No
0x01A0	Unknown	10	No
0x01B0	Unknown	10	No
0x01C0	Unknown	10	No
0x01D0	Unknown	10	No
0x01E0	Unknown	10	No
0x01F0	Unknown	10	No
0x0200	Unknown	10	No
0x0210	Unknown	10	No
0x0220	Unknown	10	No
0x0230	Unknown	10	No
0x0240	Unknown	10	No
0x0250	Unknown	10	No
0x0260	Unknown	10	No
0x0270	Unknown	10	No
0x0280	Unknown	1D0	No
0x0450	Unknown	390	No
0x07E0	Unknown	1D0	No
0x09B0	Manufacturing date etc	1A8	No
0x0B58	Unknown	1388	No
0x1EE0	Certificate	10	No

Listed above are some of the indices into the KV (add 8 to find the actual offset into the vault), the assumed length, the keys purpose (if known) and if the key holds the same value in more than 1 consoles KV.

Anyone know what any of the others are?

[arnezami]

I've noticed that all 4 cerificates in the area you marked "Certificate" are chained: each public key is signed by the previous one. And the first public key in the "Certificate" part (encoded in base64) is also present in 7F0-86F (encoded as binary in reverse 64-bit chunks). And it seems there are a few more signatures/public keys in there.

What I'm wondering is whether this ultimately is all signed by the (public) key in the 1BL. If not that would be interesting since they are using a stream cypher instead of a block cypher...

arnezami

PS. When I look at my decrypted KV.bin my offsets are 8 position different: what do those first 8 bytes of the KV stand for anyway? Is the decrypted KV in any way checksummed or hashed? And was it compressed btw?

[robinsod]

PS. When I look at my decrypted KV.bin my offsets are 8 position different: what do those first 8 bytes of the KV stand for anyway? Is the decrypted KV in any way checksummed or hashed? And was it compressed btw?

The KV is crypted with the CPU Key, no compression, the first 8 bytes are some kind of hash. I haven't looked any deeper than that though

[arnezami]

PS. When I look at my decrypted KV.bin my offsets are 8 position different: what do those first 8 bytes of the KV stand for anyway? Is the decrypted KV in any way checksummed or hashed? And was it compressed btw?

The KV is crypted with the CPU Key, no compression, the first 8 bytes are some kind of hash. I haven't looked any deeper than that though

Thanks .

I've been thinking about something. I believe it is possible to change the known (or predictable) contents of the KV into anything we want even if we do not have the cpu key. But only if certain conditions are met. And what effect a change has depends on whether the changed parts are somehow verified and how they are used (eg a hash or strong checksum of the decrypted KV rules out this idea).

As a proof of concept we could change one bit in the DVD key. These assumptions have to be true for it to work:

• You can read your (encrypted) flash and edit it and re-flash it
• The KV is uncompressed (already confirmed)
• The KV is encrypted using a stream cipher (RC4 in this case)
• We do know our DVD key: so we know what that decrypted part of the KV looks like
• We do not know our cpu key (eg because we have upgraded to an unvurnable kernel, this we pretend ftm)
• The decrypted KV is not hashed, checksummed or signed as a whole (this a real deal breaker, although a weak checksum might still work)

Normally we can only change something inside the KV by changing the decrypted one and re-encryting it. But because a stream cipher is used it can also be done without the re-encryption. In order to change one bit of the DVD key you simply change one bit at the position where the DVD is located (even though its all encrypted). What this does is change the same bit in decrypted form. The reason being that a stream cipher simply XORs a (in this case: fixed) stream of bits with unencrypted bits: while we do not know this secret stream of bits we can know the effects of changing the encrypted bits on the decrypted message. With a block cipher this wouldn't work.

Maybe somebody can try this out. You would also have to change the DVD key in you drive to see if it actually works. Of course if one of the above assumptions isn't true it won't work.

One application may be to make a public key even instead of odd (change one bit) and this just might (eventually) give us the ability to sign binaries ourselves. However this stuff is extremely hard and I still have to think about what can and can't be done. In the mean time a PoC test would be nice. I'm also trying to find out where all the keys in the KV are used for and if they're all chained to the 1BL. I'm also curious whether some xbox-es may have some keys in common. Or whether some information in the KV can be predicted/guessed somehow. Any information you know may be helpful.

Anyway. Just my thoughts...

Regards,

arnezami

PS. When looking at the layout of the NAND its not clear to me where the KV is actually located. Can somebody clear this up?

[Takires]

The KV is always 16 kbytes long and its address can be found at 0x6c (which usually contains 0x4000).

[SeventhSon]

You would also have to change the DVD key in you drive to see if it actually works.

Or, even better, change something other than the DVD key on a vulnerable box and then dump the decrypted KV from RAM to observe the plaintext changes. KV is available from 0x8000_0176_018D_0000 in the 4548 HV (length 0x4000 bytes). Obviously not ideal to change the DVD key because we need to load the exploit from DVD to dump the KV from RAM and observe the changes.

Maybe somebody can try this out.

I've not currently got my NAND socketed in my exploitable kernel box. But I changed a single bit in the serial number of my box running 5759. Result = Nothing on screen and alternating red/green front panel LEDS. Then I tried to change a single bit in my manufacture date. Same result. I can't be sure because I've not reversed anything much to do with the KV, but it looks like some kind of verification is going on. Here's what I did in case you want to check for stupid mistakes in the experiment.

1. Dump NAND in 528-byte-per-page format.
2. Get KV offset from NAND[0x6C] (0x4000, as usual)
3. Change LSb of NAND[0x42B9] which I calculate to be 10th digit of my serial
4. Fix up the EDC using the modified version of the DrMatrix algorithm posted in the ECC thread.
5. Flash back to NAND
6. Boot xbox (fails)
7. Repeat steps 1 - 6 changing the LSb of NAND[0x4C2B] at step 3 which I calculate to be the last digit of my manufacture date.

Hope this helps. Good luck with your research.

[robinsod]

Im pretty sure the first 8 bytes are a hash of the KV so that isn't going to work

[sectroyer]

Since we know some parts of keyvault (common to all xbox'es,dvd key, serial number,etc) can't we use it to calculate cpu key.
I am not an expert in crypto but:
X crypt_with Y = Z
If you know two parts of this equasion you can calculate the third one ?

[SeventhSon]

X crypt_with Y = Z
If you know two parts of this equasion you can calculate the third one ?

Yes, but the crypt_with function is designed to make that calculation computationally unfeasible. Basically, no

[arnezami]

You would also have to change the DVD key in you drive to see if it actually works.

Or, even better, change something other than the DVD key on a vulnerable box and then dump the decrypted KV from RAM to observe the plaintext changes. KV is available from 0x8000_0176_018D_0000 in the 4548 HV (length 0x4000 bytes). Obviously not ideal to change the DVD key because we need to load the exploit from DVD to dump the KV from RAM and observe the changes.

Maybe somebody can try this out.

I've not currently got my NAND socketed in my exploitable kernel box. But I changed a single bit in the serial number of my box running 5759. Result = Nothing on screen and alternating red/green front panel LEDS. Then I tried to change a single bit in my manufacture date. Same result. I can't be sure because I've not reversed anything much to do with the KV, but it looks like some kind of verification is going on. Here's what I did in case you want to check for stupid mistakes in the experiment.

1. Dump NAND in 528-byte-per-page format.
2. Get KV offset from NAND[0x6C] (0x4000, as usual)
3. Change LSb of NAND[0x42B9] which I calculate to be 10th digit of my serial
4. Fix up the EDC using the modified version of the DrMatrix algorithm posted in the ECC thread.
5. Flash back to NAND
6. Boot xbox (fails)
7. Repeat steps 1 - 6 changing the LSb of NAND[0x4C2B] at step 3 which I calculate to be the last digit of my manufacture date.

Hope this helps. Good luck with your research.

Ok. Thanks for testing.

A possible reason why this isn't working is because (if I remember correctly) both the serial and manufacturing date are signed . So this may have nothing to do with the possible hashing. We need to change something that is for sure not signed.

Lets go back to basics: please try to change 1 bit in the unused areas (filled with 00's). And see what happens. There are three main unused areas: right after the presumed 64-bit hash, between the binary crypto and the base64 crypto stuff and at the end of the kv. Its best to try changing only 1 bit in the whole file but try all three areas.

Hoping the xbox will boot...

Regards,

arnezami

PS. Question: where and when exactly does the decryption of the KV take place? Is it done by the code in the 1BL?

[Takires]

PS. Question: where and when exactly does the decryption of the KV take place? Is it done by the code in the 1BL?

It is done by the HV code. I dont remember which syscall does it, look it up in these random notes that had the names of a few syscalls in it.

[TheSpecialist]

PS. Question: where and when exactly does the decryption of the KV take place? Is it done by the code in the 1BL?

It is done by the HV code. I dont remember which syscall does it, look it up in these random notes that had the names of a few syscalls in it.

sc2e_KeysInitialize.

BTW, like Robinsod noted, the first 8 bytes of the KV is a hash. I haven't looked into that, but I wouldn't be surprised if that's the reason why you can't change anything: you'd have to write a correct hash too. At least, that would make sense

BTW2, I also wouldn't be surprised if the serial is related to the certificate and therefore you can't change it anyway .. Or better said this way: I'd be VERY much surprised if the serial was not somehow related to the console certificate.

[SeventhSon]

Lets go back to basics: please try to change 1 bit in the unused areas (filled with 00's). And see what happens. There are three main unused areas: right after the presumed 64-bit hash, between the binary crypto and the base64 crypto stuff and at the end of the kv. Its best to try changing only 1 bit in the whole file but try all three areas.

I agree with Karl and Spec about the hashing, but I performed your experiment. Results all point the same way I'm afraid. I changed the LSb of the following offsets into my NAND dump (note that dump includes the spare areas if checking these offsets).

0x4258 = somewhere in first 0x00 block
0x4FA8 = somewhere in second 0x00 block
0x8118 = somewhere in third 0x00 block

Not all at once obviously. Same result as before for all 3. So it looks like game over. A valiant effort all the same.

Of course, the only way to be 100% sure is to reverse the OS.

[arnezami]

Lets go back to basics: please try to change 1 bit in the unused areas (filled with 00's). And see what happens. There are three main unused areas: right after the presumed 64-bit hash, between the binary crypto and the base64 crypto stuff and at the end of the kv. Its best to try changing only 1 bit in the whole file but try all three areas.

I agree with Karl and Spec about the hashing, but I performed your experiment. Results all point the same way I'm afraid. I changed the LSb of the following offsets into my NAND dump (note that dump includes the spare areas if checking these offsets).

0x4258 = somewhere in first 0x00 block
0x4FA8 = somewhere in second 0x00 block
0x8118 = somewhere in third 0x00 block

Not all at once obviously. Same result as before for all 3. So it looks like game over. A valiant effort all the same.

Of course, the only way to be 100% sure is to reverse the OS.

Thanks for the confirmation.

I agree this idea is probably a dead end now. But it was a good attempt I think. It would have been a nice way of using a "loose end" in the encryption scheme. But I guess we have to find another exploit in the code...

Btw: does anybody have a clue what kind of hash is used? 64-bit seems a little strange. Have two hashes been compared yet? How sure are we the EDC is correct?

arnezami

[SeventhSon]

How sure are we the EDC is correct?

Very

[arnezami]

How sure are we the EDC is correct?

Very

Ok. Thanks.

Been thinking...

There is still one thing that just might work. Just in case they used a very simple 64-bit checksum (could very well be ) the following could work:

1) Change the LSb of a 64 bit value in an unused part (an area with 00's)
2) Change all 64 bits (= complement) in the 64-bits next or close to it (has to be aligned)

This would result in the same 64-bit checksum. Basicly you change 0000000000000000h into 0000000000000001h and another 0000000000000000h into FFFFFFFFFFFFFFFFh. If you add them up the result will be zero in both cases.

Of course this would only work if the "hash" is in fact a checksum.

Regards,

arnezami

[SeventhSon]

How sure are we the EDC is correct?

Very

Ok. Thanks.

Been thinking...

There is still one thing that just might work. Just in case they used a very simple 64-bit checksum (could very well be ) the following could work:

1) Change the LSb of a 64 bit value in an unused part (an area with 00's)
2) Change all 64 bits (= complement) in the 64-bits next or close to it (has to be aligned)

This would result in the same 64-bit checksum. Basicly you change 0000000000000000h into 0000000000000001h and another 0000000000000000h into FFFFFFFFFFFFFFFFh. If you add them up the result will be zero in both cases.

Of course this would only work if the "hash" is in fact a checksum.

Regards,

arnezami

That would be *very* out of character for Microsoft's security model this time around. But I'll gladly try it for you when I get home (in 8 hours time ). I'll try and find the verification code in the HV too, that will settle it once and for all.

[arnezami]

Ok. Thanks.

Been thinking...

There is still one thing that just might work. Just in case they used a very simple 64-bit checksum (could very well be ) the following could work:

1) Change the LSb of a 64 bit value in an unused part (an area with 00's)
2) Change all 64 bits (= complement) in the 64-bits next or close to it (has to be aligned)

This would result in the same 64-bit checksum. Basicly you change 0000000000000000h into 0000000000000001h and another 0000000000000000h into FFFFFFFFFFFFFFFFh. If you add them up the result will be zero in both cases.

Of course this would only work if the "hash" is in fact a checksum.

Regards,

arnezami

That would be *very* out of character for Microsoft's security model this time around. But I'll gladly try it for you when I get home (in 8 hours time ). I'll try and find the verification code in the HV too, that will settle it once and for all.

Great.

Really curious about what algo is used here to create the 64-bit value: eg if a crc64 is used I believe its also doable...

I'm guessing the fact they used only 64-bits sort of hints that this is not a full-blown hashing algorithm.

As an aside: I'm also working on making HD DVD key retrieval and (on-the-fly) decryption/playback possible on the xbox itself (among several other things ). Its a lot of work. I have very little time but I really love this crypto stuff . So can't do all the reverse engineering aswell. Either way I really appreciate your efforts and patience...

Regards,

arnezami

[SeventhSon]

Denied.

Entire decrypted KV (excluding the signature obviously) is signed with HMAC SHA1. Signature is 128-bit, not 64-bit and exists at offset 0 into the KV at NAND[0x4000] (assuming NAND[0x6C] is 0x4000). KV 'dumps' extracted via Robinsod's awesome flash tool are only 0x3FF0 bytes in size and do not contain the signature, but if you dump the KV from HV RAM then you get it (addr: 0x8000_0176_018D_0000 length: 0x4000). Or simply read it right out of flash and stick in on the front of a Robinsod dump.

Here's the ASM. Excuse the comments, I make silly comments as I go along that probably are no use to anyone but me. This is from the 4548 HV. It generates decryption key using HMAC SHA1, decrypts with RC4, then verifies signature with HMAC SHA1.

Code:

ROM:00007338 DECRYPT_VERIFY_KV_7338:                 # CODE XREF: sub_74B0+68p
ROM:00007338                                         # ROM:00008914p
ROM:00007338
ROM:00007338 .set var_C0, -0xC0
ROM:00007338 .set arg_50,  0x50
ROM:00007338 .set arg_5C,  0x5C
ROM:00007338 .set arg_60,  0x60
ROM:00007338 .set arg_70,  0x70
ROM:00007338 .set arg_80,  0x80
ROM:00007338 .set arg_90,  0x90
ROM:00007338
ROM:00007338                 mflr    %r12
ROM:0000733C                 bl      sub_B3FC        # save regs & LR
ROM:00007340                 stdu    %sp, var_C0(%sp) # 0xC0 byte stack frame
ROM:00007344                 addis   %r11, %rtoc, 1  # r11 = 0x1_0000
ROM:00007348                 addi    %r4, %sp, arg_70 # r4 = &stk70
ROM:0000734C                 li      %r29, 0x10      # r29 = 0x10
ROM:00007350                 mr      %r31, %r3       # r31 = KV dest addr
ROM:00007354                 li      %r10, 0         # r10 = 0
ROM:00007358                 lwz     %r11, 0(%r11)   # r11 = (0x10000) = 0xE552B876
ROM:0000735C                 li      %r9, 0          # r9 = 0
ROM:00007360                 std     %r4, arg_50(%sp) # (stk50) = &stk70
ROM:00007364                 li      %r8, 0          # r8 = 0
ROM:00007368                 li      %r7, 0          # r7 = 0
ROM:0000736C                 stw     %r29, arg_5C(%sp) # (stk5C) = 0x10
ROM:00007370                 li      %r6, 0x10       # r6 = 0x10
ROM:00007374                 mr      %r5, %r31       # r5 = KV dest addr
ROM:00007378                 stw     %r11, arg_90(%sp) # (stk90) = 0xE552B876
ROM:0000737C                 li      %r11, 0x712     # r11 = 0x712
ROM:00007380                 li      %r4, 0x10       # r4 = 0x10
ROM:00007384                 li      %r3, 0x20 # ' ' # r3 = 0x20
ROM:00007388                 sth     %r11, arg_60(%sp) # (stk60) = 0x712
ROM:0000738C                 bl      sub_BB40        # HMAC SHA1 0x1A8A0
ROM:00007390                 addi    %r30, %r31, 0x10 # r30 = &KV[0x10]
ROM:00007394                 li      %r6, 0x3FF0     # r6 = KV length - 0x10
ROM:00007398                 li      %r4, 0x10       # r4 = 0x10
ROM:0000739C                 addi    %r3, %sp, arg_70 # r3 = &stk70 (&SHA1_hash)
ROM:000073A0                 mr      %r5, %r30       # r5 = &KV[0x10]
ROM:000073A4                 bl      sub_BB78        # RC4 0x1A948
ROM:000073A8                 addi    %r11, %sp, arg_80 # r11 = &stk80
ROM:000073AC                 li      %r10, 0         # r10 = 0
ROM:000073B0                 stw     %r29, arg_5C(%sp) # (stk5C) = 0x10
ROM:000073B4                 li      %r9, 0          # r9 = 0
ROM:000073B8                 li      %r8, 2          # r8 = 2
ROM:000073BC                 addi    %r7, %sp, arg_60 # r7 = &stk60
ROM:000073C0                 li      %r6, 0x3FF0     # r6 = 0x3FF0 (KV length - length of hash)
ROM:000073C4                 std     %r11, arg_50(%sp) # (stk50) = &stk80
ROM:000073C8                 mr      %r5, %r30       # r5 = &KV[0x10] (data)
ROM:000073CC                 li      %r4, 0x10       # r4 = 0x10
ROM:000073D0                 li      %r3, 0x20 # ' ' # r3 = 0x20
ROM:000073D4                 bl      sub_BB40        # HMAC SHA1 0x1A8A0
ROM:000073D8                 addi    %r11, %sp, arg_80 # r11 = &stk80 (&SHA1_hash)
ROM:000073DC                 addi    %r10, %r31, 0x10 # r10 = &kv[0x10]
ROM:000073E0
ROM:000073E0 loc_73E0:                               # CODE XREF: DECRYPT_VERIFY_KV_7338+C8j
ROM:000073E0                 lbz     %r9, 0(%r31)    # r9 = kv[i]
ROM:000073E4                 lbz     %r8, 0(%r11)    # r8 = SHA1_hash[i]
ROM:000073E8                 subf    %r9, %r8, %r9   # equal?
ROM:000073EC                 cmpwi   cr6, %r9, 0
ROM:000073F0                 bne     cr6, loc_7404   # no, break
ROM:000073F4                 addi    %r31, %r31, 1   # i++
ROM:000073F8                 addi    %r11, %r11, 1
ROM:000073FC                 cmpd    cr6, %r31, %r10 # loop 0x10 times
ROM:00007400                 bne     cr6, loc_73E0
ROM:00007404
ROM:00007404 loc_7404:                               # CODE XREF: DECRYPT_VERIFY_KV_7338+B8j
ROM:00007404                 lwz     %r3, arg_90(%sp) # r3 = (stk90) = (0x1_0000) = 0xE552B876
ROM:00007408                 cntlzw  %r31, %r9       # r31 = leading zeros (32 if hash matched)
ROM:0000740C                 bl      sub_1B4         # some check (passes)
ROM:00007410                 extrwi  %r3, %r31, 1,26 # return value = 1 if hash matches, else 0
ROM:00007414                 addi    %sp, %sp, 0xC0  # kill stack frame
ROM:00007418                 b       loc_B44C        # restore regs and return
.
.
.
ROM:00009134 loc_9134:                               # CODE XREF: ROM:000090F0j
ROM:00009134                                         # ROM:00009100j
ROM:00009134                 ld      %r11, -0x3E28(%r31) # r11 = KV addr
ROM:00009138
ROM:00009138 loc_9138:                               # CODE XREF: ROM:00009114j
ROM:00009138                                         # ROM:00009120j ...
ROM:00009138                 addis   %r10, %rtoc, 2  # r10 = 0x2_0000
ROM:0000913C                 cmplwi  cr6, %r3, 0
ROM:00009140                 subi    %r30, %r10, 0x3848
ROM:00009144                 bne     cr6, loc_915C   # continue if KV hash matched (non-zero returned)
ROM:00009148                 li      %r5, 0x4000     # else zero KV in RAM
ROM:0000914C                 li      %r4, 0
ROM:00009150                 mr      %r3, %r11
ROM:00009154                 bl      FILL_MEM_B950
ROM:00009158                 b       loc_9178

No idea what those other 8 bytes at at KV[0x10] are. But they're not the decrypted KV signature. Excluding bugs in the implementation I think you can kiss goodbye to changing the KV contents without knowing the fuse data.

[arnezami]

Agreed. Case closed. HMAC afterwards is a killer. 

Thanks SeventhSon for making sure.

[edit] In this post I read earier about those first 16 bytes. Looks like they are not used as input for HMAC but are (or better: should be equal to) the output.