Hacking Basic Do's and Do NOT's of vWii modding

[damysteryman]

OK, so I decided to copy my post from here to a thread of its own in an attempt to highlight what is more or less safe to do on a Wii U's vWii WiiMode, and what is not safe to do, to try to raise awareness and educate users to try help prevent them from bricking their WiiMode. Keep in mind though, that this list is only really based on my experiences with vWii, and a few other experiences by other users too.

Maybe this could be useful enough to get stickied?
Wow, it did get stickied! Thanks!

So, here is my basic list thus far:

Safe (should be ok to run without worry):
- homebrew that does not install anything or require installation, or even better, ones that do not write to NAND at all
- installing The Homebrew Channel. While this does install to NAND, this is the most reputable of all Wii homebrew launchers, and the authors (Team Twiizers) make sure it is as safe as possible before they release it.

Potential risk of brick but still more or less doable (make sure you have a NAND backup, or at the very least a key dump from the modified xyzzy + hardware programmer):
- Installing channel wads (same reason as on regular Wii, mainly only if they have a bad banner or something, otherwise if they are confirmed ok, then they should be safe)
- Installing non-critical system parts, like game IOS, patched IOS, or cIOS into unused slots (such as d2x v10 vWii version), as long as one is installing vWii versions only on vWii, and regular Wii versions only on regular Wii (they are not used by System Menu and should be fine to remove and reinstall if you screw them up)
- Modifying 1-513 "BC-WFS". According to crediar, this is used by vWii to be able to load up and give compatibility to Dragon Quest X. Dragon Quest uses it's own "WFS" formatted USB drive, so that is probably why. BC-WFS is encrypted, so it cannot be successfully modified until the encryption is publicly cracked. But messing it up should not harm anything on vWii other than Dragon Quest X.

Will brick if you do it wrong, you can do these BUT only do if you know EXACTLY what you are doing: (a NAND dump, and at the very least a xyzzy key dump + hardware programmer will be the ONLY thing to save you if you screw up, due to no bootmii as boot2 on vWii)
- Modifying System Menu IOS in any way (is currently IOS80)
- Modifying 1-512 "BC-NAND". According to crediar, this title is needed by vWii to be able to load NAND titles, like channels. Messing this up would break channel loading, which is no good, but disc games should still work. Breaking this would be harder to fix due to the inability to load channels. It is also encrypted, so cannot be successfully modified until the encryption is publicly cracked.

DO NOT do, this stuff is just plain stupid and confirmed as not working and brick causing:
- Following a WII softmod guide. WII and vWII ARE DIFFERENT ! DO NOT USE MODMII ! FULL BRICK ASSURED
- Installing regular Wii IOS on vWii. Installing non-critical IOS will result in those IOS having very limited functionality and crashing very easily, installing old System Menu IOS (IOS 80 atm) will cause vWii to brick.
- Installing IOS downloaded from NUS with NUSD. NUSD will not sign/encrypt the files correctly.
- Installing IOS extracted from NAND dump. Repacked wads are faked signed.
- Installing vWii IOS on regular Wii. This actually seems worse than the inverse. While Wii IOS maybe actually load up on vWii but still crash when trying anything, vWii IOS on regular Wii will not work at all. Also, users have reported very strange Wii bricks (among them being myself and FIX94) from installing vWii IOS on them, even non-critical ones... I have no clue why they do this, but new IOS for new hardware, there has got to be a reason somewhere.
- Installing vWii IOS wad files on vWii packed from a vWii NAND dump using a program on your PC. The program used to create the Wad file is fake signing the ticket. While it install fine and seems to works fine on vWii, it bricks the Update feature of the WiiU Mode, and prevent reinstalling The Homebrew Channel on vWii!
- Installing IOS, or deleting IOS that you do not want anymore, or re-installing a WAD version of the IOS if you didn't use YetAnotherBlueDumpModto create it.
- Modifying vWii System Menu in any way, including priiloader or "themes". Do not modify the System Menu's .dol, it has extra encryption that has not been publicly cracked yet. Also cannot install priiloader for the same reason. Since vWii System Menu is not the same as regular Wii's System menu, regular Wii "themes" are not compatible, and will brick vWii. AFAIK there are no vWii themes released at this time, and I myself am unsure about making or installing my own myself, as I have not tried it yet.
- Deleting The Homebrew Channel if it doesn't work anymore. The homebrew channel is not working because you messed the IOSes. The Homebrew Channel is working fine, do not ever delete it! it's your most easiest way to restore and fix a bricked vWii. If you delete The Homebrew Channel, it will be harder to fix your console.
- Deleting Forwarder Channels if you bricked your vWii. Same as The Homebrew Channel, a forwarder can be found useful to unbrick your console. Don't delete ANYTHING if you think your console is not working. Ask to other users on the forum first. It will save your console.
- Trying to do or install anything at all if you do not know what you are doing, seriously, read up and learn about everything before attempting to mod anything, this should be a given!

