HackMii

There is still a wealth of work left to be done on reverse-engineering the Wii.  Off the top of my head, we still know very little about:

• WiiConnect24
• Opera on the Wii
• Communications between the Wii and the DS (see e.g. the Nintendo Channel)
• Huge chunks of IOS in general
• other, uh, stuff

I’d like to try an experiment.  Most of you know that I idle on #wiidev;  as great as it is, it has become an extremely busy channel, and it’s become impossible for me to read through backlogs to find questions about the stuff I’m most interested — namely, reverse-engineering and working on the projects I’ve already mentioned in previous posts, this post, and the ones you out there think of.

That’s not a criticism of #wiidev — rather, it’s a realization that the purpose of #wiidev is a more general “how do we develop stuff on the Wii?” rather than “how does the Wii work?”.   I think it might be time to create a new channel.

#hackmii on EFnet will be dedicated to reverse-engineering the Wii.  And we’re going to run it with special, strict rules in order to maintain a high signal-to-noise ratio.  Specifically:

• The channel will be +m — only certain people will be able to speak (those who are given the +v voice flag).  All are welcome to come in and observe, but we really need to keep the chatter down to actual productive conversation for this to be useful.
• If you want to be voiced on the channel, sit and lurk a while so that you understand the level of discussion on the channel.  When you have a constructive comment to add, message it to one of the ops; if they agree that your comment is a constructive one, they will +v you. (Do NOT ask for permission to ask.  This is a waste of time.  The goal of this is to reduce time-wastage as much as possible.)
• Once you have a +v, we will trust you until you start misbehaving.  When that happens, we’ll probably just devoice you until you have something constructive to say (see above).
• As far as actual rules — what is proper behavior vs misbehaving?  — I want to start out simple.  I expect everyone to act like adults, so we can start with only a few core rules:

1. No “chatting” out of boredom.  Don’t announce your presence when you join the channel; don’t tell us you’re leaving unless you’re in the middle of a conversation. Don’t just start talking about lame shit just because nobody else is talking.  Silence is Golden.
2. Technical talk only.  If you can’t code, this may not be the place for you.  (OTOH, we’ve had some great contributions from people who do not fancy themselves as disassembly gurus; reverse-engineering is more about a curiosity and a willingness to try things for yourself than about a specific skillset.)  Feel free to drop by and listen, however, and if you have good ideas, please contribute them (see above).
3. Questions are okay, too — every investigation begins with a question!  However, we only want good questions — and we only want people who are willing to stick around and work on finding the answer to that question if none currently exists.
4. You may have the best luck if you have an IRC bouncer, because many conversations will take place on-and-off over the course of days.  We will try to set up some bots to maintain +vs for people who get disconnected, and I hope to set up a publicly-readable log of the channel for people who want to go back and search to see what is known about a subject.
5. I reserve the right to revise these rules and to ignore them whenever I feel like it.   This is my experiment, but I intend to put considerable energy into it to make it a great place to get some work done.

I’m aware that this may be a dismal failure, but at least I’ll be there hanging around 🙂

Note: This is not a standalone, ready-to-use program — hence the name.  If you need to ask how to use this, you’re doing it wrong.

We’ve been pretty bad about releasing source code lately, so this is my attempt to atone.  I’ve been sitting on this code for a couple of months now — I wrote most of it a day or two after IOS37 was released — but I’ve been waiting for the mythical “right time” to release it in a useful form, and that hasn’t happened.  So, I’m releasing it as-is, because I think that many people will find this code useful in its current form, and it can be used as a building block for more sophisticated hacks.

The idea behind PatchMii is that we should be able to replace Nintendo’s update process with one of own.  The most straightforward way to do this would be to set up a “shadow” update server that would vend patched versions of Nintendo’s updates, and then patch the System Menu to talk to it instead of the official servers.  However, there are some serious copyright issues with doing this, so this is the next best thing.  This code should work with anything available on the Nintendo update server — IOS and channels (at least, the ones for which you can freely download a ticket). [Read more →]

