In the 1980's we loved Nintendo. And even better, in the 1980's Nintendo loved us. They gave us games, we played them. They gave us cereal that was basically Kix with fun Nintendo-themed boxes, and we ate it and pretended to like it. They gave us movies like Super Mario Bros., widely considered the greatest film in the history of filmmakingcitation needed. We watched the cartoons, learned how to Do the Mario (ideal if the Macarena is too complex for you), slept in the sheets, memorized the codes, subscribed to Nintendo Power, and hooked up all manner of ridiculous equipment to our TVs.

Lately, though, Nintendo has all but turned its back on us. Mainstream acceptance of the Wii has resulted in less core games like Pikmin and F-Zero, and more casual games like Big Brain Academy, WiiFit, Babyz Party, and Bob Ross Painting. And seriously, who wants those? I'm pretty sure the Big Brain Academy isn't accredited, we're not 40 year old women, parties attended only by babies are just awkward, and Bob Ross... actually, that game sounds pretty rad. Still, Nintendo hasn't been servicing the core gamer as much as they did in the SNES days, so many of us have moved on to the Xbox 360 and the PStriple. Hector Martin, however, is more ambitious, and set out to do what any real geek would. Try to hack the thing!

Now, Nintendo doesn't want you hacking your Wii for several reasons. "Homebrew" is often considered piracy's cousin, which is why every major console is full of security measures to lock users out of running unauthorized code on them. And when a console manufacturer catches a whiff of piracy, lawsuits ensue. Piracy was rampant on the Dreamcast, and Sony is currently feeling the sting of piracy on its PSP platform.

