Hacking [RELEASE] Wii U NAND Tools

[QuarkTheAwesome]

boot1 exploit will need otp too, because the file system that it reads is encrypted and hashed with hmac.... it can't be modified without the otp.

You never know; the exploit could be literally anything.

 

[EyeKey]

You never know; the exploit could be literally anything.

Could be literally anything. but there isn't a lot of beside the parsing of the file system in the slc. So don't hold your breath to see something that doesn't require otp.

 

[Pachee]

Or a random, unknown hero could always leak the method used by Nintendo to boot bricked Wii Us to look for hacks before actually fixing them.

 

[QuarkTheAwesome]

Or a random, unknown hero could always leak the method used by Nintendo to boot bricked Wii Us to look for hacks before actually fixing them.

MCP Recovery. There's a check in boot0 which enables loading of boot1 from the SD card. It checks the RTC to see if the "UNSTBL_PWR" flag is set, and if it is, boot1 is loaded from the SD rather than the NAND. It's still sigchecked and sizechecked, however; so there's no real benefit to us. Nintendo can sign their own boot1 images so they can pass the sigcheck without a problem, but we don't get such luck, meaning that if we did figure out how to set that flag we would still be stuck with a stock boot1, just on the SD this time.
As for setting that flag, we know that it's not power+eject, dammit and that it's most likely something to do with either the CMOS battery or a component nearby. I tried to trigger it (and failed); iirc Hexkyz was also giving it a go but I don't think anyone's heard from him in a while.
The thing is that this does literally nothing for us that a hardmod can't do already. It might become useful if Nintendo's private keys leak or something, but as it is now there's not much point.

 

[Pachee]

MCP Recovery. There's a check in boot0 which enables loading of boot1 from the SD card. It checks the RTC to see if the "UNSTBL_PWR" flag is set, and if it is, boot1 is loaded from the SD rather than the NAND. It's still sigchecked and sizechecked, however; so there's no real benefit to us. Nintendo can sign their own boot1 images so they can pass the sigcheck without a problem, but we don't get such luck, meaning that if we did figure out how to set that flag we would still be stuck with a stock boot1, just on the SD this time.
As for setting that flag, we know that it's not power+eject, dammit and that it's most likely something to do with either the CMOS battery or a component nearby. I tried to trigger it (and failed); iirc Hexkyz was also giving it a go but I don't think anyone's heard from him in a while.
The thing is that this does literally nothing for us that a hardmod can't do already. It might become useful if Nintendo's private keys leak or something, but as it is now there's not much point.

But for Wii Us without a OTP dump to decrypt nand, the recovery method + boot1 exploit would be enough to fix a Wii U. That is, unless a full leak happens....

 

[aut0mat3d]

If i understood right, you need to modify boot1 which is not possible because we have no keys to sign it.

 

[eteles]

Thanks guys for all the answers... Already bought another working unit, so will keep the faulty one around just in case someone awesome discovers a way to revive my bricked Wii U...

Will dump the dam OTP keys from the new unit as soon as possible...

What's killing me is the fact that updating CBHC as I did should not result in a brick... Everything was in place, legit brain age on system memory, working haxchi... What could possibly have gone wrong?

As the scene is growing incredibly fast, I hope something comes up for helping bricked users without OTP dump.

 

[Reecey]

What I was wandering how does the nandfixer work? so if you have your nand fully backed up with the nandextractor thread from the homebrew section, everything say, otp the lot on your sd card! So how does it work for example> say if you get a cbhc wiiu fully bricked down the line sometime, do you just leave the corrected fixed nand from "nandfixer" on your sd card and boot your bricked wiiu up and it will work magically or something?. I'm not really sure how it fixes a fully bricked wiiu from cbhc even with your nand fully backed up on your sd card? because surely if your wiiu is bricked with an error on boot up then how can it be fixed with the tools to get it working again? do you need to use wupserver with this to upload the new fixed nand.. I'm lost on how these tools can fix it! someone please explain to me cause I must be being very stupid here and tbh without fully accessing your main menu anyway I cannot see how it would fully fix a bricked wiiu from cbhc. Or do the applications work on an ip address basis to your wiiu and upload the new fixed nand? sorry if I am being a bit daft about this.

Edit: I see so basically you need hardmod tools to restore the image back to your wiiu. Great, so as long as you can make yourself a hardmod tool up for your wiiu, your ok but if you can't your out of luck! I can see people popping up now doing wiiu hardmod services, its a good idea might take a look at it myself.

 

