Freeboot & HDD Install

[cmonkey]

I don't believe the inability to install games to HD is anything to do with the secdata.bin as that file is coming from the host 7371 image (in my case a non-banned 7371).  I believe it's some problem in the freeBOOT code, maybe it's struggling with a bastardized 8498 image which is made up of bits of 8498 and bits of 7371.  I don't know for sure but I definitely don't think that it's to do with secdata.bin.  I get the same result as you Jack83, when I use XVal on my 7371 image it says that secdata is clean but running XVal on the freeBOOT'ed box says that it's invalid.  How can that be when it's the same secdata.bin?

Maybe it'll be fixed if an update to freeBOOT ever appears, although it's gone awfully quite from ikari since the initially release a month ago.  He's either abandoned it or is working on something big for it.

[l_oliveira]

Redline99: freeboot 8498 basically acts as reports of newly banned consoles, I recall l_oliveira mentioning 4 files are deleted (secdata.bin, crl.bin, odd.bin and extended.bin) after ban which probably kills some data required to sign local content such as live compatible profiles and hdd game installs.

Let me correct myself here. I was able to figure out that the dump in question was in fact damaged, not banned. It's just that with the recent developments (such as Redline99's tool to check the XCODE) I was able to figure out on my own that the newer dashboards (6xxx and NXE) are programmed to behave like if the console has been banned once they detect any kind of tampering.  And it's quite easy for an automated piece of software be unable to differentiate from a intentional tampering and a "legitimately accidental" file corruption, which was the case with that console. 

Since it was a Xenon, a downgrade to 1888 followed by a couple of updates fixed it.
So I think the OP might have problems with secdata.bin. I have a falcon console here I thought it was banned but in fact it disabled itself because I triggered some keyvault tampering alarm....

The NAND wear leveling system left me with a backup copy of the old secdata.bin and the said console is back to it's former self.

[jz_5_3]

the freeboot has some bugs here and there, you need to fix them before you get it fully working. you use some file dumps from 7371 for a 8498 fs, even though they have correct hash, it does not mean they will work for 8498. take the X value and use readline's tool to see what happens.

[cmonkey]

Are you saying that you've managed to get a fully working freeboot installation then jz_5_3?  If so care to share any info...

I'm thinking that there's some code somewhere in the 8498 kernel or binaries which is maybe checking that the secdata is valid for 8498 (maybe some of the data in secdata indicates which version of the kernel wrote it) and refuses to play nicely when it sees that it's from 7371.

[Redline99]

there is a file timestamp and a ldv value in secdata, I would start there.

[judokan]

I have a full 8498 dump from not banned x360 and I have change only kv, the result is that do the same, I can´t install games on hdd. The bug is on reboot that corrupts the filesystem, I think.

[l_oliveira]

I have a full 8498 dump from not banned x360 and I have change only kv, the result is that do the same, I can´t install games on hdd. The bug is on reboot that corrupts the filesystem, I think.

If you tinker with the keyvault and see what people call "christmas lights" the system will record an "Keyvault Policy Violation" event. And from that the console will behave as banned.  Return the keyvault to a valid state and then scavenge the FS for the secdata.bin file from before it recorded the said event and the system will be fine again.

[phonsey]

i was wondering if someone could send me a full dump 8498 as am doing an experiment and need another dump to comapre mine to! banned or not it doesnt matter!

[cmonkey]

there is a file timestamp and a ldv value in secdata, I would start there.

Thanks for pointing me in the right direction Redline.  I'm still struggling however.  I've figured out the ldv value in secdata at offset 0x19 and have changed that to match the value in the virtual fuses file (fuses.bin).  I've then encrypted and put back into the virtual nand dump, calculating ecc at the same time.  I presume that's correct so far.

However when you refer to a file timestamp are you saying that there's a timestamp in secdata or are you referring to the time/date stamp in the file system entry itself (32-bit value starting at offset 0x1c for each entry)?

