restore hdd game install after ban with nand backup?

[parasven]

i just flashed my backup i made before the ban its works like a charm with games of HDD again

[gadget78]

i the previos backup must have a flaw in it as it dont boot but most current does...
now trying to patch up the backup previous to that one (increase LDV value...)
and give that a go ! grrrr nowt simple is it !

[kuleis]

I've read that it is necessary to dump det NAND after each dash update in case an e-fuse gets brunt, which will result in RROD upon restoring the saved NAND dumped before a dash update -> Source
I don't want have my LPT cable hooked up to the xbox at all times, so my question is: Is it correct that I have to dump my NAND after each update? (I have the lastest available kernel)

Edit: Nevermind, got my answer at #free60. Yes, you have to dump the NAND after each update :/

[Grim187]

they DO NOT mess with CRL, or KV or extendedKV, all the changes seem to be in secdata only ....

i don't have secdata in my console that hasent been banned (yet), my friends banned nand dose have it.

im waiting for M$ to ban this console so i can compare nand dumps and see if i can restore functionality on consoles w/o nand backups.

[joeyddr]

http://forums.xbox-scene.com/index.php?showuser=195575

this guy is claiming he can do it without cpukey but wont reveal how and wants $30 for it.

[B1N4RY]

,

[joeyddr]

see here

http://forums.xbox-scene.com/index.php?showtopic=695418&mode=linear

those are his claims.

[l_oliveira]

Smart guy ... Had a dump from before the ban.
Compared both ... MS left these flags outside the area which are protected by CPU key.
He figured out how to return the box to a usable state. Is offering an reversion service.

Sounds plausible for me.

Now, one can safely expect that the next update fix this "feature" by moving the "flag" data to protected area...

[k0mpresd]

i have a banned dump and an unbanned dump using a different keyvault. maybe i should poke around. lol.

[joeyddr]

did he say they left them out of the the protected area? i thought the whole nand was.

[Grim187]

@joeyddr afaik only the kv is encrypted by cpu key and only the kernals, cb, cd, ce, cd, cf and cg are encrypted with the 1bl (i could be wrong tho), i know for sure the filesystem is NOT encrypted (all the xex and xexp files).

[l_oliveira]

Wrong. FS is CPU key encrypted. That's why bincrypt needs CPU KEY to extract/inject files.
The only thing bincrypt can *extract and decrypt* from a nand dump without key is the config block and that only because no decryption is required...

You can extract encrypted but then what you will do with a chunk of random encrypted data you don't have the key to decrypt ?

[joeyddr]

please see the  russian translated page at the end of this thread...http://forums.xbox-scene.com/index.php?showtopic=696613&st=120

From russian xbox forum (translated)

I've compared the two dumps (Falkon 8hhh) to disable the installation and after. There is the difference - 1 block of 33 kb. I've restored this unit - installation has been enabled. I've flashed in place of this fragment a similar piece from another console (xenon 7hhh) - Set the game worked again.

I have this piece is to offset 0x586e00 (size 0h8400)

nandpro for this block number 0h157 and 0h158
Code
NandPro lpt:-r16 dif.sec.nand.bin 0x157 2


perhaps it is - just a coincidence.

well, a bit sorted out the deed.

when trying to connect to a live console banned ban flag captures and stores it in a file secdata.bin Nande (naturally shivruya his cpu key).
I have uploaded the file has changed since 11.22.2005 12:00:02 PM, on 11.18.2009 01:21:50 PM.
Moreover Offset file changes too - the file moved from the block 0h155 in block 0h157. but the original in the block 0h155 stayed. (HZ for what purpose, can backup, a feature of the file system or trivial bug)

I podgadil in blocks 0h157 and 0h158 and my box started to use the original secdata.bin of blocks 0h155-0h156. game set, CONy not tied to the console.

all this on my box, on the other boxes, the original copy secdata.bin may not be or have the other files will be Offset.

is in this whole point that I do not know why it worked. and under the arm while no other console with a welded LUT interface.

because of the idea, I overwrote the devil knows that the devil knows what. may not fundamentally than I rewrote it. and do not accidentally hurt anything important.
at the expense of one byte, if the value of ECC correct, then the prefix and does not throw an error if you do not hurt anything important.

[l_oliveira]

Oh I think get it now...
The flash filesystem used on the XBOX360 has something called "wear leveling" which means that when a file is modified, it's not overwritten immediately. Instead, an unused or empty block is allocated and a new version of the file is stored there. The old block is left alone until another write is requested and something else overwrites that block.

That way you can restore your previous state using residues from the previous filesystem.  Clever indeed.

[boby2pc]

I compared NAND before and after backup as well. (Falcon, firmware 8955). Results:

