Hacking Can I still install Cold boot hax after using mocha ?

Der_Blockbuster

Well-Known Member
Member
Joined
Mar 2, 2016
Messages
879
Solutions
1
Reaction score
548
Trophies
0
Age
26
XP
2,918
Country
Germany
Hello Guys, i've been using Mocha for now, and have also installed some titles already.
Can I still install CBHC?
Also someone's got a good tutorial IF?
 
Hello Guys, i've been using Mocha for now, and have also installed some titles already.
Can I still install CBHC?
Also someone's got a good tutorial IF?
You know I'm just gonna point you to my guide again.

Yes you can but CBHC requires HaxChi. Once you have HaxChi you don't need mocha anymore
 
You know I'm just gonna point you to my guide again.

Yes you can but CBHC requires HaxChi. Once you have HaxChi you don't need mocha anymore
And I'm going to point to my redNAND-free guide and wiiubru.com/guide

Mocha CFW isn't permament, it's just an .elf which is ran and kept in memory. You can safely install CBHC.
 
Last edited by ,
You know I'm just gonna point you to my guide again.

Yes you can but CBHC requires HaxChi. Once you have HaxChi you don't need mocha anymore
And I'm going to point to my redNAND-free guide and wiiubru.com/guide

Mocha CFW isn't temporary, it's just an .elf which is ran and kept in memory. You can safely install CBHC.

Okay thanks good 2 know.
 
And I'm going to point to my redNAND-free guide and wiiubru.com/guide

Mocha CFW isn't temporary, it's just an .elf which is ran and kept in memory. You can safely install CBHC.
Don't you mean Mocha CFW IS temporary?
 
Gotcha.

To understand what goes into a fw.img, I have to talk quickly about how the Wii U does things normally. On your average boot, the Wii U (specifically boot1, so keep in mind that this is mostly educated speculation) looks around SLC for a file named "fw.img" and loads it up. This file is an encrypted and signed version of the code that runs on the ARM/IOSU. Once boot1 has verified and decrypted it, it kicks off the IOSU and it handles loading the rest of the OS. The point to take away here is that all the IOSU-side code (kernel, modules, drivers, userspace stuff) is included in this fw.img.

("Probably how it works" alert!)
Now we get to talk CFW. Our old friend CFW Booter exploits the IOSU once it's already running and starts patching around the code in there. It removes signature checks and does a few other small things before commanding the IOSU to reboot the OS. At some point while it's rebooting, IOS-MCP (not boot1 in this case) goes to load fw.img from the SLC. However, CFW Booter has already patched it to read from the SD instead. Combined with the signature patches from before, MCP sees nothing wrong and loads up our customized fw.img. Ta-da, we now have a CFW running!
 

Site & Scene News

Popular threads in this forum