That's not to say that all console manufacturers want to prevent all user-created code from running on their systems; far from it. Microsoft has given the homebrew community a sandbox environment to work in with its XNA initiative. Still, it's run in a very locked-down managed environment with very limited resources (you can't access files outside of your individual game's allocated storage area, and you can't even grant read-only access to those files to other games). You can code on the PS2 if you buy the Linux kit, but for the PS3 there's no large-scale initiative to give development tools to consumers. Nintendo isn't courting the hobbyist either — if you want to develop for the Wii, rumors are that you're looking at $1,732.00. Not unreasonable for a console dev kit, but well out of reach for most hobbyists.

Breaking In

Hector just wanted to see what he could do with the Wii. And when he first took a look under the hood, he started with the usual approach — he started poking through Wii game discs. On every disc he tried, the entire contents were encrypted with secure RSA-2048 and SHA-1. The second place he looked — game saves — were signed using elliptic curve cryptography. Nintendo clearly wasn't going to make this easy.

It looked hopeless. That is, until someone looked at the core function via a disassembler that performed the RSA and SHA-1 verification. Hector provided this pseudocode for the check function:

bool is_valid_signature(byte signature[256], byte public_key[256], byte content_sha1[256]) {
    byte decrypted_signature[256];
    decrypt_rsa(signature, public_key, decrypted_signature);
    if(strncmp(content_sha1, decrypted_signature + 236, 20) == 0)
        return 1;
    else
        return 0;
}

This function is used in every piece of security-sensitive code Hector could find. And rather than use a standard implementation, they rolled their own. In short, they throw away 236 bytes of the RSA signature, which are typically just a particular constant. If the signature isn't the expected constant, well, they apparently don't care. Furthermore, they're using a string compare function to compare a binary SHA-1 hash where they really should've been using a binary compare function. Reason being that a zero byte in the hash will cause strncmp to stop comparing, assuming it's the string terminator. All it takes is analyzing a few valid signatures (say, on game discs) and finding the one with the earliest zero byte, then bruteforcing the preceding bytes.

But there's still the matter of the first 236 characters (1888 bits) lopped off the signature. And since RSA is based on exponentiation, if the signature is zero, the result (and expected SHA-1 hash) is also zero. Once this was discovered, the homebrew community was overjoyed! It didn't take long before they were running custom code on the system.

Development moved quickly. The homebrew community took it upon themselves to design their software to be as elegant and Wii-like as possible, and they succeeded. The Homebrew Channel worked just like any other channel on the system, elegantly integrated into the Wii experience without interfering with existing channels. Take a look yourself: it almost looks official.

Part of what made their lives easier was the storage of existing channels. Interestingly, previously installed WiiWare games, Virtual Console games, and other channels are always considered "OK" by the system, and stored completely unencrypted. Perhaps Nintendo figured that with all the security checks during the boot process, once something was in the system, it had already passed security and should be safe. Therefore previously installed homebrew apps, and even hacked versions of the security software, are ignored by the system. Amazingly, Wii Repair Centers have occasionally sent back replacement Wiis with all of the homebrew apps transferred to the new system.

The Corporate Response

Nintendo is busy. They're selling Wiis faster than they can make them, they've got a lot of internet petitions to ignore (sure we don't have EarthBound on the Virtual Console yet, but thanks for China Warrior), they have to keep an eye on the Check Mii Out channel and delete miis with genitals for faces, and they have to thwart Hector and crew's hacks.

They started to fight back with firmware updates. The Wii is designed such that this security and IO software is essentially duplicated with minor changes in 20-plus different places. With updates pushed via WiiConnect24 (the Wii's automatic update service), they've been slowly patching the holes. Still, Nintendo has had to tread carefully, as they can't break existing software and risk a mass of bricked consoles clogging up their repair centers. Out of the 20-some instances, they've fixed three so far. The main impact this has had is that booting from a disc on a modded Wii (as in, with a mod chip installed) no longer works. Exploiting an individual game still works fine, however.

One such exploit involved modifying saved games for The Legend of Zelda: Twilight Princess. The hack involved a stack overflow on some of the strings in the game's savefile. Two of the strings were the player's name (in my case, "Link"), and the horse's name (in my case, "Horsey"). An exploited save file was made available online, which could be copied onto an SD card, and then copied onto the Wii via its built-in SD card slot. Then you start up the game, walk backward a step or two, and voilà the homebrew channel is installed off the SD card.

On June 16, 2008, Nintendo released a patch, which was timestamped March 6. It seemed reasonable that with development, testing, and finally releasing that the cycle would be at least three months. Among other things, the update included a few functions that raised Hector's eyebrow. DeleteSavedata and VerifySavedataZD. These were designed to thwart the Twilight Princess hack, but like their signature checking algorithm, they didn't quite get it right. Here's the condensed version in pseudocode that would run during the boot process:

fileLength = getfilelength(savefile);
fileLength = (fileLength + 31) & (~31);
data = malloc(fileLength);
fd = fopen(savefile, "r");
if(fread(data, 1, fileLength, fd) != fileLength)
{
     // The file length is a multiple of 32
     return NO_EXPLOIT;
}

In short, it verifies that the save file length is a multiple of 32, as all legitimate Twilight Princess saves are. The publicly released hacked file was not. It went on to check individual save slots, and individual strings within the save file for their lengths. If the check failed, the file was deleted from the console. Code was added to prevent the hacked save file from being transferred off an SD card, too.

It didn't take long to figure out a workaround, by exploiting some bugs in the code that Hector disassembled. One in particular that was useful was that it only checked the first file on the card with the Twilight Princess filename (zeldaTp.dat). If you had two files with the same name, it'd only check the first one, then the code that copies the save from the SD into the internal memory overwrites it when it gets copied.

Six hours after the firmware update, they'd figured out a new exploit, and a few days later a new version of the hack was released to the public.

Tug of War

Nintendo is still engaged in a fierce tug-of-war with the homebrew scene, and for every feature they add to enhance security, Hector and crew find a way around it.

Wii hacking for the consumer isn't hard to do, as instructions are readily available online, and the only necessary supplies are an SD card and Twilight Princess. Homebrew applications include media players (including DVD playback, not natively supported by the Wii), emulators, games (originals as well as Quake and Doom), file system browsers, and a version of Linux (surprised?). There's even a utility to change the Wii's region, which is now being used for buying (yes, buying) WiiWare games that haven't been made available to all regions.

For the most part it seems that the homebrew scene caters to the geeks who want to see what they can do with the system. Sure, there are those that use these powers for evil, but the intentions of the majority of the community are pure. The Wii isn't just a games console, it's an interesting challenge that has brought people together for little more than the joy of hacking, experimentation, and creation.