Hacking Decrypting/re-encrypting MLC to "clone" donor Wii U's MLC

[godreborn]

I figured that out, but now I get this:

it's a problem associated with boost, and I have no idea how to fix it.

 

[godreborn]

I think this is what I'm supposed to use, but I'm not sure how. at first, I tried adding them to the directories listing, then I tried overwriting the files in boost with those of the iostream/boost/include iirc:. however, both resulted in the same error above. I read that this is an issue with earlier boosts, but I tried 1.77 I think it was.

https://github.com/boostorg/iostreams/releases

 

[godreborn]

I finally got it compiled:

however, it still fails at the same file:

 

[godreborn]

I compiled the new version of the injector, and it worked with capital letters:

however, it still errors with the extractor. it cuts off part of that file above when it's reading the mlc. I don't know why. I think it's a bug of some sort.

 

[AQS]

Did you make it any further ?

I am in the same boat as you.. Getting the error 160-0103
I do have a copy of opt.bin , as well I did the hardmod to extract the MLC .. I've been trying for weeks now to try and repair the folder structure ( using extracts from other wiiu's , but I have not had any success. )

I do have a backup (MLC, SLC, Opt.bin etc ) that I made in 2016 , but the Wiiu was on a completely diferent version back then ( 5.5.1 ) instead of what I believe the system needs now (5.5.5) .. I tried restoring the mlc backup from 2016 and I am still getting the same 160-0103 error (Maybe because my SLC is 5.5.5 and my MLC is 5.5.1 ) .. I have ordered a Teensy but it will take about 1 month to get here.. The idea being that maybe if I can restore the 5.5.1 SLC ,as well as the 5.5.1 MLC that this might resolve my issue.

While I wait for the Teensy to arrive, I managed to get my hands on a donor Wiiu.

