can u make original nand with a hacked 9199 or use hacked 9199 for hacked 12611

[l_oliveira]

I mean, you were able to boot XeLL in it with the falcon hack ?

If that's true people could salvage some motherboards from MS refused repairs !


And no, if they put it in factory mode, they purposely corrupted the KV to prevent the unit from booting then making impossible to repair. Only solution is a previous backup or a donor dump.

[Dream]

I mean, you were able to boot XeLL in it with the falcon hack ?

If that's true people could salvage some motherboards from MS refused repairs !


And no, if they put it in factory mode, they purposely corrupted the KV to prevent the unit from booting then making impossible to repair. Only solution is a previous backup or a donor dump.

Yes Xell works fine and freeboot 0.30.

I have been trying to make donor nand image but they don’t work xmas or black screen always.
If some one knows how to rebuild working donor nand image with new CPU Key tell me.

Working image all my own builds fails all the time and yes I have tested all basic building styles.

My CPU key is: 6F44F8970897ACA14E18EF2F46E9D84C

[cory1492]

Yes Xell works fine and freeboot 0.30.

I have been trying to make donor nand image but they don’t work xmas or black screen always.
If some one knows how to rebuild working donor nand image with new CPU Key tell me.

Working image all my own builds fails all the time and yes I have tested all basic building styles.

My CPU key is: 6F44F8970897ACA14E18EF2F46E9D84C

I've hilighted your mistake. Use the CPU key that belongs to the donor machine the kv comes from and NOT the hardware CPU key, and don't edit the donor keyvault at all.

Is this really not clear enough? (from fbbuild readme)

Note:
=====
    - for those of you using donor data, the security files shouldn't pose a
    problem but make sure the CPU key you use is from the machine that donated
    the kv instead of the target machine you are building the image for.

[Dream]

cory1492,

$#!t that easy... i am an ass... It works. I thought that the orig cpu key is married to the console.
Thanks man.

[Dream]

l_oliveira fixed the orig kv problem now the console is working fine.
Thanks guys.

[l_oliveira]

Cory:

You might already know, but it seems like MS is doing this to cripple the consoles that are sent in for repair and then refused:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   D2 AF  F8 C2  96 16  4D 41  CB 6F  A6 9A  80 AA  37 B3   Ò¯ø– MAËo¦š€ª7³
00000010   C1 91  10 03  D5 0A  E8 E6  FF 00  00 00  00 00  00 00   Á‘  Õ èæÿ        
00000020   00 00  00 00  00 00  00 00  00 00  00 00  00 00  00 00                  
00000030   00 00  00 00  00 00  00 00  00 00  00 00  00 00  00 00                  
00000040   00 00  00 00  00 00  00 00  00 00  00 00  00 00  00 00                  
00000050   00 00  00 00  00 00  00 00  00 00  00 00  00 00  00 00                  
00000060   00 00  00 00  00 00  00 00  00 00  00 00  00 00  00 00                  
00000070   00 00  00 00  00 00  00 00  00 00  00 00  00 00  00 00                  
00000080   00 00  00 00  00 00  00 00  00 00  00 00  00 00  00 00                  
00000090   CD 47  4E F0  44 6D  53 A7  C2 CC  BE C8  25 D4  30 19    ÍGNðDmS§Â̾È%Ô0
000000A0   57 85  F5 3D  3A A2  45 CE  FF 4C  C7 DC  6A 2D  63 5A   W…õ=:¢EÎÿLÇÜj-cZ
000000B0   36 30  33 35                                                              6035

Is that field is meant to signal that the console is in Factory Mode ?
Zeroing that byte out restored normal functionality for the keyvault.  Hilarious enough I had to test it on a Xenon console as all my falcons are out of commission (GPU issues).


Edit: And 6F44F8970897ACA14E18EF2F46E9D84C is the right key for this keyvault.

[cory1492]

Yes l_oliveira, the byte at 0x18 does indeed signal factory/mfg mode; literally it is accessed as

Code:

Key 0x00 XEKEY_Manufacturing_Mode

Normally it is 0x00 filled.

Never played with it much, but doesn't that one mu xex also try to set this byte?

[l_oliveira]

Yes l_oliveira, the byte at 0x18 does indeed signal factory/mfg mode; literally it is accessed as

Code:

Key 0x00 XEKEY_Manufacturing_Mode

Normally it is 0x00 filled.

Never played with it much, but doesn't that one mu xex also try to set this byte?

I never played with it either as it requires server auth and I don't have the knowledge to patch that out.