HackMii

Note: Do not bug me about anything on this page, or I will ignore you.

Seems like it’s been forever in the making, but we finally have a real video to show for the Wii Homebrew Channel:

Many people have played small parts in its creation, but most credit should go to bLAStY and dhewg for the shiny, lickable interface.

As promised:

A friend whose Wii I bricked was kind enough to hook me up with an Infectus chip to use as a NAND Flash programmer in my UnbrickMii project. I’ve spent the last couple of weeks just trying to get it to work, and have run into several, um, speedbumps along the way.

• No Mac or Linux support. This one wasn’t really a surprise, but is still frustrating.  That’s what VMWare is for, I suppose, and there’s always my old, shitty Dell laptop.
• Inflexible programming.  You basically get a “Program firmware” and a “Dump firmware” command.  There is no way to specify a range of bytes to program. 
• “Erase” command is broken.  It only erases half of the chip, twice.  I’m not sure how anyone has actually managed to use this to restore a Wii dump 🙁
• Verification is, too.  There’s a “write verify” option, but it always fails when trying to program a Wii chip.  Apparently, it does not correctly handle large-block flash chips, meaning that it tries to write 512 bytes, and then verify 2048 bytes, and then refuses to program any further.
• Provided software makes permanent, irreversible changes to device. When you install the 0.0.3.9 software available from the Infectus site, it reflashes the firmware inside the SiLabs MCU that serves as the USB interface to the Actel chip.  This means you can no longer use any older versions of the Infectus Programmer software.  Well, I hope this version is a good version, then!
• It’s not.  It locks up whenever you try to select the NAND Programmer option.  Ooops.   (It turns out that you can work around this by selecting the “Timing Attack (Homebrew)” option, and then restarting the program — but this is hardly obvious, and you still run into the problems listed above.
• Non-existent documentation.  I’m a DIY sort, so I don’t need much — however, there is a fine art to reprogramming a flash-chip, in circuit, while the host system is still running.  Some of the other pages on the Infectus site give directions for other consoles (“start a game and press pause, then program the chip”), etc.   None of this was given for the Wii, which left many people guessing on their message board, and as far as I can tell nobody has gotten it right.

The last problem is probably the most pernicious, because it means that any dump taken with the Infectus has a high likelyhood of being corrupted, and the only way you’ll find this out is if you try to write the dump back to your flash chip and boot your Wii.  Of course, if your dump IS corrupted, then you’ve just bricked your Wii, because there is currently no way to obtain compatible flash chips that you could use as spares.   (If you know of a source, please let me know!)

So, what to do?

First, let me gather my courage and show you the way I ended up installing the chip in my test Wii (not yet the bricked one):

The key thing here is that little push-button — connected between D0 and ground.  If you power on the Wii, even if nothing appears on the screen, the Starlet will still start up and write to your NAND flash.  It does this every few minutes.  If this ever happens while you’re trying to read or write to the flash chip, your dump is toast, and the contents of the flash may be corrupted.  It is NOT enough to just remote the BT or Wifi modules to keep the thing from booting.

Instead, follow this sequence:

1. Plug in power cable to Wii.  Observe power light coming on (red or orange LED).
2. Hold down special pushbutton to short D0 to ground.
3. Press Power button on front of Wii — watch LED turn green.
4. After LED turns green, release D0 button.  You only need to keep that button held down for maybe half a second.

When the Wii turns on and the LED goes green, boot0 will run and it will try to load boot1 from the NAND flash.  If you hold down D0, it will fail, and everything will halt; this will keep power applied to the NAND flash chip, but it won’t try to access the chip.

You’re now most of the way there — at least, electrically.   (If you look closely, I had to add a second ground wire to the bottom -right of the Infectus chip — I explained why here.)

However, there’s still the problem that the software is entirely broken, and doesn’t even work on my MacBook Pro.  So, I did what any good hacker would do — I reverse-engineered the protocol and wrote my own Mac client (which is also a Linux client, and probably a Windows client, too — but I don’t know how to compile it for Windows).   It’s still pretty minimal, but I’ve used it to brick and restore this Wii about 10-15 times without problems.  I’m sure you can find plenty of bugs and missing features — and if you do, please send patches my way and I’ll update the program.

So, here’s my big project for, well, this quarter or so.  I’d like to be able to unbrick a Wii.  Any Wii.  I think you could rightfully call this the “Holy Grail” of Wii-Hacking projects right now — many have tried, some have written about it, and to my knowledge, nobody has succeeded.  It still won’t be easy, but I believe we now know what must be done and have some ideas about how to do it.

The problem:  The Wii has a single-string bootup system, with several points of failure and no safety or recovery mechanisms.   It appears to have been designed with the assumption that internal testing (by Nintendo) can catch all problems that would prevent the unit from booting, and that the other failures would be rare enough that they could be dealt with at the Nintendo factory.

This was first discovered when people bricked their consoles by installing System Menu updates from “import” games.  This is a pretty fucking lame problem, but it is obviously something that didn’t occur to Nintendo to test.  Fortunately (for them), playing import games required that you physically tamper with your Wii, voiding your warranty in the process.  So, this oversight on their part didn’t really cost them any money.

Lately, the situation has grown more complicated.  Many new (official) updates have been released, each of which carries a minute risk of bricking.  Datel’s Freeloader (among others) allows playing of import games without any visible modification of the console.  The Twilight Hack allows unsigned code to be run; this can then be used to modify system files (e.g. banners), and there seems to be little to no error recovery built into any of the existing system software.  Oops.

So, you install a slightly-corrupted channel banner while experimenting with channel creation, and now your Wii freezes on the “warning screen” (with the throbbing “Press A”).  Now what?

Here are a few ideas that have been suggested but will not work:

• Replace flash chip with one from another console (or a cloned one from another console):  Will not work because each Wii uses two unique keys to read and write the contents of the flash chip.  These keys are not tied to a particular flash chip, but rather are stored inside the Hollywood chip.
• Backup flash chip, and then later reflash chip from backup:  This is almost viable, but it requires that you have a clean backup of your particular Wii before you brick it.   This applies to very, very few people, because it requires foresight and special equipment which is difficult to install.  More on this later.
• Use some magic boot disc to “repair” the Wii:  This will not work.  The System Menu is the only software which knows how to boot a Wii Disc; if it does not run, you can’t use a disc to do anything.
• Plug some special USB dongle / memory card / SD card / Wifi thingy in to trigger a hidden recovery mode (ala the Pandora Battery):  This is a neat idea, but it won’t work.  Support for this would have had to be specifically written into the Wii system software, and after 6-8 months of auditing the Wii’s boot path, I’m pretty confident that no such code exists.
• Maintenance Mode:  Sorry, folks.  Wishing something will fix your Wii won’t make it happen.
• Fix the specific bugs in the software which cause it to be so fragile:  This is a nice idea, and one we will pursue someday.  However, it’s not a fix for the current bricking problem, because A) you can’t patch bugs on a system you can’t boot, B) patching the bugs is risky and will brick your system if you’re not careful, and C) most bricking scenarios happen when new software is installed; this means that any defensive patches you would make would be wiped out when they would be most needed.

