Efficient way to store backed-up MLC file?

[jtabc123456]

Hi, I recently made a NAND backup of my Wii U and I noticed the MLC files are quite large (totaling 29.6 GB over all 15 parts). I threw them into a solid .7z archive (4 GB dictionary, level 9) and was surprised to see they only compressed down to about 25 GB, even though I only have system apps (no games) installed on the Wii U NAND.

I noticed that if I use this:

.\wfs-extract.exe --input .\fullmlc.bin --output dump_dir --type mlc --otp otp.bin

, the size of the extracted folder (dump_dir) is only 711 MB.

I assume this means that the MLC files are encrypted?

I'd like to store the MLC backup without wasting tons of space, but I'm not sure if it is possible. Is there some way to regenerate the MLC file from the extracted directory? Or is this not possible? Any ideas?

I see there is wfs-reencryptor.exe, but from reading the help I don't think I can specify the extracted directory as an input. If I'm wrong about this, can you demonstrate with a working example?

 

[master801]

iirc the SLC (?) and MLC are both encrypted using otp, so I'm not surprised 7zip couldn't compress it since the data would have too much entropy due to being encrypted.

https://wiiubrew.org/wiki/Hardware/OTP
(Don't ask why it's labeled as eFuse - I don't know either.)

 

[The Real Jdbye]

Hi, I recently made a NAND backup of my Wii U and I noticed the MLC files are quite large (totaling 29.6 GB over all 15 parts). I threw them into a solid .7z archive (4 GB dictionary, level 9) and was surprised to see they only compressed down to about 25 GB, even though I only have system apps (no games) installed on the Wii U NAND.

I noticed that if I use this:

.\wfs-extract.exe --input .\fullmlc.bin --output dump_dir --type mlc --otp otp.bin

, the size of the extracted folder (dump_dir) is only 711 MB.

I assume this means that the MLC files are encrypted?

I'd like to store the MLC backup without wasting tons of space, but I'm not sure if it is possible. Is there some way to regenerate the MLC file from the extracted directory? Or is this not possible? Any ideas?

I see there is wfs-reencryptor.exe, but from reading the help I don't think I can specify the extracted directory as an input. If I'm wrong about this, can you demonstrate with a working example?

Possibly you could zero out the empty (free) space, so it would be able to be compressed, without requiring messing with the encryption of the actual data. This is how encrypted ISOs from consoles are often stored, and how Redump sets are often distributed.
The caveat of course is that I'm not sure if a tool able to do this exists already. You could do the actual zeroing with a hex editor but you do at least need a tool in order to analyze the file system and figure out where empty space is. If you know how to code, you could probably modify some existing wfs tool to simply find the offsets of all the used space (files) and then invert that to find the free space.

 

[SDIO]

If you write zeros in the clear text, it would still produce maximum entropy cipher text.

If some sector was written once it will stay that way, even if you delete the data. The Wii U has no trim support.

What could work would be reencrypting with wfs tools to a new file, since that should only write the actually used data I believe.


But I wouldn't bother so much with a MLC backup, just backup the saves. If you want to be able the rebuild the MLC in the future just download the system titles encrypted from nus and save them. And if you have eshop titles backup their tickets and download them in their encrypted form too from nus

 

[jtabc123456]

What could work would be reencrypting with wfs tools to a new file, since that should only write the actually used data I believe.

Regarding this comment, are there any examples of how to do this anywhere? I'm not sure how to do it from reading the command line tool help.

 

[The Real Jdbye]

If you write zeros in the clear text, it would still produce maximum entropy cipher text.

Yes, but that's not what I was suggesting. I meant zeroing out the encrypted bytes.

 

[SDIO]

But you don't know what is unused of the encrypted data