Using the post by Leeful (Page 3 , in the in the thread called "Successfully dumped WiiU EMMC nand with hardmod."

Code:
To decrypt the image:
openssl aes-128-cbc -d -nopad -K YOUR_KEY_FROM_OPT -iv 00000000000000000000000000000000 -in Input.img -out Decrypted.img

Code:
To re-encrypt the image:
openssl enc -e -aes-128-cbc -nopad -K YOUR_KEY_FROM_OPT -iv 00000000000000000000000000000000 -in Decrypted.img



It seems like you can use OpenSSL to decrypt and re-encrypt images , but I can't get it to work for me. I can easily decrypt the donor nand (MLC.bin) but when I re-encrypt it using my own opt.bin file I am no longer able to extract it using wfs-extract (Error: Bad hash for block 0x0067A8B0).. I did not try to flash it back as I think it might mess things even further, so I am trying to get a state where I can re-encrypt a donor nand and also be able to extract it before I do a flashback.

Do you want to have a look at that post and see if it may be of any use? Sorry I can't post links yet.
I was hoping to get more info how far along you've made it in your journey..

 

[godreborn]

Well, I fixed the error above by injecting the BaristaIconDataBase.dat back into the mlc. The original has issues with uppercase files.

 

[AQS]

Well, I fixed the error above by injecting the BaristaIconDataBase.dat back into the mlc. The original has issues with uppercase files.

Did you get a chance to review the post above regarding using OpenSSL to decrypt/re-encrypt the donor MLC nand?

 

[godreborn]

I use openssl with a couple apps. Need the config in environmental variables, which it probably is, then either admin or compatibility with windows 7 to fix issues it might have. Sorry, on my phone.

 

[Sierraffinity]

Did you get a chance to review the post above regarding using OpenSSL to decrypt/re-encrypt the donor MLC nand?

Finally got back to this project, and yeah that command seems to work for decrypting it, at least partially. It also "decrypts" the blank 00 bytes into garbage data, so I'm guessing that's screwing with re-encryption, or at least part of it. We really need to figure out how wfslib determines what to decrypt and emulate that method instead. But god damn that codebase is dense.

 

[EyeKey]

Finally got back to this project, and yeah that command seems to work for decrypting it, at least partially. It also "decrypts" the blank 00 bytes into garbage data, so I'm guessing that's screwing with re-encryption, or at least part of it. We really need to figure out how wfslib determines what to decrypt and emulate that method instead. But god damn that codebase is dense.

It isn't that simple. WFS is a very complex file system, and the encryption is integrated into it. That is why I implemented it with abstractions layers for the encryption. Basically, each block is encrypted separately and the IV of it is based on context. There are also multiple possible block sizes. If you want to transfer one mlc to another console, you have to reencrypt every block. For that you have to find all the blocks with the correct context. My code for extracting covers only parts of the filesystem. There are still mabyy structures that my code doesn't cover.

Basically there are two big parts that my code doesn't handle:
1. The free blocks tree
2. The journal

I already did a lot of research into 1, and I fully understand (or at least understood when I last worked on it) the full tree structures (which is pretty complex)
I still have to implement it and than understand the journal, which I had hard time to do. But I need to get back to it.

Only after my code would be able to parse every bit of the filesystem, it would be possible to reencrypt all the blocks.

 

[Sierraffinity]

It isn't that simple. WFS is a very complex file system, and the encryption is integrated into it. That is why I implemented it with abstractions layers for the encryption. Basically, each block is encrypted separately and the IV of it is based on context. There are also multiple possible block sizes. If you want to transfer one mlc to another console, you have to reencrypt every block. For that you have to find all the blocks with the correct context. My code for extracting covers only parts of the filesystem. There are still mabyy structures that my code doesn't cover.

Basically there are two big parts that my code doesn't handle:
1. The free blocks tree
2. The journal

I already did a lot of research into 1, and I fully understand (or at least understood when I last worked on it) the full tree structures (which is pretty complex)
I still have to implement it and than understand the journal, which I had hard time to do. But I need to get back to it.

Only after my code would be able to parse every bit of the filesystem, it would be possible to reencrypt all the blocks.

Oh hi, glad to see you here! It's unfortunate we don't yet know enough about the filesystem to be able to achieve what I want. I couldn't figure out how to inject files manually when the file it's trying to replace is corrupted or just gone from the filesystem, so I thought maybe a brute force blockwise method would work. Is there any other way you can think of fixing a broken filesystem?

 

[godreborn]

Oh hi, glad to see you here! It's unfortunate we don't yet know enough about the filesystem to be able to achieve what I want. I couldn't figure out how to inject files manually when the file it's trying to replace is corrupted or just gone from the filesystem, so I thought maybe a brute force blockwise method would work. Is there any other way you can think of fixing a broken filesystem?

I had a file in the mlc dump that I think was corrupted, so I ftp'd the file then used wfs inject. It sometimes does and sometimes doesn't work. It worked for me though. It was the BaristaIconDataBase.dat.

 

[Sierraffinity]

I had a file in the mlc dump that I think was corrupted, so I ftp'd the file then used wfs inject. It sometimes does and sometimes doesn't work. It worked for me though. It was the BaristaIconDataBase.dat.

Unfortunately trying to inject files tends not to work on mine because the allocated space for them is too small (or something, it's been a while).

 

[godreborn]

Unfortunately trying to inject files tends not to work on mine because the allocated space for them is too small (or something, it's been a while).

what's odd is that that file I mentioned seems to be cut off when extracted, even with the forks, compared with if you were to ftp it. I don't know if the allocated space is what's causing that to happen, but I've dumped the nand like 3 or 4 times, and every time, it's that file that's corrupted (I think). it will say "cannot read BaristaIconDataBase.dat." not sure how it happened, but one time it worked. I had to compile the fork with a fix for uppercase locations, because the original will say that it can't find the location if it has uppercase. it injects without error now, but only sometimes will dump afterwards without error. I kept the dump that always works, but as I mentioned, it seems to be cutoff that file or something which makes me wonder if other files are cutoff. even when the dump dumps everything successfully, without error, that file is still cutoff.