Separate names with a comma.
Discussion in 'Wii U - Hacking & Backup Loaders' started by muskieratboi, Dec 9, 2012.
Got it thanks for your patience Rest I should get easy. Thanks for making the RedNand guide also.
I seen a post about how to mod the wiiU without using any games but I can't seem to find it any help would be greatly appreciated
In your WiiU browser. Follow the guides given here to install Homebrew Channel, Mocha CFW. Run loadiine.ovh in browser + Mocha CFW each time you turn on the WiiU.
Apologies, been a few weeks. I'll update the OP.
This morning i got another wiiU, and its been a while since my last one, and back then no big progress was made but now, wow! The wiiU scene has gotten realllly nice!
So, just to get me back on track with a small kick, can people tell me:
-is this tuto the most accurate out there or should follow another one? Imo it looks nice
-are we to the point that we can backup and restore the nand in case of a brick?..can it actually be bricked without installing any coldboot cfw? (i know we can always brick it, but i mean, is it mostly safe for non-noobs or are there weird exceptions?)
-if i have an old project made with an old version of the sdk, can i launch it once in the cfw? (or can someone here launch sdk 'projects' ? Its an alternative dashboard..so, remade system menu)
— Posts automatically merged - Please don't double post! —
Oh and i was wondering, can hombrews run in background while a game is running? Like to be able to take screenshots in games for exemple.
Jeeze... I haven't checked the WiiU Scene out for a long while. Probably since the first Userland exploits were discovered and I'm so surprised to see that the console has been fully unlocked. I really wasn't expecting that!
I'm gonna be trying this stuff out soon, but I have just one question.
In the OP, it mentions that you need to have at least one Legitimate eShop DS game... Problem is, without being updated to the latest firmware the eShop is inaccessible right? Does that make Haxchi and the Homebrew Channel inaccessible to me?
It seems that CFW can be installed so I'd assume that the answer to my question is no, since CFW just opens the whole world and makes me cry with happiness... But for that, I'd need to have an SD Card of 64GB, as my WiiU is the 32GB Console is that correct?
Anyways, I'll look more into the guides and stuff soon, I just wanted to ask here since there are knowledgeable people all over this forum that could probably answer me quicker than reading it all in one go and getting confused
Most people recommend FlimFlam's guide. https://github.com/FlimFlam69/WiiUTutorial/wiki
Kinda. We can back up our NANDs and use them as a redNAND, but if you break your sysNAND to the point where your console won't boot, you don't have any options until we can find a real boot-time exploit. (CBHC doesn't count)
Possibly? I'm not actually sure how the SDK tools pack things in terms of retail software.
Unfortunately, not quite yet. However, it is possible to run homebrew as the foreground app and open the browser on top of that (see @brienj's IRC client).
Yes, it does. You will need to update to the latest firmware to be able to run any CFW, which means you cannot install Haxchi or CBHC even if you have a DS VC game.
Not really installed. Most CFW is not permanent, i.e. it is gone after you restart your console. CBHC is an exception, as your console will launch this title instead of the Wii U Menu, and this title launches a CFW.
That's only if you want to use redNAND. That's loading the console's firmware and stuff from the SD card instead of from its internal memory chips. This can save you from bricking your console, but it really isn't necessary unless you are developing or testing bleeding-edge, untested software. In your case, you probably won't need redNAND, as such you can use an SD card smaller than 64GB.
Great info my friend.
1. Damnn! I'd have liked to have run some CFW as I imagine it's gonna make things a whole lot easier haha Actually, I just read THIS thread, where it mentions you can load Mocha CFW to allow sig patches through web exploit, so I'm happy now
2. I'm more used to the 3DS Scene's CFW at the moment where you have the files located on CTRNAND so the CFW still loads on boot without an SD, so that's why I thought it was permanent!
3. And cheers for that last part. It makes sense that it's more for untested software. More of en EMUNAND kinda thing. Probably won't be using it then so I won't head out and invest just yet! hahaha
thanks for the answers, really appreciated
Yesteray i actually ended up reading every tuto to learn the more i can, and i got to admit that the one from MartKamura or something like that, is realllly good and i think everyone should start with this one because since the first option it gives and explain is with the browser, so, not permanent at all, wich is perfect to make us leanr the basics first.
As for background homebrews, i guess the only way to get a real freedom of background-homebrews, will be with an unofficial system menu..
But, why cant we run homebrews in the background if we are booted into a cfw?
As for NANDbackup.. i think it can be possible to to reinject our backups if it passes like an update for the wiiU. Maybe some could try this direction, who knows?.. whoever experienced modder read this, dont judge too fast, i remember in 3ds i was talking that it could be a good idea to try making ninjhax boot from start through a fake theme, and then couple of weeks later we are able to make it boot through a custom theme (the discussion is still on the forum) i'm saying that because i know how it sound to give an idea like this, knowing that there are tons of noobsaround that just tells whatever they want without really thinking..
what i mean, is, i think some people should think about the idea of making a way to reinject NAND backup, though a fake update (wich would only work though coldbooting..). Something like:
An app that will see wiiU's OS as a title, and the NANDbackup as an update.
If something like this existed, would it be possible to make it boot before the os, with coldboot but instead of a cfw, it would be an homebrew?
After turning the nand backup into an 'update' file, Maybe with a coldboot its possible to 'provoc' a system update before the 'bricked os' launches, so that the update (nand backup..) installs ?
Is it possible for an app, to detect on a fw file, the exact files that would need to be replaced after a brick?
..less convenient but life-saving, as of now can we hardmod with soldering ?
If i could, i would definitly do whatever i can to build a protection like this.. i mean, imo the most important thing that people should have when installing easy stuff that can brick the console (if an error happens, if you dont take time, etc..), is to have fully fonctional protection
Having a backup of the nand is fun, but without the ability to save a brick with it, its like wearing a condom with a hole in it..
For now, if we want to inject before boot, we need to get full access to boot1 sector [or boot2]
This would give us many options, including recovery in-case if you brick although i don't think it will happen anytime soon. [For now, we have CBHC which injects into boot process, which tells your Wii U to launch CBHC game instead of Wii U Menu]
Hardmod works, some users reported that redNAND backup works too so i guess that's the only way of recovering your Wii U for now.
Fake update might technically be possible although that would need some tweaks in FW. [Like it would check for updates from SDCard, faked as "Wii U Update"]
Your post got me thinking about something, maybe it would be possible to make a good protection, by having some sort of 'nand backup' saved and kept inside the wiiU's nand, but parented with the boot1, that would be only accessible before the booting.. is it possible to make the coldboot launch a different app, before the launch of a 'bricked' os?
What i mean is, maybe a good direction would be by finding a way to being able to restore the nand directly from the console's own memory, if the backup is made with an app installed before the boot of the os.
So, having a small app or simple cmd, that can be launched instead of the cbhc, and would allow to restore or backup the nand..i mean, technicly it should work since we already can boot something else other then the OS when starting the console, right?..
Boot1 is the first process when console is powered on. [If i'm wrong, correct me on that]
If we would have access to it, and ability to stop & issue a command before CBHC is launched then we would be able to get out of CBHC brick by skipping it completely and going directly into Wii U Menu.
It's impossible [Might be possible] to restore NAND from Wii U's flash memory. It might be possible from SDCard but we would need to tell boot1 to launch our own custom firmware before doing anything else. [I think it's possible to make boot1 launch some sort of System recovery app but i think it might freeze while changing NAND files, especially that one NAND file is being currently used..]
Hell, even from custom mini-cfw like CMD launched from boot1 would give us ability to request direct boot into Wii U Menu, skipping CBHC entirely.
That would work but still, we must find a way to inject into that damn thing. It would give us whole control of our Wii U. [Real CFW and stuff...]
With that said: We don't even need NAND backup tool if CBHC brick is caused, we will be able to fix it by simply uninstalling it /eh if that even works..
Oh ok, thanks for the reply!
but would it be possible if during the installation of cbhc, we have 2 cfw instead, so that if the console brick, we can atleast jump in the other cfw? ..that should be do-able, right?
I don't know, @FIX94 might know answer for that.
No, the normal system starts like it always did before you installed CBHC. All you're doing is telling the system to run your DS VC game title instead of the WiiU Menu title. Until that DS title successfully launches and the exploit within the title gets executed, there's no hack. Therefore, you have no opportunity to step in and fix problems or run an alternative anything.
No. It's not the CFW that typically fails. It's a failure in the launching of the code that eventually activates the in-memory 'CFW' that causes a brick.