HackMii

Notes from inside your Wii

HackMii header image 1

IOS HAX

July 10th, 2008 by bushing · 20 Comments

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.
Expect to see more on this in the future; Marcan has already written a great article about our near-term plans, if you can read Spanish.  I will be releasing some code in the near future to make it easier to experiment with IOS, but be warned that this would be a very poor choice for a first programming project.
Please try to keep all discussion at a technical level; I’m not in the mood for arguments, but I will try to answer any thoughtful questions you may have.  At the very least, please look over all of these references before we begin:

→ 20 CommentsTags: Wii

factory 2

July 7th, 2008 by bushing · 27 Comments

(Note: this is a continuation of http://hackmii.com/2008/06/factory/)

Last week, I bought two brand-new Wiis (the first new ones I’ve ever owned!) and dumped their NAND Flash filesystems before powering them on for the first time.  I was able to recover some interesting info (although nothing earth-shattering).

The two Wiis: [Read more →]

→ 27 CommentsTags: Wii

etc

July 1st, 2008 by bushing · 36 Comments

It’s been a few days, so I’m just going to post some brief notes on what I’ve been working on lately.

  • Twilight Hack:  Marcan did a great job of putting together a nice new release that works with System Menu 3.3: Twilight Hack v0.1beta1.  It seems to work well; we have some initial reports that some SD cards don’t work with it, giving a “error -1 reading boot.elf”.  I’ve found at least two different problems that can cause that, so expect a small update soon — in the mean time, reformatting the card often fixes it.
  • Updates:  No new updates, as seen on Marcan’s Wiimpersonator.  I would not expect this to last; Nintendo will probably release a fixed version of their anti-TP hack code which will not be nearly so easy to defeat.   For those of you who updated to 3.3, take that as a warning and just don’t update next time.  We’re working on a long-term solution.
  • Korean Wii:  We believe that the new Korean Wiis have a new common key, and we won’t be able to use our tweezer attack to recover it.  I’d like to take a look at one and see what other avenues of attack there may be.  If anyone knows how I can buy one of these and get it shipped to the US, please let me know. 
  • Forum:  I must confess to the fact that I didn’t even know there was a Wiibrew Forum until recently, but the admins there have put a lot of work into spiffing the place up recently.  I think we can turn this into a good resource to take the place of some of the discussion that doesn’t really belong on a wiki, so please drop by and bring your quality questions with you.
  • UnbrickMii / Factory — both of these have updates which deserve their own article.  Stay tuned. 

→ 36 CommentsTags: Wii