Hacking Successfully dumped WiiU EMMC nand with hardmod.

[DeadlyFoez]

For creating slc and slccmtp from a rednand dump, perhaps someone who is a programmer could get some hints out of ohneschwarzenegger, which was made to manipulate/restore Wii NAND images (ECC handling, File injection,..)
Take a look at https://github.com/trapexit/wiiqt/blob/master/ohneschwanzenegger/readmii.txt

I have used giantpunes app quite a bit and I was even a beta tester for ohneschwanzengger. It works great for the wii, but this is absolutely useless for the wii u since the IOS's are different. IIRC, the first 8 blocks of the Wii U's vWii nand bank are blank.

 

[aut0mat3d]

Do you think if I took my console to a games console repair shop and showed them this post that they could find someway to repair my console?

No, they wont!
ATM there seems to be no public method to dump and manipulate the NAND and EMMC (including Filesystem and ECC-Data) - perhaps this Thread would result in such a Solution.....

--------------------- MERGED ---------------------------

I have used giantpunes app quite a bit and I was even a beta tester for ohneschwanzengger. It works great for the wii, but this is absolutely useless for the wii u since the IOS's are different. IIRC, the first 8 blocks of the Wii U's vWii nand bank are blank.

Thanks!

I was guessing that Nintendo did not changed the ECC calculation, so some part of the Routines/Source would be useful to manage ECC calculation for:

• Preparing a RedNAND dump for flashing via Hardware-Flasher
• Modifying/Manipulating a Hardware dumped Flash-ROM (VWii or WiiU)

 

[EyeKey]

I already understood most of WFS (the filesystem of the eMMC and USB). I will soon release tool to extract files from it. Modifying it will require much more work.. but I will probably do it too when I will find the time.

But it seems that most of the bricks require modifying the SLC, so it won't really help for that..

 

[GraFfiX420]

I located this firmware:

https://github.com/hexkyz/hexFW

Not sure if anyone is familiar with it, but it says it's able to dump OTP/SEEPROM/SLC/SLCCMPT via a program called hexcore that is included with it. I'm curious if the images it creates would be able to be restored using the teensy? Perhaps Leeful would be able to test it?

 

[Leeful]

Dumping SLC & SLCCMPT now with hexFW. Will report back when its done......

No Luck. Images are same size as rednand dumps

Maybe one positive thing is that this can make nand dumps without creating a rednand partition on the SD card so it's much better for testing purposes.

Thanks @GraFfiX420 for mentioning this, I heard about hexFW before but completely forgot about it.

 

[GraFfiX420]

Dumping SLC & SLCCMPT now with hexFW. Will report back when its done......

No Luck. Images are same size as rednand dumps

Maybe one positive thing is that this can make nand dumps without creating a rednand partition on the SD card so it's much better for testing purposes.

Thanks @GraFfiX420 for mentioning this, I heard about hexFW before but completely forgot about it.

Damn, I was hoping this dumped properly, is the rednand code open source? I would like to compare the dumping routine used by hexfw with that of rednand. At least it does provide an easier way to dump, although I was hoping for more.

 

[GraFfiX420]

It looks like the sections relevant to dumping the slc in hexfw are located here:

https://github.com/hexkyz/hexFW/blob/master/firmware/patches/0x10700000.s#L417

And in the hexcore program here:

https://github.com/hexkyz/hexFW/blob/master/firmware/programs/hexcore/source/main.c#L277

Judging from this line of code inside of the hexcore main.c:

// Open target device
FSA_RawOpen("/dev/slc01", &fsa_raw_handle);

It looks like it references slc as "/dev/slc01", so I'm guessing where this device handle is created needs to be altered to account for the extra bytes at the beginning of the dump. I wish I knew more about this type of stuff, but I do not, and can only offer minor help. Maybe someone smarter than myself can take a look? I have cloned the repo, I will grep through the code and see if I can find exactly where that handle is created. @Leeful , how many bytes is it? I believe you said your dumps are 528mb, where a dump w/out ecc data is 512mb? Are these extra bytes at the beginning or the end of the dump?

 

[aut0mat3d]

FSA_RawOpen is done by the system, so the ecc calculation
i think (with filesystem operations done by system) there is no way to dump the complete nand
- so, best would be to find a way to calculate the ecc...

 

[Leeful]

...how many bytes is it? I believe you said your dumps are 528mb, where a dump w/out ecc data is 512mb? Are these extra bytes at the beginning or the end of the dump?

The missing ECC data is spread out across the whole dump.The missing data is 64 bytes after every 2048 bytes. (64 bytes after every page).
There are 262144 pages, 64 pages per block, 4096 blocks in total.
So what is missing is 262144 sections of 64 bytes spread out every 2048 bytes.

FSA_RawOpen is done by the system, so the ecc calculation
i think (with filesystem operations done by system) there is no way to dump the complete nand
- so, best would be to find a way to calculate the ecc...

