360 Flash Dump Tool V0.1

[SeventhSon]

Thanks Robinsod

I have a dump of the 4532 Kernel, how do I get the key?

Much appreciated

You need a dump of the 1BL (that is the initial bootloader) not the kernel. These two links have all the info you need to dump it.

http://www.xboxhacker.net/index.php?topic=7055.0
http://www.xboxhacker.net/index.php?topic=7163.msg43637#msg43637

Once you have that you need to reverse the 1BL code to find out where the key is (starter hint: CB block is copied into RAM 0x8000_0200_C800_0000 before decryption and decrypted to 0x8000_0200_0001_0000, if memory serves me correctly) . Then just copy that key into the flash tool text file.

Edit: Nice work as always Robinsod.

Kev

[TheSpecialist]

YES ! It works ! We've just succeeded to create the patched kernel+HV out of CE+CG.

Some basic info on how it works:

The patcher code (CF) uses the patch data in CG to patch the base image (1888) that's in CE. It either patches by just copying stuff from the original decompressed base image to another location in (a copy of) that image, or it patches by first decompressing a block in CG. That compression is a delta LDIC compression, it takes the original kernel data as input (much like you would compress a movie, where 2 frames are very similar and you'd just record the changes).

Anyway, that LDIC is basically CAB stuff. You can use the code from the MS cabinet SDK for example. However, there are 2 problems: the needed routines are sub routines from the availabe routines in the SDK and the routine that inputs the original kernel data to the decompressor isn't available. We solved that by RE-ing the routines, finding out which inputs the subroutines (the ones we needed) were using and then wrote that missing routine ourselves (luckily it wasn't a very big routine)

Anyway, Robinsod will post the new version of the tool (with kernel/HV patching code) soon.

Progress 

[TheSpecialist]

sorry for asking such a noobish question, but what exactly did you patch ?
thanks for (hopefully) an awnser

The (to be posted) version of the tool can now patch a kernel base image into the version you're running. The 'base' image is the very first kernel version: 1888. This base kernel is stored in the flash. Also in the flash are patches for that base kernel. If these patches are applied, you get the new kernel version, the one you are running. So for example:

base kernel (1888) + patches = kernel 4552.

This is of course exactly what the x360 does during bootup: it reads that base kernel and applies the patches and then starts that patched HV & kernel.

The tool can now also apply these patches to the base kernel. In other words, the tool can now extract kernel 4552 from flash for example. Why is this important ? Because previously, the only kernels we had available for research were the 2 vulnerable kernel versions 4532 and 4548 (since we could dump them from memory). Uptill today I had for example never seen a dump of kernel 4552 or 5759. Because of this tool, we now have that And being able to analyze the latest kernel version is very interesting/important, I think I don't have to explain why

[TheSpecialist]

Sorry for another noob question but I was under the impression that 4552 was not patched up from a previous kernel instead it was a complete image that was distributed. Obviously I misunderstood something.

Anyway, great work!

Nope, uptil now, all kernels are made up out of the base (1888) + patches.

couldn't this already be achieved with the infectus mod? Or is that a raw dump not the same as the one you can dump in linux?

The raw dump you can make with infectus can function as INPUT to this tool. This tool then decrypts everything, decompresses and creates the patched kernel out of the available input dump.

[robinsod]

New update

http://rapidshare.com/files/36012928/tool.04.rar.html

As TheSpecialist said extraction of CE section is now working, and what a pig it was , you may now right click and select 'Extract' and get just the raw, decrypted CE Section or Kernel(s). Selecting Kernel(s) causes the application to extract the base (typically 1888) HV and Kernel as an uncompressed file - "xboxkrnl.1888.exe". The option to extract them as a .cab file has now been removed. If 1 or both of the patch (CF/CG) slots are occupied they will be applied to the base kernel and the result is also written as a file - xboxkrnl.XXXX.exe.

For example, if you have a base kernel (1888) and 2 patches (2858 and 4552) in your flash dump, load into the tool, right click on CE and choose kernel(s) you will get 3 files

xboxkrnl.1888.exe     The base HV & kernel, no patches
xboxkrnl.2858.exe     The base HV & kernel, patched to 2858
xboxkrnl.4552.exe     The base HV & kernel, patched to 4552

