HackMii

Manufacturers of consumer electronics are constantly revising their designs over the lifetime of each product, generally for four reasons:

1. Yield improvements — fix flaws that caused lots of warranty returns
2. Cost reduction — use cheaper or fewer parts, so that profit margin increases or the retail cost can be lowered (or both)
3. Part refresh — sometimes manufacturers stop making parts (for example, 64MB memory chips), so they’ll start using “better” chips because they are the only ones now available
4. Security — anti-modchip modifications

Most people only think about the last one, but the first three are far more common. I think Sony has most actively revised their designs — aren’t there something like 30+ revs of the PS1, 15+ revs of the PS2, and several of the PSP and PS3? Microsoft had 5 or 6 revs of the Xbox1, and 3 of the Xbox360. Nintendo has had relatively few — perhaps this is because they have never sold their consoles at a loss, so they have less incentive to retool their factories to bring their costs down. (It’s rather expensive to redesign a PCB and then retool your factories to make new ones, and you add some risk of creating new hardware problems and increasing your failure rate.)

Focussing back on our Wii, we can consider the following things as being more or less independent:

• Updates to the disc drive
• Updates to the “big chips” (Hollywood, Broadway)
• Updates to the main PCB

[Read more →]

Most of you probably remember our infamous attempt to open a line of communication with Nintendo. We chose that bug because a previous attempt at communication had failed — we had thought that them fixing the strncmp bug in the System Menu’s IOS could cause the system menu to brick when it tried to load the banner for the Homebrew Channel.   I emailed them about that in March, 2008 (right after IOS37 was released), and never got a response.   Thinking maybe I’d failed to find the right email address, we tried again with another bug.  We chose that bug because

1. We could position it as a piracy-related concern, and Nintendo has some channels for reporting piracy
2. We didn’t really care if they fixed the bug, since it wasn’t really that useful for legitimate homebrew
3. There was probably not much they could do to fix it, anyway, since it was more of a design flaw

The bug (as we intended to report it) wasn’t so much that you could poke a register to enable DVD video mode:

 #define HW_DIFLAGS 0x0d800180

 set32(HW_DIFLAGS, 0x200000);

… it was that you could just set a bit in the TMD (in the “access rights” field) and it would let you send DVD video commands.  You didn’t even need to patch IOS!  If you set that bit in your TMD, when your title gets launched, ES reads the “access rights” field (offset 0x1d8) and checks a couple of bits.   If bit 1 is set, it opens /dev/di and calls ioctl 0x8E, which in turns calls syscall 0x50, which does the above register poke.  This seems to set some state in the DI controller chunk of the Starlet that allows DVD video commands to go through.  This is how DVDX works — that bit is set in the TMD for DVDX and that makes the magic happen.

All of this is more or less academic, because if you can forge a signature to modify the TMD, then you can just patch the content of IOS — and that’s what most people (everyone else) did.  We think our approach is cleaner, but oh well.

[Read more →]

This happened a couple of weeks ago, but I only found out about it recently. Nuke released the full kit-n-kaboodle of USBGecko as open-source at http://code.google.com/p/usbgecko/ — this includes not only the source code for the latest WiiRd and GeckoOS under GPL, but the full schematics and VHDL files for the USBGecko itself under the BSD license. Bravo!