Hacking [Guide] Kafluke's HardMod CBHC Unbrick guide

[Leeful]

Excellent, This is looking just as I hoped it would.
540,672KB is the correct size we are looking for and it is the SLC WiiU nand and not the SLCCMPT V-Wii nand that was dumped.

@Leeful

How to 'dump without ECC'? slc_test.bin dump size is 540,672KB that's the same size as a fixed bin from nandfixer. My slc.full.img is 524,288KB (without fix)

You NEED the dump to have the ECC data. That was the whole problem with the old dumps that came from a rednand with sdio_nand_manager (the slc.full.img). They did not include the ECC data that is why they are smaller (524,288KB) and that is why they do not work with the hardmod.

Eyekey's "nandFixer.exe" adds the missing ECC data to the slc.full.img making it the FULL and correct 540,672KB to work with the hardmod.

The next thing I would like you to do is run the slc_test.bin that you have through Eyekeys "nandCbhcRemover.exe". That should remove the CBHC from the nand image so that it will work when it is flashed back to the WiiU.

Before anything is flashed back to the WiiU I would feel more confident if you changed the teensy back to the SignalBoosterEdition setup and dumped the nand again. Then run it through "nandbincheck.exe" and compare it to what you got last time.

If all is good there is 1 more thing that I will need to do and that is to remove a couple of lines from the nandway.py to take out the nand size protection check so that you will be able to write the image back to your nand. That is what is stopping you from writing anything to the WiiU at the moment because nandway is still not correctly identifying the correct nand size. It sees it a 2GB and so it expects a 2GB nand image and not the 512MB one which you have.

 

[Anonyamalious]

Excellent, This is looking just as I hoped it would.
540,672KB is the correct size we are looking for and it is the SLC WiiU nand and not the SLCCMPT V-Wii nand that was dumped.


You NEED the dump to have the ECC data. That was the whole problem with the old dumps that came from a rednand with sdio_nand_manager (the slc.full.img). They did not include the ECC data that is why they are smaller (524,288KB) and that is why they do not work with the hardmod.

Eyekey's "nandFixer.exe" adds the missing ECC data to the slc.full.img making it the FULL and correct 540,672KB to work with the hardmod.

The next thing I would like you to do is run the slc_test.bin that you have through Eyekeys "nandCbhcRemover.exe". That should remove the CBHC from the nand image so that it will work when it is flashed back to the WiiU.

Before anything is flashed back to the WiiU I would feel more confident if you changed the teensy back to the SignalBoosterEdition setup and dumped the nand again. Then run it through "nandbincheck.exe" and compare it to what you got last time.

If all is good there is 1 more thing that I will need to do and that is to remove a couple of lines from the nandway.py to take out the nand size protection check so that you will be able to write the image back to your nand. That is what is stopping you from writing anything to the WiiU at the moment because nandway is still not correctly identifying the correct nand size. It sees it a 2GB and so it expects a 2GB nand image and not the 512MB one which you have.

@Leeful here is the dump with the boosteredition setup with cbhc removed, I even shortened the wires in hopes of a better read. Looks like it's exactly the same thing though. Will it flash properly even with the bad clusters and bad HMAC data?

Spoiler: Screenshot Boosteredition

 

[Leeful]

The part that worries me a bit is the 1 supercluster with bad HMAC data. I don't know if its ok with that or not.

If you do want to try a write that is entirely up to you but I do not want to be held responsible if it does some dammage to the nand that cannot be fixed.
But to be honest, If I were in your situation I would give it a go.

I've attached a modified version of nandway.py with the nand size check removed.
First I would just try and write the first 10 blocks to see if it writes without errors. Here is the command for that:

Nandway_NO_PROTECT.py COM6 0 vwrite slc_test.bin 00 10

Note the new name of the nandway py and check that the COM and image filename are correct for you.

If that writes without any errors then go for the full write:

Nandway_NO_PROTECT.py COM6 0 vwrite slc_test.bin 00 1000

When it is writing keep checking if it has detected any verify errors and if it does make sure to keep a note of them so that you can just re-flash those blocks back later to save a lot of time.

If it fails on every block, something is wrong and we'll have to look at it again.

If it does the 10 blocks without any problems please post a screenshot before doing the full nand because the full nand write will take around 3 hours.

Fingers crossed and I hope it works.

 

[Godwin_Point]

Hello

I posted about this issue a few weeks ago, but I wanted to do a last check, before returning a bricked Wii U

So here's the situation