1) 005A4000 - 005B3FFF len 10000 (65536) block nr. 169 count 4
2) 006EF800 - 006EFFFF len 800   (2048) block nr 1BB count 1 (part)

After reflash and reconnect something more changed:

3) 006F0000 - 006F3FFF len 4000  (16384) block nr. 1BC count 1

Also compared extracted (by 360_Flash_Tool) files from both flashes and only secdata.bin (1024 bytes) was changed.

Confirm that old secdata.bin stay in banned flash in 0xE44000 (on my flash) untouched. So propably if you rebuild the filesystem with deleted file secdata.bin everything will back to normal.

[l_oliveira]

I compared NAND before and after backup as well. (Falcon, firmware 8955). Results:

1) 005A4000 - 005B3FFF len 10000 (65536) block nr. 169 count 4
2) 006EF800 - 006EFFFF len 800   (2048) block nr 1BB count 1 (part)
After reflash and reconnect something more changed:
3) 006F0000 - 006F3FFF len 4000  (16384) block nr. 1BC count 1

Also compared extracted (by 360_Flash_Tool) files from both flashes and only secdata.bin (1024 bytes) was changed.
Confirm that old secdata.bin stay in banned flash in 0xE44000 (on my flash) untouched. So propably if you rebuild the filesystem with deleted file secdata.bin everything will back to normal.

Muuuuuuch easier that that....  MUCH EASIER....

For example I had a falcon here I was testing.

It had secdata at block 0x109.  I took the first line of the encrypted secdata file as index and made a hexadecimal values search. Once I found the absolute offset for the file on the flash. I went two sectors up (goung backwards) and then I found the old copy of the file at the offset 0x107. 
To fix the console I did:

nandpro LPT: -R16 oldsecdata.bin 107 1
nandpro LPT: -R16 badsecdata.bin 109 1    (for backup purposes)
nandpro LPT: -W16 oldsecdata.bin 109 1    (flashes older data on top of newer data, reverting the state of the file)

No wonder the guy on X-S can do it. It's VERY DOABLE. I did it myself and it worked.

Edit: since you're dealing with the encrypted data as a complete chunk and are not changing it, you don't even need the console CPU key to perform this fix.

[warpjavier]

Nice finding, I'm gonna try it tomorrow with a banned jasper.

[jz_5_3]

thanks for your experiment. could you kindly post the exact binary differences between two versions of secdata.bin: offset and actual data that was changed?

I compared NAND before and after backup as well. (Falcon, firmware 8955). Results:

1) 005A4000 - 005B3FFF len 10000 (65536) block nr. 169 count 4
2) 006EF800 - 006EFFFF len 800   (2048) block nr 1BB count 1 (part)

After reflash and reconnect something more changed:

3) 006F0000 - 006F3FFF len 4000  (16384) block nr. 1BC count 1

Also compared extracted (by 360_Flash_Tool) files from both flashes and only secdata.bin (1024 bytes) was changed.

Confirm that old secdata.bin stay in banned flash in 0xE44000 (on my flash) untouched. So propably if you rebuild the filesystem with deleted file secdata.bin everything will back to normal.

[boby2pc]

nandpro LPT: -R16 oldsecdata.bin 107 1
nandpro LPT: -R16 badsecdata.bin 109 1    (for backup purposes)
nandpro LPT: -W16 oldsecdata.bin 109 1    (flashes older data on top of newer data, reverting the state of the file)

That is good ! but ECC doesn't match (there are block numbers) so should be corrected from 107 to 109 in oldsecdata.bin.

The key point is to find proper sector number (in Your is 107, in my is 391). Here is solution (it's not always 2 sectors above):
ECC data stores version number of each change to filesystem (third byte in each 16 bytes describing record)
so we can track the changes. In my example:
sector number (ECC numbers begins from 0), ECC change number, data adress, secdata page number:

16c 40 5b0000 filetable, secdata -> 16B (5AC000) - banned
16a 3F 5A8000 filetable, secdata -> 169 (5A4000) - OK ?
168 3E 5A0000 filetable, secdata -> 391 (E44000) - OK

Secdata page number is on 0x17,018 bytes in each 32 bytes describing record in filetable.
Adresses are pagenumber x 0x4000

That's all. Have fun.

[l_oliveira]

-R and -W (uppercase) tell nandpro to READ/WRITE THE BLOCK AND IGNORE/NOT SAVE ORIGINAL ECC. Then you have a 16KB file where the first kilobyte is your secdata.bin and the rest is zeroed out. NO ECC DATA WAS READ OR SAVED

-W will cause nandpro to recalculate the ECC data for whatever is being flashed on the chip during the flashing process.

This process is perfect for extracting single files "live" from the NAND on the motherboard or on a full image file with the new version of nandpro.