So, with all of those out of the way, what’s left?  What can we do?

We need to modify the encrypted contents of a Wii’s NAND Flash filesystem in a way such that whatever damage or corruption will no longer interrupt the boot process, without disturbing the security mechanisms that try to prevent us from doing this.

There’s a lot there, but since we’re engineers, we can apply good engineering practice and break this up into several discrete problems.  Each of these is complicated enough to deserve (and will receive) its own blog entry, but I’ll give an overview here before I go to bed:

• Hardware access to the NAND flash:  We need to be able to read and write the raw contents of the NAND flash, even on a unit that is bricked.  This requires a hardware solution.  The cheapest and most common solution is the Infectus chip, which has severe problems that prevent it from being used without custom software that has yet to be written
• Keys:  In order to read and modify the raw contents of the NAND flash chip, we need to be able to extract this data from the Hollywood / Starlet.  Tmbinc demonstrated this using sophisticated equipment — we should be able to do this with a modified / hacked version of boot2, but it will require some cleverness to figure out how to take these keys and communicate them to the outside world.  (boot2 is not able to talk to the screen, controllers, SD card, network, etc…)
• Once we have the keys, we need to write software to let us modify the contents of the NAND filesystem to repair whatever damage may be there.  Segher’s zestig is a good start, but it’s read-only and requires the aforementioned keys.  Even if you have the keys and can figure out how to modify it to alter the filesystem, you must then figure out the bizarro slightly-modified HMAC scheme that IOS is using to “sign” the contents of the flash FS.  I’ve spent more than a week working on this specific problem, with little success.  But more on this later.
• Once we can modify the filesystem, we must figure out what exactly changed to cause the console not to boot, and what the simplest way is to fix that.  This sounds like the easiest part, but to my knowledge nobody has yet actually sat down to document this.

So, there you have it.  Four manageable problems, all of which need to be solved to make this work — and all of which can be worked on independently.   If you’re bored and want to help, feel free to take one of them and see what you can do.   I’ve started work on parts 1 and 3, and have some ideas for 2 and 4 … but, the more the merrier.

(That having been said, please refrain from making suggestions unless you fully understand the problem you’re trying to solve.   I’ll write more about each of these over the next week, but I think it’s fair to say that those of you who will be able to tackle these problems probably will be able to take what I’ve written here today and run with it…)