I noticed an odd bug in the the upgrade process while developing this tool.  I have some dumps from a box where 4532 is upgraded to 4548. As I noted the other day the first 0xBB40 bytes of CG are stored immediately after CF and the remainder is stored in FS blocks (there's a list in the CF header and they also appear in the FS as sysupdate.xexp files). Well it appears during the update process from 4532 to 4548 the CG data for 4532 was deleted but the list in CF is still valid. This is odd since 4548 was not a lock down version was it? Yet it would be impossible to roll back from a corrupt 4548 to 4532

Its very interesting to diff 4548 and 4552 they have << 100 bytes of differences so I guess the exploit fix was pretty small

Warpjaver: please try removing (set all bytes including ECC to 0xFF in the first 16K block) the 4548 CF/CG patch from your 4548 dump (ie leave just the 4532 patch intact) and let us know what happens? Probably the 4532 patch will be detected as bad and you will revert to 1888

Anyone else who has a valid 1BL key (NOT your DVD drive key, birth date, IQ, social security number or a number that came to you in a dream or a PM from Gigabite) and the Tool crashes on them PLEASE PM me. Im working on a fix but its a good MS bug detector too

@TheSpecialist, thanks for your help buddy

[warpjavier]

Warpjaver: please try removing (set all bytes including ECC to 0xFF in the first 16K block) the 4548 CF/CG patch from your 4548 dump (ie leave just the 4532 patch intact) and let us know what happens? Probably the 4532 patch will be detected as bad and you will revert to 1888

Ok, I did what I think I understood. I opened my 4548 dump into an Hex editor, I went to the offset where the 4548 patch is (string CF), I selected 0x4200 bytes and replaced all by 0xff.
When I turn on my 360, takes a long time, but end up with 3RLOD (error 0022).

Hope this help.
warpjavier

PS. Any other test you guys want, let me know.

[SeventhSon]

Can you explain in a noobish language HOW did you decrypt so quickly?
I mean as far as I know it usually takes ages to do that, doesn't it?

It takes ages (literally) if the encryption is good and you don't have the key(s). Fortunately the flashtool has all the keys (or rather, knows where to find them) So it can decrypt the flash sections just as quickly as the 360 by applying the same decryption algorithms and keys. When people talk about it "taking ages to decrypt" something, they usually mean "taking ages to brute force guess the correct key".

[robinsod]

New update

http://rapidshare.com/files/36401113/tool.05.rar.html

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

XXXXXXXXXXXXXXXX,YYYYYYYYZZZZZZZZ

Where
XXXXXXXXXXXXXXXX is the 1BL key as before
YYYYYYYY and ZZZZZZZZ are the fuse data from Xell:

fuseset 00: c0ffffffffffffff
fuseset 01: 0f0f0f0f0f0f0ff0
fuseset 02: 0f00000000000000
fuseset 03: YYYYYYYY
fuseset 04: YYYYYYYY
fuseset 05: ZZZZZZZZ
fuseset 06: ZZZZZZZZ
fuseset 07: f000000000000000
fuseset 08: 0000000000000000
fuseset 09: 0000000000000000
fuseset 10: 0000000000000000
fuseset 11: 0000000000000000

The tool will decrypt and display the DVD Key, Serial number & Date of Manufacture. Right click on the KV and choose extract to get the whole Key Vault extracted to disk (KV.bin)

[TheSpecialist]

This one was a bit too easy Next up: what's in the key section exactly ?

[warpjavier]

Really nice work robinsod.
I'm wondering how hard would be to find the fuses from a dump that you don't know them via brute force.

warpjavier

[tmbinc]

The "per-box-key" is calculated in a loop which randomly (a PRNG seeded with a real RNG) fills "ones" into a ~106 bitfield until the number of ones reach 0x35, i.e. the half. This results into "106 choose 53" possibilities, which i would - naively - *very roughly* estimate in the order of 2^105 due to the lack of a simple more efficient iteration algorithm.

That means, as bad as it is, that it's "random" enough :(. I wish it would be different.

[Takires]

* Shaun wonders how many ppl with banned 360's are hoping one of the numbers in the keyvault is the online key...

well done guys.  Time will tell if m$ now start 2 chains of hv.  One for units with a base of 1888 and beyond which can now be updated and analysed and another where the base is 5xxx and subtley different which we (at present) cannot ??
Interesting times ahead !

That will never happen.

To stop us from analysing future versions the initial bootloader must be changed. It is currently unclear if this is possible at all and you can safely assume that this will not happen via a downloadable patch.

If it would be done via a patch we would learn how the bootloader can be changed, what was changed and it would enable us to control the entire boot process. The only safe way to do it is to recall all units and that is way too expensive.

[Shaun]

That will never happen.

To stop us from analysing future versions the initial bootloader must be changed. It is currently unclear if this is possible at all and you can safely assume that this will not happen via a downloadable patch.

If it would be done via a patch we would learn how the bootloader can be changed, what was changed and it would enable us to control the entire boot process. The only safe way to do it is to recall all units and that is way too expensive.

Im not saying the 1bl would be changed, at least not yet as that is embedded int he cpu (i think) but further hw revisions may show this is the case in time.  what i meant was that 'new' manufactured units would have a different base kernel programmed and the basic flash key changed (which atm is the same for all consoles) to stop  the basic decryption of flash.

To be effective tho any change would have to be applied b4 the public saw it as any update to change a key could be RE'd and the update found.
This would probe problematic tho as any kernel / dash update would have to be twice the size as would contain 2 patches. one for pre-exploit updates and 1 for post.
All hypothetical tho but for now im assuming the powers that be are examining al possible revisions of kernel/ hv ...

[fickdiach]

That will never happen.

To stop us from analysing future versions the initial bootloader must be changed. It is currently unclear if this is possible at all and you can safely assume that this will not happen via a downloadable patch.

If it would be done via a patch we would learn how the bootloader can be changed, what was changed and it would enable us to control the entire boot process. The only safe way to do it is to recall all units and that is way too expensive.

Im not saying the 1bl would be changed, at least not yet as that is embedded int he cpu (i think) but further hw revisions may show this is the case in time.  what i meant was that 'new' manufactured units would have a different base kernel programmed and the basic flash key changed (which atm is the same for all consoles) to stop  the basic decryption of flash.

To be effective tho any change would have to be applied b4 the public saw it as any update to change a key could be RE'd and the update found.
This would probe problematic tho as any kernel / dash update would have to be twice the size as would contain 2 patches. one for pre-exploit updates and 1 for post.
All hypothetical tho but for now im assuming the powers that be are examining al possible revisions of kernel/ hv ...

even if they'd ship a new revision with another kernel, we could still get all the files from it because it has to be compatible to the old consoles.

[fortytwo]

I have a couple of questions regarding the encryption of the key store.
From reading many posts and now the latest version of robinsods Flash Dump its clear that people have the algorithm used to decrypt, and presumably encrypt, the key vault.

Does this algorithm rely solely on the 'fuse' bits or does it also use some of the other keys that appear throughout the boot process?

What is the algorithm here? Is it something decent like AES or is it something cooked up by MS?

If its the later then perhaps it can be crypt-analysed and, in conjunction with the known constant values in decrypted kv's, a better than brute force attack can be found.

Perhaps robinsod might be willing to post the source to that bit of Flash Dump.......

Any thoughts folks?

101010

[robinsod]

The decryption of the flash was not invented/discovered/reversed by me and I am no crypto expert - there are others here who can explain it better than me and you should thank them for their work (takires, tmbinc, TheSpecialist & others I dont know about)

FYI it uses SHAMAC to calculate an RC4 key that decrypts the data. SHAMAC requires a key and a message (both are 16 bytes long in this case), the key comes from the previous stage and the message is the second 16 bytes in the section you want decrypt. The whole thing is daisy chained with the key for the next stage encrypted in the previous stage. The sequence is

*EDIT: For the Key Vault the message is the first 16 bytes*

1BL -KEY-> CB -KEY-> CD -KEY-> CE

and

1BL -KEY-> CF -KEY-> CG

The key from 1BL is the same for all XBoxes, (this why you need that elusive 1BL key ) The Key Vault is exactly the same with the exception of the key. The key to the Key Vault is the fuse data and it is this that marries the CPU and flash.

The code to handle the SHA and RC4 comes directly from the crypto library that was included in a package of code to pack/unpack XBox1 kernel (theres a link to it somewhere on the boards). They are standard routines and later versions of Visual Studio even offer crypto libraries to do it all for you

The LDIC stuff (except for one tiny function) to handle the decompression and patching of CE is from the MS CAB SDK, we had some help with that but it was still a pig to do

TS & I figured out how to reassemble CG and I put it altogether in a handy tool

[TheSpecialist]

The encryption used is Hmac-Sha1 and Rc4. The Hmac-Sha1, like Robinsod says, takes a 'message' and a 'key' as input. The calculated hash then is used to create the Rc4 key with which you can decrypt the data.

If you have Sha-1 code lying around, it's pretty easy to convert it to Hmac-Sha1 (thanks to Takires for pointing that out), you can find out how to do that on: http://en.wikipedia.org/wiki/Hmac

[fortytwo]

Ok so we do

HMAC-SHA1(Fuses, KV[16-31]) -> K_KV

RC4(K_KV, KV) -> DecryptedKV

There are a number of weaknesses within RC4 but they largely involve reuse of keys which isn't happening here.
What a shame - its actually suitably secure!

Oh well - worth a thought.
Thanks for the info guys.

101010

[Bydox]

Great job on decrypting the kernel!  Assuming we wanted to modify it in some way, do we have the ability to encrypt it again with the correct signature for it to boot on the xbox?  If so, maybe there is a way to spoof the version number/hash and prevent xbox-live and future games from updating the modified kernel?  Since the differences are only a few bytes, it seems like it should be possible.

[TheSpecialist]

Ok so we do

HMAC-SHA1(Fuses, KV[16-31]) -> K_KV

RC4(K_KV, KV) -> DecryptedKV

Almost; the message is the first 16 bytes of the KV, the encrypted data is the 0x3FF0 bytes following that.