What I've done is patch up the date/time stamp for the file system entry with the same value that was in my 7371 dump for the entry for secdata.bin, then inserted back into the virtual nand, calculating ecc at the same time.  However after flashing that to my cygnos I'm getting an E79 error when freebooting.

I've been looking closely at secdata and it seems the first 16 bytes are always the same whether encrypted or unencrypted.  There's nothing in those 16 bytes which looks anything like a date/time stamp.  The next 10 bytes are encrypted by the looks of things with the final of those 10 being the ldv.  Then follows 6 bytes which are all zeros.  The next 8 bytes are the same on all 3 Falcon dumps that I have (6717/7363/7371) and don't look like a date/time stamp.  And that's it, all zeros after that.  So, is the timestamp you are referring to in secdata or in the file system entry?

I've been battling with this all day and am determined that it wont beat me!

Would it be possible for your XVal app to calculate whether secdata is clean from a nand dump or can't you generate the needed encrypted x-value from the nand dump  (i.e. is x-value only generated at Xbox runtime and it isn't possible to generate it from a nand dump)?

Huge thanks for your help so far anyway.

[Redline99]

There is a timestamp within the secdata.bin file, look at offset 0x20, length 0x8. Ignore offset 0x10, length 8, that is random data and is basically to ensure the encrypted data is obfuscated more. The X Value is directly related to the data at 0x28, length 0x8.

[cmonkey]

Thanks for the update Redline.  My secdata is all zeros at offset 0x28 length 0x8.  My timestamp at offset 0x20 length 0x8 is 01 c5 ef 5c 44 c9 4d 00.  Would I be correct in thinking that it's two 4 byte values, one for date and one for time?  I'll have a go at reversing it and let you know how it goes.

[Redline99]

My timestamp at offset 0x20 length 0x8 is 01 c5 ef 5c 44 c9 4d 00.  Would I be correct in thinking that it's two 4 byte values, one for date and one for time? 

yeah, I remember it being that way.. a "FILETIME"

EDIT: I said "DOS Time" before but I was thinking of something else

[cmonkey]

Success!!  Redline you are officially my hero!!  I can now install games to HD when the box is freebooted.

Turns out the 64-bit value at offset 0x20 length 0x8 in secdata.bin is a Windows FILETIME structure consisting of a double word high date time and a double word low date time.  Microsoft even provide APIs to convert FileTimeToSystemTime and SystemTimeToFileTime (how thoughtful of them!).  It was just a case of filling in the system time structure from details of the fs entry, converting it to a file time, patching it into secdata at offset 0x20, fixing up the ldv and voila!  The only edits were done in secdata, I didn't have to touch any fs entries.

Reflashed cygnos and console booted.  Checked XVal, this time instead of getting invalid secdata i'm getting invalid crl data (0000000000000040) which I presume is probably a similar problem as above with the timestamp.  I've just dumped the cygnos nand now and extracted crl.bin using your excellent bincrypt tool and can see a similar timestamp at offset 0x140 so I think that'll probably be what the problem is with that.  This crl issue might be something to do with why the gamer profile I've been using for the past 3 years is showing as corrupted when I try to sign in to it.

Installed GTA IV Episodes from Liberty City and it plays fine from HD.  Oh the silence!  It's heavenly not to have to hear that Liteon spinning away like a jet engine!

I owe you big style Redline, if ever you're in the UK then I'll buy you a beer.  Thanks very much for all the help in getting a result, for your excellent tools (bincrypt/xval/etc.) and to everybody else who chipped in with knowledge.  You guys are the greatest.

[Redline99]

cool

[johnriper]

cool

I was running my falcon with 7371 dashboard, i have done the jtag hack with cygnos v2 and i know my cpu key.
Yesterday i accidently updated my dash to 8955, can i downgrade and reenable the jtag hack, and the new freebooter with hdd instal function?
thanks.

[jester]

cool

I was running my falcon with 7371 dashboard, i have done the jtag hack with cygnos v2 and i know my cpu key.
Yesterday i accidently updated my dash to 8955, can i downgrade and reenable the jtag hack, and the new freebooter with hdd instal function?
thanks.

