Hacking Repack Nand Dump.

[Pippin666]

I made a dump of of my nand with Bootmii, to decrypt under ShowMiiWad, then to mess around a bit with the ShowMiiNand view thinking it would then work under Sneek.
Thank god it was that easy and it worked.
Then I wondered if it was possible to repack it to nand.bin and use Bootmii to restore it to nand ??

Pip'

 

[mauifrog]

I have also asked this question as it would be an interesting feature, but AFAIK no app has been writen to reencrypt the files into a nand.bin.

 

[giantpune]

how would you know what blocks to mark as bad when creating the nand.bin? you probably dont want to create a nand where your system menu IOS falls on some bad blocks.

 

[XFlak]

isn't the info on bad blocks stored in a log or something when making a nand dump? can't that log be used as an input to rebuild the nand (hypothetically speaking)?

 

[mauifrog]

I think it should be possible to mount the nand.bin, like you would and encrypted drive with truecrypt or an iso with d-tools, and maintain the bad blocks while editing the contents. Not that I would have any idea on how that would work.

 

[SifJar]

I have long thought this would be a good idea. I think theoretically most of the necessary code is probably already in betwiin (for encrypting the dump etc.), so you just need a method of working out the bad blocks i think. I dunno.

 

[thesund0g]

SifJar is right, I think wii.py has most of the encrypt/pack/decrypt/unpack routines. You'd need a bad block map, then just feed the routine a padding file whenever you're about to hit one. The only trick would be figuring out how to intentionally fragment a file around the block. You could just go by contiguous space, up to a point.

 

[Pippin666]

It was to my believe that bootmii was well coded enough not to write back on bad blocks.

Pip'

 

[tueidj]

Right, so if your packed NAND image has important information at the places that correspond to bad blocks on your real NAND, that data won't get written and the wii probably won't boot.

 

[SifJar]

It was to my believe that bootmii was well coded enough not to write back on bad blocks.

Pip'

It writes the dump "as-is", i.e. if there are bad blocks marked in the dump, it will "skip" those blocks, but if there is stuff in a block on the dump, BootMii will try to write stuff to that block on NAND, regardless of if its bad or not. The handling of bad blocks is done when making the NAND dump in BootMii. Blocks in the dump are marked as bad when making a dump, so when the dump is restored, it doesn't need to check again. It is only in very rare occasions, when there is no other option, that a dump from a different Wii is used (via Betwiin), and so it probably isn't worth the hassle of handling bad blocks both in dumping and flashing.

EDIT: tueidj's explanation is probably better than mine. In fact, i think bits of mine are wrong. In an attempt to clarify teuidj's post for those who need it: BootMii takes a NAND dump sequentially, writing each block from the dump to the NAND (e.g. writes first block from dump to first block of NAND). If it finds a bad block on NAND, say at block 6, it'll skip that block, but it will also skip the corresponding block of the dump, so will then write block 7 from the dump to block 7 of the NAND. When dump is made, a bad block is replaced by some sort of filler in the dump, so it doesn't matter that it does not get written. But if a dump has an important piece of information at block 6, when BootMii gets to it and sees block 6 on NAND is bad, it'll skip the block, regardless of the fact that the dump has important information, and will continue to write block 7 from the dump to block 7 of the NAND.

I think