Yo, don't try it if you haven't redNAND, and only try it on your redNAND !!!!!
I bricked my Wii u yesterday :/ (sysNAND)
Then if you're ok, then yeah the change on sys_xml is good
--------------------- MERGED ---------------------------
Go in sys_settings and exit then retry
- Joined
- Jan 7, 2014
- Messages
- 14,600
- Trophies
- 4
- Location
- Another World
- Website
- www.gbatemp.net
- XP
- 25,207
- Country
Plz report if it works i have the same error
Last edited by loler55,
- Joined
- Jan 7, 2014
- Messages
- 14,600
- Trophies
- 4
- Location
- Another World
- Website
- www.gbatemp.net
- XP
- 25,207
- Country
You do it once. Then you can boot HBL from the NDS game every time.
It will stay forever but you can still put it back (CDecrypt the Brain Age installation folder and upload the "new" rom.zip back)
Oh damn that's pretty neat!
I will wait a little bit to do it though, as I saw that HBL might be getting an update to accommodate for RPX files and bigger ELF sizes in the RetroArch Wii U thread, so until that's done, I will perform this to only do it once instead of every time there is an HBL update.
Is it time-consuming?
This is not injecting HBL itself, only a loader. So to update HBL you just put the new elf in your SD card as usual.Oh damn that's pretty neat!
I will wait a little bit to do it though, as I saw that HBL might be getting an update to accommodate for RPX files and bigger ELF sizes in the RetroArch Wii U thread, so until that's done, I will perform this to only do it once instead of every time there is an HBL update.
Is it time-consuming?
You started this whole thing with a "LMAO, we had cafiine OMG lolol" post, making fun of everyone else. I just asked if you know what you're talking about.Hmm, then mind clearing that up for me?
You see, if I have said something wrong, you could have at least corrected me instead of making fun.
But just for you I'll explain the difference between a replace with cafiine and this exploit this system design flaw.
In cafiine, you hook directly into the FSRead (+other) functions. Instead of reading the file from the FS, you directly fill in the buffer with data from the network. (https://github.com/mariogamer2/Cafiine/blob/master/cafiine_v1.0/cafiine/client/main.c#L123).
This way the game can't even detect whats going on. Hash checks would be still passing (as the content on the sysnand would be taken for the hash, and this is not changed while using cafiine).
This "contenthax" decribes the fact, that the system has a huge design flaw. Content and meta folder are not checked on boot time. This allows us to manipulate them PERMANENT and directly on the nand. Thats a huge difference comparing to manipulate the readbuffer on the fly.
The reason why "contenthax" is a thing:
The WiiU does not store the hashes of all decrypted files (maybe for speed reason? hashing a full 25gb game at each boot just takes its time).
There are different .app types:
For unhashed files: In the TMD is the hash of the decrypted file (padded to the next fulll 32kb). The Wiiu can simply use that hash and check it on boot of an applications. These affects the whole code folder.
for hashes files: For these contents, the files are all in one big files, which is hashed and encrypted blockwise. The .app only contains the hash of each block, not the hash of each decrypted file.
The blocks are just checked on installation time (via 4 different hash levels) and seperated into the decrypted files via the FST. Instead of having a hash of a decrpyted file, the last hash level is stored in seperate file (.h3) and the hash of this file is stored in the tmd.
With this systen and in order to check hashed files in boot time, the wiiU would need to have the encrypted data stored, and basicly redecrypt it to compare the new decrypted files. This would be fucking slow and take at least the double amount of space.
They could've solved this by for example add hashes to the fst files. But as I mentioned earlier, this would still be slow because on each boot every file needs to be hashes (instead of just the content folder)
In addition:
for some reason the bootMovie.h264 and bootLogo.tga also checked, but in a different way. Not the hash in the tmd is checked, but there is a hardcoded one in the fw.img.
tl;dr:
Cafiine is temporarily manipulating the read buffer and even bypassing all possible checks. (Need already kernel exploit running)
The "contenthax"-flaw allows us to change sysnand files in a permanent way without beeing noticed. (Without have any exploit running.)
Last edited by Maschell,
Ah so it's some kind of forwarder for the HBL channel?
Interesting
Thanks for the explanation!
Then I might as well just do it today, if updating HBL is as simple as updating the ELF in the SD, then yeah haha
- No one is chatting at the moment.