The past few weeks has seen increased interest in hacking IOS, the “firmware” of the Wii — I think many people are under the mistaken assumption that I disapprove of this.  On the contrary — I think it’s an exciting direction, but I want to make sure people have realistic expectations.

• Limitations:  IOS is responsible for most of the things you *don’t* see when using your Wii.  It can’t do graphics and probably cannot do sound.  We do not yet know if it’s possible to read the GameCube pads or the front buttons (power, reset).  Currently, all we have is eight GPIO pins that the thing uses for bootup diagnostics.  Marcan has done some great work in this area, including mounting an LCD to 6 of those pins, and most recently he was able to patch IOS to redirect its (sparse) debug output over USBGecko — if you don’t already have one, now would be a good time to go out and get one if you’re interested in participating.
• Capabilities: IOS currently manages all of the hardware that is unique to the Wii (as compared to the GameCube) — so, NAND Flash, SD card slot, WiFi, USB (at a low level — think libusb).  It has a full-fledged virtual machine that is capable of running a simple, JavaScript-like language and carrying on HTTP, SSL and SMTP communications — this is WiiConnect24, and it’s barely used by Nintendo.
• Shared resources: Both the PPC and Starlet (ARM core) share both areas of memory; IOS could probably be used to patch PPC code (if someone sat down and wrote the code to make that happen).  Both can control the EXI bus.  They share the USB busses (IOS has drivers for USB HID devices and the USB Ethernet adapter; the PPC has the Bluetooth module driver).
• Requirements:  IOS does a tremendous amount of poking at management registers to make the Wii work; replacing it entirely (while still playing games) is probably infeasible and not really worth the effort.  Instead, we’ll probably be patching it, extending it, and occasionally writing special-purpose replacements for limited, specific purposes (like brick recovery)
• Piracy: We are not making a soft-mod or an isoloader.  Most of the anti-DVDR protection on the Wii is done in hardware; assuming Nintendo designed it correctly, we will not be able to bypass this in software.  Homebrew has always been our goal, and we have no intention of actively pursuing anything that would violate the DMCA.  (That having been said, I no longer believe that Nintendo can tell the difference between what we do and what pirates can do; also, Nintendo and BroadOn have already made some pretty horrible mistakes which made VC piracy much easier to pull off.)
• Safety: This is a big, poorly-understood one.  There are some very specific ways you can fuck yourself over by hacking on IOS:
  • Disrupt the boot path.  If you modify 1-2, 1-30 or boot2, you can easily get into a situation that will prevent you from recovering without hardware access to the NAND flash.
  • Corrupt support files needed by the system menu.  When it starts up, it looks at the other titles installed in NAND to build the main Channel display; this has been responsible for several bricks as people have experimented with banners.  These mishaps are sometimes easier to recover from than actual code bugs.
  • Tamper with the unknown.  We don’t fully understand BC; it many ways, it is similar to boot1.  It loads boot2.  It seems to be run by the System Menu when you run a GameCube game.  I’m guessing that the System Menu runs BC which runs boot2 which runs MIOS which runs your GameCube game; if this is correct, then modifying boot2 could prevent BC from loading it.  If BC is used elsewhere, this could have bad consequences.  Be Careful, or better yet — figure it out kthx
  • Corrupt the filesystem.  IOS is the driver that maintains the NAND filesystem; if it discovers problems, its first reaction seems to be to completely wipe it and start over, and there’s no recovery from that.
• Redundancy:  Now that I’m done scaring you, there is some good news.  The Wii can hold about 200+ different versions of IOS, and it will only load a version of IOS when required to by a TMD or an explicit ES call from a homebrew app.  This means that it is possible — and mostly safe! — to experiment with a nonexistant version of IOS — say, IOS5 or IOS16.  You can even patch existing versions of IOS, as long as you make sure you have a way to execute code if that IOS breaks.   This also produces a unique challenge — anything that requires fundamental changes to the way that state is kept on the system means that you will have to modify every single version of IOS to get it to work — the best example of this would be adding in support for bigger NAND flash chips.  There is not yet a safe way to do this, because we do not yet have a way to recover from a mishap if you make a mistake in patching all versions of IOS.