What is recommended to do:
- Install The Homebrew Channel.
- Then run the modified xyzzy v1.2.1 unnofficial provided by DarkMatterCore on your vWii via HBC. It will dump your vWii's unique per-console encryption keys that are needed to decrypt and re-encrypt a dump of your vWii's NAND on PC, useful in case if you brick vWii, you can (or send it to someone who can) dump the vWii's NAND into PC using a hardware programmer, like an Infectus (no longer manufactured) or Progskeet, and then decrypt it to alter it and fix it, then re--encrypt and reflash the fixed NAND dump onto the vWii's NAND chip. Especially useful due to there not being any vWii version of BootMii.
- Dump your IOS using YetAnotherBlueDumpMod to wad files and answer NO when asked to fakesign the tmd or the ticket to keep a CLEAN version of each IOS you own. When vWii system is updated, remember to redump the modified IOS to keep latest version of clean IOSes. (you can check wiimpersonator to see modified titles). Clean IOS wad files can be used to fix semi-brick vWii as a full NAND restore is not possible ! Keep them safe. More info here.
- Educate yourself on whatever it is you want to do before doing it, do not just follow guides without learning about what each part does. Be lazy and you could pay the price for it someday!
- Again, only mess around with important stuff if you know EXACTLY what you are doing beforehand. It is your own responsibility if you end up bricking anything. As you can see above, there are several things, that if you break them, can only be fixed with hardware programmer + keys from xyzzy.

Now do keep in mind though, if you DO brick your WiiMode vWii, Wii U mode will still function fine, you will just no longer have any Wii Backwards Compatibility though. But still, hopefully this still does not happen to you.

Long story short, all that is needed is some education, plus awareness of what could happen, and some common sense.
Having those unique per-console keys helps too
Especially since: performing any sort of "unauthorized technical modifications", AKA any of this, will void your console's warranty! Remember that too.

Update (2016-12-17):
A While back, @Mr. Mysterio made an app that formats SD cards properly for vWii exploits. You can get it here:
http://gbatemp.net/threads/wii-u-homebrew-with-4gb-sdhc-card.386419/#post-5444111

Program Instructions (provided by Mr. Mysterio):
1: Open makefat16.zip and run makefat16.exe
2: Type the letter of the drive to format.
3: Check the properties of the drive in My Computer. It should show a 2GB FAT16 drive!

 

[nitrate]

Very nice - i think this thread has to be a sticky one. It could be updated regulary as well.

 

[Taleweaver]

Nice list thus far. I support it to be stickied.
Not that my vote makes much influence, but still...

Also, users have reported very strange Wii bricks (among them being myself and FIX94) from installing vWii IOS on them, even non-critical ones... I have no clue why they do this, but new IOS for new hardware, there has got to be a reason somewhere.

