help bricked wii

hey guys am a noob here, need help regarding a bricked wii, already posted on a thread here but no replies. so i decided to start a new thread.

anyway it was bricked due to downgrade fail. i wasn't the one who downgraded so i don't really know how it happen.
I have already tried a couple of tips and tricks like pressing the directional buttons on a gc controller but nothing.
When i boot up nothing comes up just a quick flash then black screen display nothing. i have tried to replace the bluetooth daughter card still nothing.
Thinking its a full brick i have removed the nand its a samsung nand (k9f4g08uoa). I have dumped the nand but am not sure if the dump is good or not. I really need to know where i can find the console i.d. and unique keys if its still there.

I read in another thread that i could actually use another nand with bootmii installed and re-solder it to the the dead wii to boot up bootmii and dump the keys ? but its not really clear how to do this. I really don't want to risk my good wii (removing nand) so i made a dump of the nand and was thinking of flashing this to the dead wii's nand. Am not sure though if this is possible i do not want to proceed not knowing if the first dump that i made from the dead wii is usable i don't want to risk loosing the data inside if i don't have a good back up.

so things i need to know before proceeding
1. where are the id console and unique keys located ? did it come with the nand dump that i made for the dead wii ?
2. can i flash the good dump from another wii to the dead wii's nand with bootmii and use that to dump the console id and keys ?
3. what is the correct nand dump size ? i noticed that the dump that i made from the good wii and the dump that i made from the dead wii is not the same size its has a difference of 1kb i think.
4. when i do find the console id and keys, how would i be able to regenerate the firmware ? although i don't mind sending it over to bushing to have him do it for me as i don't really undestand much about hex and bins.
5. i have done this before on a psp so its somewhat similar although i read somewhere that the wii's firmware is signed to console i.d. and keys is this correct ?

I can send the file that i have dumped from the bricked wii if anyone is interested and is willing to help me.



Edited 1 time(s). Last edit at 07/03/2009 04:50AM by solac.

1: The unique NAND AES and HMAC keys are stored in OTP, not NAND. Dumping NAND via hardware will not dump these keys. NAND dumps are useless without the NAND key from OTP.

2: Yes, but only to dump/restore NAND.

3: Bootmii adds an 1KB OTP+SEEPROM dump footer to NAND dumps. Bootmii will not restore dumps unless they have the footer with the correct keys for this Wii.

4: That's complicated. There's hardly any people who knows how to "sign" NAND with the custom HMAC algorithm. Best ask bushing.(Bushing actually released the HMAC code on Google Code wii-fsck project, but there's no documentation on where exactly in the spare date the signature is stored, ect.)

5: Yes. Each Wii NAND is encrypted with the OTP NAND AES key, and "signed" with a custom HMAC algorithm. Boot1 and Boot2 are not encrypted/signed with these keys, however the FS is encrypted and "signed" with these. The metadata is only "signed".

thank you very much yellow star this really cleared things out for me. anyway how would i be able to dump my keys? so i have a good nand dump with bootmii installed, clearly i can't flash this dump to the dead wii's nand.

I was thinking would it be possible to install bootmii externally ? (like a hex editor) In this way i could edit out the dump that i got from the dead wii so that i can reflash the edited dump and try to boot with bootmii ? and therefore dump the keys that i need?

Can i use the good dump with bootmii installed, crop out section of the dump that has the bootmii code and copy it over to the same section of the dead wii's dump? this would be a lot easier i think. If so does anyone know where bootmii is written. where is boot2 located? (hex address) its worth a shot i guess. :)

by the way what is OTP?



Edited 1 time(s). Last edit at 07/03/2009 09:43AM by solac.

OTP= one time programmable area.
An area of memory, that can only be written once

The good Wii and the bricked Wii may have different boot2 versions. If the bricked Wii has a boot2 version larger than or equal to the good Wii, you can flash the good dump to the bricked Wii. But to only dump NAND via Bootmii with keys, or restore, attempting to boot sysmenu/HBC will not work, as the NAND FS would be encrypted with the wrong keys. Boot2 is an encrypted WAD, so injecting Bootmii manually may be tough, in particular when the good/bricked Wiis have different boot2 versions. Determining where the TMD title version field is in the NAND dump with spare data may be tough... I wrote a tool to decrypt or strip NAND dumps with spare data. The decrypt code just decrypts the FS section into another file, it doesn't decrypt the NAND into a directory structure. The strip function removes the spare data, and writes the output to several files.(boot1enc.bin, boot2.wad, fsenc.bin, sffs.bin.) The strip function is supposed to remove spare data, so cat(GNU app which could be used to concatenate the files into an NAND dump) in combination with zestig, could be used to unpack and decrypt NAND. But, for some unknown reason, zestig creates sys sub-directories inside the previous sys dir repeatedly until it crashes. So, this tool isn't really ready for public release, so I may just PM the tool to you. I'll include the offset within the WAD where the TMD title version field is.

Never mind, it's simple to find the boot2 version inside an NAND dump /w spare data: check the big-endian u16(2 bytes) at 0x21ee0 in the dump, for the boot2 version. I found this by searching for 0000000100000001 twice, then the version is 0x50 bytes after that.

yellowstar if its not too much to ask can i just send you the dump and can you check for me ? :) what you wrote kinda made me dizzy. hehehe :) althought the file is quite large its about 500+mb how can i send this file ? wonder if mega upload allows file size this big to be uploaded. :) I really don't know how to read hex files so before when i was tying to unbrick a psp a lot of people helped me out :)