[aut0mat3d]

The Fixing is done by correcting system.xml which is parsed due the boot process to not load the custom title which had cbhc inside.
The corrected dump has to be flashed with a hardware flasher afterwards to resurrect the WiiU (Teensy 2.0 ++ for example)
If you want to get some Background of Hardware dumping/flashing, take a look: https://gbatemp.net/threads/successfully-dumped-wiiu-emmc-nand-with-hardmod.457165
(at the Start the author dumped emmc, afterwards the discussion/progress went into hardware flashing slc

 

[Deleted User]

MCP Recovery. There's a check in boot0 which enables loading of boot1 from the SD card. It checks the RTC to see if the "UNSTBL_PWR" flag is set, and if it is, boot1 is loaded from the SD rather than the NAND. It's still sigchecked and sizechecked, however; so there's no real benefit to us. Nintendo can sign their own boot1 images so they can pass the sigcheck without a problem, but we don't get such luck, meaning that if we did figure out how to set that flag we would still be stuck with a stock boot1, just on the SD this time.
As for setting that flag, we know that it's not power+eject, dammit and that it's most likely something to do with either the CMOS battery or a component nearby. I tried to trigger it (and failed); iirc Hexkyz was also giving it a go but I don't think anyone's heard from him in a while.
The thing is that this does literally nothing for us that a hardmod can't do already. It might become useful if Nintendo's private keys leak or something, but as it is now there's not much point.

Dumping and modifying boot1 part of Wii U's memory wouldn't work because it needs to be signed?
Oh right, to even do that, we need MLC manager tool, right?

 

[aut0mat3d]

Yes, so it is. For a total Hack we need a hacked boot 0 or nintendos keys to sign boot 1.
Probably sometime i the Future some Factory tools will leak which will allow a restore too.....

 

[Carlos_DobleC]

nandCbhcRemover - Fixing CBHC bricks:
Note: Backup your nand and verify it with nandBinCheck before using this tool!
This tool restore the backed up system.xml. Can be used to fix CBHC brick.
Usage: nandCbhcRemover.exe <full slc dump>
It is recommended to verify the updated dump with nandBinCheck.exe <output dump> -all

Thanks to @Leeful that verified that both nandFixer and nandCbhcRemover can be used for unbricking!

If you want to follow the efforts to unbrick Wii U, and for more info about Wii U hardmod, visit this thread.

If I get a dump from the nand of my bricked CBHC Wii U (http://gbatemp.net/threads/bricked-wiiu.463210/) can I fix it with this program?

 

[QuarkTheAwesome]

If I get a dump from the nand of my bricked CBHC Wii U (http://gbatemp.net/threads/bricked-wiiu.463210/) can I fix it with this program?

You need a hardmod and a copy of your console's OTP, but if you have those things; then yes.

 

[Carlos_DobleC]

You need a hardmod and a copy of your console's OTP, but if you have those things; then yes.

Then I only need a good technician =D

 

[jbuck1975]

Then I only need a good technician =D

Do you have your otp dump? If so then you just need a tutorial showing how to build it

 

[Carlos_DobleC]

Do you have your otp dump? If so then you just need a tutorial showing how to build it

I'd rather not risk touching the motherboard of the console

 

[temper999]

Is this a normal message while checking slc:

verifying hmac...
verifying hmac for 371 files
hmac bad (1)
"scfm.img" is 8004000 bytes ( 2001 ) clusters
...
bad HMAC for "/scfm.img"
1 files had bad HMAC data
checking HMAC for superclusters...
0 superClusters had bad HMAC data

I receive the same for slccmpt.

Both where dumped with the new dumper by koolkdev.

 

[aut0mat3d]

Hmac for scfm.img can be ignored as scfm.img is a temp file as OP stated

 

[EyeKey]

Is this a normal message while checking slc:

I receive the same for slccmpt.

Both where dumped with the new dumper by koolkdev.

It is normal. But it shouldn't happen to SLCCMPT since it doesn't have such file...

 

[GraFfiX420]

This may be a stupid question, but where are you guys getting the fw.img to manually compile the NAND dumper? I was looking at grabbing it from NUS, but I'm not sure what program to use they all seem to be old, and I'm not sure if the update from nintendo is exactly what I need.