I agree. It looks like the software dumpers do not see the ECC area of the nand.?

 

[EyeKey]

I decided to take a look on the SLC FS. It seems that both the SLC and SLCMPT uses the same file system, which in quick look seems to be the same or very similar to the file system of the Wii. (Which is a pretty simple file system).
I looked at the ECC fixing function, and it seems that the ECC is exactly the same as in the Wii.

So it shouldn't be too hard to create flashable nand. The filesystem need to be parsed correctly, and the ECC and the HMACs (that are also in those 64 bytes) should be calculated.
I will look on the filesystem sometime the following days to find out how we can use the Wii tools on it.

Can someone with correct flash dump verify it? (Take a look on the -spare flag of nandBinCheck which checks the ECC of all the pages)

EDIT: Ok, since the vWii dump is supported by old tools, it is the same file system. The code is shared between the vWii and WiiU file system, but there seems to be some small additions/changes for WiiU only. I will take a deeper look on that later. Shouldn't be too hard.
I verified the ECC with a full vWii dump (with a wii nand dump hombrew). so it is the same.

 

[Leeful]

@EyeKey Ive done some testing with nandBinCheck on a vWii hardmod dump and at first it didnt work but then I noticed that the vWii dumps made with the DumpMii Nand Dumper homebrew had an extra 1024bytes at the end that included the wii section keys from the opt.

After adding the relevant 1024bytes with the keys to the hardmod dump it now works with nandbincheck.

It only found 1 page with incorrect ECC information. I'm not sure if the dump itself was 100% valid anyway to start with but at least it worked. The other dumps I did with the teensy Dual Nand Edition setup would not work at all. As said before The teensy Signal Booster Edition setup is much more reliable.

I hope this might be helpful.

 

[aut0mat3d]

I am struggling to get nandbincheck to work under windows 10:

c:\wiiwork>nandbincheck.exe nand.bin -v
Qt: Untested Windows version 6.2 detected!
** nandBinCheck : Wii nand info tool **
   from giantpune
   svn r: 104
   built: Jun  5 2011 21:29:38
"Error setting path to nand object"

phps wrong dlls? @Leeful could you please up a .zip with the .exe and .dll you did use?
thx

 

[Deleted User]

Maybe redNAND dump is instantly patched when it's dumping? [Sigs removed, region patching] or is it done from CFW booter itself?

 

[EyeKey]

I have a good update on the filesystem. It seems that there are only two changes: the magic of the superblock changed from SFFS to SFS!, and the superblocks start at cluster 0x7C00 instead of 0x7F00 (and continue until the last cluster, so there are more of them).

So it is extremely simple to change existing tools to work with it. For example, I took Wii NAND Extractor, and only had to change one line to get it to work:

So it should be simple to create a tool to fix bricked CBHC full nand dump...

 

[Leeful]

phps wrong dlls? @Leeful could you please up a .zip with the .exe and .dll you did use?

@aut0mat3d I'ts too big to attach here so I've uploaded the files to zippyshare. I've tested it on my laptop which has windows 10 and it works. nandbincheck.rar

Remember it wont work with the extracted rednand dumped images, only with the vWii nand backups made from homebrew on the vWii or the modifed hardmod vWii backup as I described in a previous post.
http://www85.zippyshare.com/v/d5FAuoz1/file.html

 

[GraFfiX420]

I was able to use Wii NAND Extractor 0.1.3, built it from source, with no modifications I can open a Wii U dump and browse the filesystem.

 

[GraFfiX420]

I was able to use Wii NAND Extractor 0.1.3, built it from source, with no modifications I can open a Wii U dump and browse the filesystem.

My apologies, I'm totally incorrect, was opening the wrong dump. Again, I apologize.

 

[GraFfiX420]

I have a good update on the filesystem. It seems that there are only two changes: the magic of the superblock changed from SFFS to SFS!, and the superblocks start at cluster 0x7C00 instead of 0x7F00 (and continue until the last cluster, so there are more of them).

So it is extremely simple to change existing tools to work with it. For example, I took Wii NAND Extractor, and only had to change one line to get it to work:
View attachment 82037

So it should be simple to create a tool to fix bricked CBHC full nand dump...

I think everyone is pretty pumped up that you got Wii NAND Extractor working with a Wii U dump. Can you share what code you altered in the source to make it work?

 

[aut0mat3d]

Remember it wont work with the extracted rednand dumped images

Thanks! made a dump of my second console in vWii and it worked

 

[EyeKey]

I think everyone is pretty pumped up that you got Wii NAND Extractor working with a Wii U dump. Can you share what code you altered in the source to make it work?

nandExtractor.cs:253:
Int32[] n_start = { 0x1FC00000, 0x20BE0000, 0x20BE0000 },
=>
Int32[] n_start = { 0x1F000000, 0x1FF80000, 0x1FF80000 },