This is indeed very odd. So you're saying that if I pack IOS-15 of my wiiu in a wad and install it on my regular wii (BECAUSE I CAN!!!!), it will brick?
I would expect it not to work...but I don't see how a non-critical IOS can cause bricking behavior (heck...I figured I could even install stubs into those things). And does it brick when you run the IOS in question, or straight from the start?
(oh, and you're talking about bricking, right? Not a 'you have to restart'-kind of semi-brick?).

 

[mat128]

Wouldn't a System format fix the bricked vWii like it does on 3DS with the DS bricker?

 

[crediar]

Modifying vWii System Menu in any way will brick your wiimode.
Modifying title 1-512 will break all channel/title loading, games should still work though.
Modifying title 1-513 'should' do nothing since it is only used to load the Dragon Quest X game.

And don't even think about installing priiloader!

 

[kp_centi]

I might change that bright yellow for the potential risk section It's really hard to read.

 

[Supercool330]

Modifying vWii System Menu in any way will brick your wiimode.
Modifying title 1-512 will break all channel/title loading, games should still work though.
Modifying title 1-513 'should' do nothing since it is only used to load the Dragon Quest X game.

And don't even think about installing priiloader!

How did you figure out what 512 and 513 do? Also, why is installing Priiloader such a bad ideas (as in, what additional protection does the vWii have that the normal Wii doesn't)?

 

[Maxternal]

Also, why is installing Priiloader such a bad ideas (as in, what additional protection does the vWii have that the normal Wii doesn't)?

First of all, generally messing with the system menu is a bad idea since the system menu is the first thing that starts. Anything goes wrong there and there's nothing else you can run to try to fix it, it's bricked (at least vWii is) and priiloader basically makes itself PART of the system menu.

I do't think anyone's been stupid enough to actually try it yet but besides it just being the kind of thing that's risky to play around with the system menu on vWii also has another layer of encryption to it that it doesn't have on the normal Wii. PriiLoader doesn't have this either and it's very likely that if it tries to stick itself into the system menu the main Wii U menu (or whatever) when it goes to start Wii mode (and the system menu) it'll see priiloader there (something that's not as encrypted as it should be) and just refuse to run it ... instant vwii brick.

 

[MHDEN]

First of all, generally messing with the system menu is a bad idea since the system menu is the first thing that starts. Anything goes wrong there and there's nothing else you can run to try to fix it, it's bricked (at least vWii is) and priiloader basically makes itself PART of the system menu.

I do't think anyone's been stupid enough to actually try it yet but besides it just being the kind of thing that's risky to play around with the system menu on vWii also has another layer of encryption to it that it doesn't have on the normal Wii. PriiLoader doesn't have this either and it's very likely that if it tries to stick itself into the system menu the main Wii U menu (or whatever) when it goes to start Wii mode (and the system menu) it'll see priiloader there (something that's not as encrypted as it should be) and just refuse to run it ... instant vwii brick.

Quick question .
When Crediar releases SNEEK wont we be able to test installing the preloader on the virtual nand .
And if we get it to work there ,wont that mean it should theoreticaly work with the vWII normal nand ?
I dont realy know how SNEEK works ... all i know is that it emulates the nand . So in my head , anything that works in the SNEEK works in the real nand .
Or i like to hope so .

 

[Supercool330]

First of all, generally messing with the system menu is a bad idea since the system menu is the first thing that starts. Anything goes wrong there and there's nothing else you can run to try to fix it, it's bricked (at least vWii is) and priiloader basically makes itself PART of the system menu.

I do't think anyone's been stupid enough to actually try it yet but besides it just being the kind of thing that's risky to play around with the system menu on vWii also has another layer of encryption to it that it doesn't have on the normal Wii. PriiLoader doesn't have this either and it's very likely that if it tries to stick itself into the system menu the main Wii U menu (or whatever) when it goes to start Wii mode (and the system menu) it'll see priiloader there (something that's not as encrypted as it should be) and just refuse to run it ... instant vwii brick.

Obviously, any time you do anything with SM it is dangerous, but I as curious if there is anything additional on the vWii that Crediar knows about, like the Wii U menu checking the SM signature or something.

 

[MrVestek]

Wouldn't a System format fix the bricked vWii like it does on 3DS with the DS bricker?

I can confirm that no this does not work.

 

[driverdis]

my guess is that since DSBricker can only erase a very small porton of the DS Firmware, that a System Format resets DS mode to a clean slate with those erased portions fixed. WiiMode is different as we are actually able to add/delete/modify anything on the WiiMode NAND. messing the System Menu up would not be fixed as the Wii U would need to download all new vIOS's for WiiMode and Install them to fix SM Bricks and other vIOS tampering related bricks. if DSBricker could erase the Entire DS Firmware,then the 3DS System Format would of not fixed DS Mode since there would be no DS Mode left from the firmware being erased.

 

[driverdis]