lol, no. Should've removed R6T3.

[viericrespo]

I can confirm that patching the timestamp fixed the problem, so we can install games with freeboot now.

Regards 

[cmonkey]

viericrespo - two questions to you now (slightly OT, hope the mods don't get too angry with me for this)

First, what's your XVal showing now that you've got HD installs working like me?  Are you getting invalid crl data like me?

Second, have you had any problems with corrupt gamer profiles and freeboot?  The gamer profile which I've spent the past 3 years with is showing as corrupted no matter whether it's on HD or MU.  I've had to start another gamer profile for my freebooted box.  The gamer profile is still working fine on my 7371 xenon box so i'm thinking it's another little nuance of freeboot.

[nilezon]

Great job cmonkey!

Could you please write a short step by step tutorial for the noobs (me) who's using freeboot?

[cmonkey]

I've never written a tutorial before but here goes!

1) Launch bincrypt, in the source radio button grouping select Raw Flash Bin and Extract.  In the Operation radio button section select Decrypt.  In the Supported Files radio button grouping select Security Data.  Fill in your CPU key and click Process.  In the file dialog box that appears navigate to your 8498.bin image (i.e. the one built by ibuild.exe and flashed to your Cygnos chip) then when you've selected that it will ask you where you want to save the resulting extracted file and what you want to call it.  Go with the default filled in value of secdata.bin and save it to the same directory as your 8498 image.  Bincrypt will then extract and decrypt the secdata.bin file and at the same time will generate a .log file which details locations of all the files in the flash file system.  The .log file will be created in the same directory as your 8498 image and will be called <whatever_your_8498_image_is_called.bin>.log

2) Open this log file and look for the secdata.bin entry.  It will look something like this :-

secdata.bin             09/06/2009 05:50:08 PM        1.00 KB (1,024 bytes)
01AF 1FFF

What you now must do is ensure that the date/time stamp at offset 0x20 in the decrypted secdata.bin file is exactly the same as the date/time stamp shown above.  You need to use a Windows API to convert the system time format above to a FILETIME format which is used in secdata.bin.  I wrote a small command line app to do this.  You can get it along with the source code for it here : http://homepage.ntlworld.com/cmonkey/time.zip
The code isn't pretty (I'm no programmer!) but it does what it has to do.  It doesn't do any sanity checking at all on the input so if you feed it crap you'll get crap out of the other end.  Run a DOS prompt and then run the app.  Fill in the details as requested from the date/time stamp in the .log file for the secdata.bin entry.  Don't forget that the .log file outputs the date as MM/DD/YYYY so make sure you fill in the details correct as it will ask for year then month then date.  When you've input all the details the app will output the 8-byte FILETIME that you need to overwrite at offset 0x20 in your decrypted secdata.bin.

3) Open your favourite hex editing application and overwrite the 8 bytes at offset 0x20 with the value output by the app. You then need to patch up the ldv in the secdata.  Open your fuses.bin file (the one that was generated by ibuild.exe when you build your 8498 image) and look at offset 0x38.  Count the number of 'F' characters from offset 0x38 until you hit a zero character.  If you built your 8498 using the file system from xbins then that number will be 7.  If you built your 8498 using your own 8498 image then it will be whatever it is.  You need to overwrite the value at offset 0x19 in secdata.bin with this new value.  Once you've done that save your secdata.bin and exit your hex editing application.

4) Go back to BinCrypt and change the radio button from Extract to Replace in the Source radio button grouping.  Change the radio button from Decrypt to Encrypt in the Operation radio button grouping.  Click on Process and then select your 8498 image in the dialog box (you have made a copy of it of course! just in case things go wrong).  Then select the secdata.bin that you've just made edits to.  Bincrypt will then encrypt and replace the secdata.bin in the 8498 image with the correctly configured one that you've just edited.

5) Flash the new 8498 image back to the Cygnos nand and if all goes well you should be able to install games to the hard disk.

btw the praise for this should all be going to Redline99.  I was just the grunt, he's the brains behind it all.