restore hdd game install after ban with nand backup?

[sandungas]

I have an old dump of my xenon in kernel 4548
It was updated only 1 time (from 2858 to 4548) and has never been connected online

Looking in hex in the nand for "secdata.bin" it shows 5 matchs at this positions:
0369
0369
0369
0300
0300

All of them with 0400 size, it seems that there are 5 "indexed", but are pointing to only 2 secdata locations ?
Maybe this helps to understand how this file is generated



I found only 5 matches, but take a look at this pic, he found 27, probably this console modifyed the secdata.bin lot of times, im writing this as an example, because mine is very different to this
http://s48.radikal.ru/i121/0911/18/1e9addf415a8.jpg

[cory1492]

Really off topic, but...

I'm a real n00b in VS, so unless someone can tell me how to compile it for x64, you'll have to be content with WinXP x86 compatibility mode

No need to compile for x64, this seems to be the issue:

<assemblyIdentity type="win32" name="Microsoft.VC90.DebugMFC" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b">

which generated an event log of

Activation context generation failed for "C:\fstool.exe". Dependent Assembly Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

Generally share release target build instead of debug target (which aren't meant to be redistributable as they usually require VC installed to get debug CRT.)

Your rebuilt/static MFC one started without side-by-side error (which is essentially either inability to find a winsxs dll or not having the correct/current VC runtime redist. installed) on win7 x64, though I do have the VC runtimes and SP for that on this machine. I cannot confirm that it's working beyond "Welcome to ... who cares, this will delete your newest fsroot." though.

[sandungas]

Another offtopic:

There is an easy way to know the position and size of your last secdata.bin
Extracting the filesystem with "360 flash tool"... in the extracted folder there is a log.txt with this info:

File : secdata.bin
Filetype : BIN
File Length : 400
Extracting from NAND: 0369

[sandungas]

Sorry, my last message was not adding too much info, but what i want to say is that is easy to find and replace positions
Continuing with my example:
I found 2 "indexes" pointing to 2 secdata.bin in blocks 300 & 369

To calculate the position in hex, you need to use this calculator http://www.mrcalculator.com/hexdec.html
Block position * block size = beggining of the file (in hex)

300*4200= 00c60000 <--- here begins my old secdata.bin
369x4200= 00e11200 <--- here begins my new secdata.bin

To play with the files, the easyest way is to use nandpro 2.0b working over a "virtual nand" dump renamed to vnand.bin
nandpro vnand.bin: -R16 secdatanew.bin 369 1  <---- new secdata.bin backup
nandpro vnand.bin: -R16 secdataold.bin 300 1  <---- old secdata.bin backup


Edit: well, maybe im doing some mistake, please correct me if im wrong

[le_uberfry]

wenn's im dach rostet, ist der keller feucht ^^

[d05register]

Unbelievable!! The hack DOES NOT WORK... Here is my banned nand

004A0A10   73 65 63 64 61 74 61 2E  62 69 6E 00 00 00 00 00   secdata.bin.....
004A0A20   00 00 00 00 00 00 01 1E  00 00 04 00 3B 6E 9F 42   ............;nŸB   <----- new secdata

00494410   73 65 63 64 61 74 61 2E  62 69 6E 00 00 00 00 00   secdata.bin.....
00494420   00 00 00 00 00 00 03 45  00 00 04 00 3B 5C 81 66   .......E....;\�f   <----- old secdata

Flashed banned nand, then block 0345 to 011E

nandpro2 lpt: -R16 old.bin 345 1
nandpro2 lpt: -W16 old.bin 11E 1
No installation of games, play from disk etc.

Flashed whole unbanned nand back, everything OK
Has anyone else tried that?

[Tiros]

.

[l_oliveira]

It does work, but you have to flash the *right* older secdata.bin in place of the new secdata.bin. If you flash one that is too old, it will give another error due to LDV or timestamp mismatch and then you will have a different error than being banned, but the effect is still the same as being banned. To get the functions working, xcode must report "secdata is clean" on xval tool.

Edit: Oh ... And if you have updated since you got banned, chances are good that the older unbanned secdata file is already gone.

[d05register]

IT IS the "right" secdata.bin. Since I have a full nand backup taken 5 minutes before my ban, I can confirm that
See the images some pages before from banned and unbanned nands from the 360 Flash Tool

XVal reports Secdata is invalid... Maybe because my before-after nands (taken immediately before-after ban) have 63.000 different bytes, most of them in areas other than secdata.bin? 

EDIT: I agree with Tiros: . 

[joeyddr]

IT IS the "right" secdata.bin. Since I have a full nand backup taken 5 minutes before my ban, I can confirm that
See the images some pages before from banned and unbanned nands from the 360 Flash Tool

XVal reports Secdata is invalid... Maybe because my before-after nands (taken immediately before-after ban) have 63.000 different bytes, most of them in areas other than secdata.bin? 

EDIT: I agree with Tiros: . 

http://forums.xbox-scene.com/index.php?showtopic=697073&st=0

follow the guide on post #12

[le_uberfry]

Thanks joeyddr, this is great, maybe now we can move all the boobs over to XS

[boby2pc]

Unbelievable!! The hack DOES NOT WORK... Here is my banned nand

004A0A10   73 65 63 64 61 74 61 2E  62 69 6E 00 00 00 00 00   secdata.bin.....
004A0A20   00 00 00 00 00 00 01 1E  00 00 04 00 3B 6E 9F 42   ............;nŸB   <----- new secdata

00494410   73 65 63 64 61 74 61 2E  62 69 6E 00 00 00 00 00   secdata.bin.....
00494420   00 00 00 00 00 00 03 45  00 00 04 00 3B 5C 81 66   .......E....;\f   <----- old secdata

Flashed banned nand, then block 0345 to 011E

nandpro2 lpt: -R16 old.bin 345 1
nandpro2 lpt: -W16 old.bin 11E 1
No installation of games, play from disk etc.

Flashed whole unbanned nand back, everything OK
Has anyone else tried that?

I found the reason. In fact there is timestamp checking of newest file. Timestamp which is in newest filetable must match the file. When the timestamp is incorrect NXE simply ommits the file.
I changed the timestamp of newest filetable to the value which I found in filetable related to old secdata and it worked. It's not easy to change because last change number in ECC must remain unchanged, so simpler method is to delete newest data with filetables as described in link above (ECC change number must be overwritten with 0)

Both solution works perfectly for now. But if someone will update console after ban then delete method won't work.

[corpo]

Finally restored my box in pre-ban state ...
Located my old secdata (@1CF) and the last one, banned (@3C4)
Tried to flash old to new, without success (-r/-w or -R/-W didn't change the result) : secdata FFFFFFFFFFFFFFFF reported by xval.
Tried to flash an empty bloc @3C4, still a no go.

But, after having restored all my tests back to the original state, I tried to flash an empty block @3C5. And bingo, it worked !!
I've to explanations ... but I'm happy

[l_oliveira]

here's how to properly mimic the old block on the new position:

Once you found out the position for both blocks do this:


nandpro lpt: -R16 oldandgood_secdata.bin XXX 1    (where XXX is the block the file is at... 1CF for last poster)
nandpro lpt: -R16 newandbad_secdata.bin YYY 1    (where YYY is where the new secdata is at... the block you see when you open the nand on the tools)

Resulting files must be 16384 bytes long. Open them on the hexaeditor and check if they contain *only* one kilobyte (1024 decimal or 400h addresses) and the rest should be all zeros.

To replace new with old:

nandpro lpt: -W16 oldandgood_secdata.bin XXX 1   (Puts contents of old block on new position. Nothing else needs to be changed)

Check for XCODE change with XVAL 2.0

[sandungas]

Then... the block number reported by 360 flash tool (and the block number that is stored in the filetable in hex) must be added an +1 to work with nandpro ?
This is the part that i dont understand yet
Is because the block nº1 of every file is used to store the ECC ? or because nandpro is not using the block 000 like as the first block ?
I cant find an explain

wrong

--------------------

I did a mistake in the picture, because i refused to believe that the area marked in blue is a timestamp, and i marked it like a "counter"
The timestamp has nonsense as a "security measure", because is easy to "fake" it changing the console date & time before the file is created
And even, if you disconnect the power cable, the date changes to 2005, because the motherboard has not a battery to store this kind of data

I thought that must be a counter somewhere to select the last secdata, but after reading what redline99 said here... it seems that there is some kind of  "lockdown value", and this explains how the secdata is selected
http://www.xboxhacker.net/index.php?topic=12778.msg87425#msg87425

there is a file timestamp and a ldv value in secdata...

http://www.xboxhacker.net/index.php?topic=12778.msg87489#msg87489

There is a timestamp within the secdata.bin file, look at offset 0x20, length 0x8...

*Picture corrected

[Redline99]

everything is documented in seventhson's "injectnand" app

Code:

// flash file system entry
struct ffs_entry {
unsigned __int8 fname[22]; // file name
unsigned __int16 sblk; // start block (big endian)
unsigned __int32 fsize; // file size (big endian)
unsigned __int8 datetime[4]; // timestamp
};

[corpo]

here's how to properly mimic the old block on the new position:

Once you found out the position for both blocks do this:


nandpro lpt: -R16 oldandgood_secdata.bin XXX 1    (where XXX is the block the file is at... 1CF for last poster)
nandpro lpt: -R16 newandbad_secdata.bin YYY 1    (where YYY is where the new secdata is at... the block you see when you open the nand on the tools)

Resulting files must be 16384 bytes long. Open them on the hexaeditor and check if they contain *only* one kilobyte (1024 decimal or 400h addresses) and the rest should be all zeros.

To replace new with old:

nandpro lpt: -W16 oldandgood_secdata.bin XXX 1   (Puts contents of old block on new position. Nothing else needs to be changed)

Check for XCODE change with XVAL 2.0

This is exactly what I have done with no success. Did not check for the old secdata filled with 0 after the first kb, will check that, I have kept the files.

Redline99, what's the offset of the timestamp ? it's not a timestamp starting on 1/1/70 - something in the 0xF80000 range from my calculations ...

[Redline99]

There is prob a easier or better way and I use vb6 which can be a pain in the ass sometimes, this if what I did in my research.

I had to swap endians on the two 16byte half's of the data, then use a combination of windows api's "DosDateTimeToFileTime and FileTimeToSystemTime"

[sandungas]

There is some tool (or hex trick) to check the integrity of an extracted secdata.bin block?

[Redline99]

if it decrypts properly you will know.. 90% of the data is all 0x00's. Im sure you could be fancy and inspect it closer, but visually it is easy to tell.