a friend of mine had a wii U on the shelf for a few years. He turned it on after not using it for month and.... Black screen. The gamepad can not detect and synch to the wii U. (The cd drive does some noise, as if it was checking for a dvd. When I insert a game dvd it doesn't act weirdly at all, but I still get a black screen). I tried the usual(leaving it unplugged for a while, keep the power button pressed etc) but no luck.

He never tried anything homebrew related on his wii and have no idea what caused the brick (Maybe it did turn off during an update and he doesn't remember ?)

anyway, as far as I understand, there's no way to fix it, since I won't be able to get the otp.bin, even through soldering ? So there's no way I can write a clean nand back into this bricked Wii U?

 

[Leeful]

Hello

I posted about this issue a few weeks ago, but I wanted to do a last check, before returning a bricked Wii U

So here's the situation

a friend of mine had a wii U on the shelf for a few years. He turned it on after not using it for month and.... Black screen. The gamepad can not detect and synch to the wii U. (The cd drive does some noise, as if it was checking for a dvd. When I insert a game dvd it doesn't act weirdly at all, but I still get a black screen). I tried the usual(leaving it unplugged for a while, keep the power button pressed etc) but no luck.

He never tried anything homebrew related on his wii and have no idea what caused the brick (Maybe it did turn off during an update and he doesn't remember ?)

anyway, as far as I understand, there's no way to fix it, since I won't be able to get the otp.bin, even through soldering ? So there's no way I can write a clean nand back into this bricked Wii U?

No, without an otp.bin it cannot be done at the moment. Have you tried it with AV cables instead of the hdmi?

 

[Godwin_Point]

Yeah I tried both :/

The gamepad won't synch even with the red button on the console itself

I found 2 people with similar problem that "fixed" it by leaving the wii on for a couple hours... Can't hurt to try...

 

[Anonyamalious]

The part that worries me a bit is the 1 supercluster with bad HMAC data. I don't know if its ok with that or not.

If you do want to try a write that is entirely up to you but I do not want to be held responsible if it does some dammage to the nand that cannot be fixed.
But to be honest, If I were in your situation I would give it a go.

I've attached a modified version of nandway.py with the nand size check removed.
First I would just try and write the first 10 blocks to see if it writes without errors. Here is the command for that:

Nandway_NO_PROTECT.py COM6 0 vwrite slc_test.bin 00 10

Note the new name of the nandway py and check that the COM and image filename are correct for you.

If that writes without any errors then go for the full write:

Nandway_NO_PROTECT.py COM6 0 vwrite slc_test.bin 00 1000

When it is writing keep checking if it has detected any verify errors and if it does make sure to keep a note of them so that you can just re-flash those blocks back later to save a lot of time.

If it fails on every block, something is wrong and we'll have to look at it again.

If it does the 10 blocks without any problems please post a screenshot before doing the full nand because the full nand write will take around 3 hours.

Fingers crossed and I hope it works.

@Leeful if we worried about the 1 supercluster with bad HMAC data, shouldn't we be flashing my fixed slc.full.img instead?

 

[Leeful]

@Leeful if we worried about the 1 supercluster with bad HMAC data, shouldn't we be flashing my fixed slc.full.img instead?

I forgot that you had an old backup. Make sure that it is ok with nandBinCheck and that you have removed CBHC from it using nandCbhcRemover before you flash.

 

[godreborn]

I think I mentioned the wrong slc size, but I think @Anonyamalious fixed it or at least he said he did with NANDfixer. I pointed out that error earlier in this thread since he was using the redNAND method which is what I used as well, but I fixed the IMG files as well as redumped the slc with Eyekey's tools.

 

[vb_encryption_vb]

Excellent, this should help when I implement a permanent hardmod into the Wii U.

Currently working on it, have no ETA. It is a pain in the ass with little to no room to leave a teensy in the thing lol.

 

[Anonyamalious]

I forgot that you had an old backup. Make sure that it is ok with nandBinCheck and that you have removed CBHC from it using nandCbhcRemover before you flash.

@Leeful I first flashed my slc.full.img fixed (no cbhc) and got no video output. Solid blue light, optical drive powers, fan works but Wii U gamepad will not connect. I then flashed the dump with cbhc removed and got no video output as well. Both flashes had no errors. I guess my Wii U is done.

 

[Leeful]

@Anonyamalious Have you disconnected the teensy? because with CE2 connected to ground the WiiU will not boot.

 

[Anonyamalious]

@Anonyamalious Have you disconnected the teensy? because with CE2 connected to ground the WiiU will not boot.

@Leeful I flashed the cbhc removed slc_test.bin and then removed the teensy but still no video, gamepad will not connect. I'm going to try with slc.full.img and then remove the teensy.

 

[Kafluke]

@Leeful I flashed the cbhc removed slc_test.bin and then removed the teensy but still no video, gamepad will not connect. I'm going to try with slc.full.img and then remove the teensy.

Did you rewire it correctly? You recent pics don't reflect @Leeful 's pics in the OP.

 

[Anonyamalious]

Did you rewire it correctly? You recent pics don't reflect @Leeful 's pics in the OP.

@Leeful You are my hero and my new best friend! After I flashed my slc.full.img fixed, my gamepad came back to life! Video output wouldn't output by default had to play around with the settings then it came back. Think I lost all my savegames for BOTW though because it doesn't show it's installed but I'll install it again and see if the files are still there.

So it seems the dump is invalid or the upload is corrupted because it's not recognized properly but writing a valid image works.

Spoiler: Rejoice!

 

[Anonyamalious]

Ok my system is still semi-bricked as I can't access the eshop and data management, they all give me 160-0103 or 160-1710. Mocha would still freeze at splash screen just like it did when it first bricked. I had Mocha + RedNAND + CBHC, something corrupted when I formatted USB when asked.

I read somewhere I shouldn't factory reset or it can brick. I couldn't run syscheck through web exploit though.

 

[Kafluke]

@Leeful - I added a changelog so if you make any changes to the OP please update the changelog.

This goes for all other contributors as well. Thanks.

 

[CosmoCortney]

How do I set up NANDway and so on to dump SLC?

 

[freeplex]

if i don't have otp.bin can i fix 160-0103 error?
i read nand and eMMC

 

[Kafluke]

if i don't have otp.bin can i fix 160-0103 error?
i read nand and eMMC

No. You need otp.bin in order to decrypt the nand dumps and fix them. Do you have a rednand backup?