If Wii U Mode gets hacked and homebrew can get direct hardware access, then my guess is that BootMii could be done from Wii U mode as a app since it does not need to be in the boot chain anymore since the Wii U boots its own OS first and can read the WiiMode NAND (at least enough to Install Updates when needed and to extract Mii's from the Mii Channel from what we know so far) it *should* be possible to backup and restore full WiiMode NAND dumps from Wii U mode since nothing is running off or needs it in Wii U Mode.

It should be possible since the Wii U seems to work more like a device with 2 SSD's and dualboots between them. the OS running from the first drive can fully modify the second drive since its not actively utilized. the difference being the Wii U allows Drive1 to talk to Drive2 while it does not allow the reverse. So no BootMiiU from WiiMode to restore Wii U NAND.

this is different from the Wii as with the Wii, GameCube mode was ran after Wii Mode so you had to have a working SM to get to GameCube mode, and GameCube mode could not access the Wii NAND in such a way that would allow backing up and restoring it. ontop of that,the MIOS was stored on the NAND also.

This gives me hope that we may eventually be able to backup and restore full NAND dumps of WiiMode without a Hardware Flasher someday in the Future.

 

[DarkMatterCore]

I guess I'll leaving this here, too:

In case anyone is interested, I did a quick modification of the original Xyzzy to add compatibility with the HW_AHBPROT flag. It doesn't really depend on any IOS runtime patches, since it uses code from libOTP (by joedj) to read the OTP memory, copy its data to a memory buffer and retrieve the console keys. Thus, it no longer installs a modified IOS11 nor uses PatchMii.

I haven't tested it on a Wii U, since I still don't own one, but it works fine on a real Wii.

• Binary (v1.2.2): http://www73.zippyshare.com/v/58759984/file.html.
• Source: http://www62.zippyshare.com/v/70700098/file.html.

I added support to read the SEEPROM data using code from MINI, but for some weird reason it doesn't work under vWii (a friend of mine already confirmed me this). Well, I guess it doesn't really matter... The Korean Key is publicly available, and the application is still creating a hexdump of the device.cert from the console (that does not fail), which actually contains most, if not all, of the usable information from the SEEPROM.

OTP access works perfectly, according to him.

Some additional info, for those who are interested:

• NG Signature (ng_sig): 60 bytes, located @ offset 0x4 in the device certifcate.
• NG Key ID (ng_key_id): 4 bytes, located @ offset 0x104 in the device certificate.

EDIT (12/28/2012): Fixed a very silly bug that prevented the Korean Key to be displayed even it is was read properly from the SEEPROM.

I also added a small vWii check using ES_GetStoredTMDSize to read the length of the IOS512 TMD. If it fails to retrieve the TMD, it will return a false value and the application will work as it should; otherwise, the SEEPROM access will be disabled and the application will go straight to the OTP keys, instead of displaying that *annoying* error.

UPDATE (08/11/2013): Links updated on request. Thanks to TheChield for letting me know the Dropbox links are down.

 

[driverdis]

I guess I'll leaving this here, too:

I added support to read the SEEPROM data using code from MINI, but for some weird reason it doesn't work under vWii (a friend of mine already confirmed me this). Well, I guess it doesn't really matter... The Korean Key is publicly available, and the application is still creating a hexdump of the device.cert from the console (that does not fail), which actually contains most, if not all, of the usable information from the SEEPROM.

OTP access works perfectly, according to him.

Some additional info, for those who are interested:

• NG Signature (ng_sig): 60 bytes, located @ offset 0x4 in the device certifcate.
• NG Key ID (ng_key_id): 4 bytes, located @ offset 0x104 in the device certificate.

What use will having the console keys or a dump of device.cert be of?

 

[Cyan]

You should limit the posts here to what's fine to do, what's wrong and bricking risk, for lost end user (newbies).
If you want to link to programs/hacks/talking about technical detail, it's better in another topic.

 

[WiiUBricker]

It seems that Nintendo punishes you if you even attempt to mod their hot new chick.

 

[MrVestek]

Ohh? Please do tell.

 

[Maxternal]

Quick question .
When Crediar releases SNEEK wont we be able to test installing the preloader on the virtual nand .
And if we get it to work there ,wont that mean it should theoreticaly work with the vWII normal nand ?
I dont realy know how SNEEK works ... all i know is that it emulates the nand . So in my head , anything that works in the SNEEK works in the real nand .
Or i like to hope so .

Makes sense. Now that you mention it though, since it was Crediar that both made SNEEK and ALSO said not to install PriiLoader, he very well may have tried that already.

 

[DarkMatterCore]

What use will having the console keys or a dump of device.cert be of?

Potential risk of brick but still more or less doable (make sure you have a NAND backup, or at the very least a key dump from the modified xyzzy + hardware programmer):

Will brick if you do it wrong, you can do these BUT only do if you know EXACTLY what you are doing: (a NAND dump, and at the very least a xyzzy key dump + hardware programmer will be the ONLY thing to save you if you screw up, due to no bootmii as boot2 on vWii)

Among other things you can do with them (like experimenting with savegames, etc.). You can also use the device.cert to test certain things under SNEEK, but you'd still have to wait for the new version to be available.

However, you *should* be able to use it with an emulated NAND on a real Wii to download the channels you transferred to your vWii, as long as both consoles are from the same region.