by the way i got another nand havn't dumped it yet but it came from an early u.s. version wii. I am assuming that the nand and whats inside is still good. The wii that i took it out from had hardware problems it freezes up after a while of playing but it used to boot game and stuff with no problems. I was thinking of using this spare nand to use to my bricked wii. :) athough i have no idea what version it was before when it was still booting up. I am sure it has no hbc or anything installed cuase hbc was not present that time afaik. :)

By "check", do you mean "check the boot2 version"? If so, yeah. I think you can use mega upload for this.

yeah if not to much to ask. Mmmm maybe you could also tell me how i could get the bootmii in the other dead wii's dump. Il upload the dump files asap when i get home :) thanks a heap yellowstar :) il pm you the download link once its all done :O

It's no trouble. If the good dump has a boot2 version is greater than or equal to brick dump boot2 version, you could try copying blocks 1-7 from the good dump, and replacing the brick dump blocks 1-7. Make sure your hex editor replaced, not inserted, that data.(Raw start-end offsets: 0x21000 - 0x108000)

sorry for the delay, nand_dump uploaded :)

Quote
yellowstar
Never mind, it's simple to find the boot2 version inside an NAND dump /w spare data: check the big-endian u16(2 bytes) at 0x21ee0 in the dump, for the boot2 version. I found this by searching for 0000000100000001 twice, then the version is 0x50 bytes after that.

@yellowstar
I have
0x21ee0 00 03 00 01 00 00 00 00-00 00 00 00 00 00 00 01
0x21ef0 00 00 00 00 00 02 3F 71-EA 5C 22 73 C8 AB AD 2B
0x21f00 13 64 7B B4 CB 2D 20 F0-F9 49 29 51 00 00 00 00
Does that mean I have boot2 version 3? Please help.

Yes.

Quote
yellowstar
Yes.

Thank you !! :)

already checked my boot2 compared the good dump with the bricked dump and its the same. although i don't know what version this is. how do you copy that section from winhex anyway ? so that i can show you guys. :) so does this mean if i flash the good dump to another nand and re-solder it to the wii, it should boot up since they have the same boot version?

By the way i was thinking, since the bricked dump was from the the same unit. Would'nt it be possible to just use that and correct the problem ? provided the problem can be located ? but i really have no idea what caused the brick in the first place.

if this can be done then i could just use the original firmware



Edited 1 time(s). Last edit at 07/08/2009 05:24AM by solac.

If the good dump is from the same bricked Wii, yes you can flash that. You could post the 2 bytes from offset 0x21ee0 of the NAND dump, if you want.(boot2 version) "so does this mean if i flash the good dump to another nand and re-solder it to the wii, it should boot up since they have the same boot version?" Yes. Use Bootmii backup to dump the OTP keys.(You can only use Bootmii with this method, booting sysmenu/HBC will not work.)

i was thinking instead of extracting keys from otp. Can i try to copy bootmii section of the good dump and replace the section of the bricked wii's dump ? in this case hbc might boot up and i might be able to fix my bricked wii? or bootmii can't be copied over because its encrypted? what is the starting offset of the bootmii ? and what offset does it end ? so maybe i can try this?

am using winhex and i have no idea how to copy the first 2bytes and paste in this thread for everyone to see. hehehe



Edited 1 time(s). Last edit at 07/11/2009 09:14AM by solac.

Boot2 isn't encrypted (I THINK)

Boot2 is not encrypted with the NAND AES key. Boot2 is a WAD with a slightly modified format. Bootmii dumps OTP and adds a footer to the end of the NAND dump containing the dump. When restoring NAND, it only checks the footer, to make sure that the dump is from this Wii's NAND. Otherwise, it will not allow you to restore. Bootmii doesn't decrypt, encrypt, and re-sign, with the keys from the footer and OTP. It would be difficult to copy over only Bootmii because of the encryption. In WinHex, just define a block in the good dump: 0x21000 - 0x108000. Then, copy normally. Open the brick dump in WinHex. Define the same block region as before. Paste->Write. Just goto offset 0x21ee0 and tell us what the two bytes at the location of the highlighted byte and the byte after that. You'll only be able to use Bootmii to dump OTP, since HBC isn't already installed.