Wii Architecture

I think the number of features that this console offered made it very attractive for hacking, as cracking the security system would allow homebrew developers to get their hands on the console's capabilities without having to go through Nintendo's checks. Be as it may, the Wii ended up having a fantastic Homebrew library.

Copy protection

Let's start with the common victim: The disc drive.

Wii discs include the aforementioned 'burst cutting' area which is inaccessible by conventional readers. So, in the absence of this, the driver will always refuse to read the content.

The disc drive won't let anyone pass this screen until a valid disc is inserted.

Modchip developers discovered that the drive contained a debug interface called 'Serial Writer' , though this port is locked until a secret key is entered. Still, it was a matter of time before the key was discovered. Once this happened, modders were able to disable the copy protection and subsequently developed a modchip that automatised this process.

Matsushita released further revisions of this drive obfuscating the debug interface, however, other flaws in the reader were discovered to re-enable it again.

It's worth mentioning that the main benefit of modchips was plain piracy, as the disc content is still encrypted, so more research and tools were needed to run custom code.

GameCube homebrew, on the other hand, was already possible to execute by following previous exploits discovered on the predecessor.

System encryption

This is probably the most complex section of this console, yet its never-stopping research opened the door to lots of talented developers and amazing programs.

The Wii designed its internal security around a couple of cryptographic ciphers (AES, RSA, ECC, SHA-1 and HMAC). To keep explanations easy-to-follow, let's take a look at each group separately:

Shared encryption

The communication between many components (NAND, game disc and SD card) is encrypted to avoid being tampered with. Nintendo chose a symmetric key system to protect it , meaning that the Wii uses the same key to encrypt and decrypt its data.

Starlet has three 128-bit AES keys stored in its OTP memory , these are written once during manufacturing:

• Common key: A global key generated by Nintendo that's found on all Wiis, it is used to decrypt the first layer of encryption used on channels and disc-based games (we'll refer to them as titles from now on).
• SD Key: This one is used to encrypt/decrypt data transferred to the SD card, and only the System Menu can perform these transfers.
  • Nintendo stored a copy of this key inside IOS for no clear reason.
• NAND Key: This key is randomly generated during the manufacturing process (meaning that it's unique for every Wii) and it's used to protect the NAND chip.

With this, we can see that Starlet is in charge of the encryption/decryption of sensible content, this is why this CPU is the only one that has access to confidential data.

Chain of trust

Titles contain another layer of security, RSA-2048. This is an asymmetric cipher, meaning that we need one key to encrypt the content and another one to decrypt it. In a nutshell, this allows Nintendo to encrypt titles using an undisclosed key (called 'private key'), while the Wii decrypts them using a 'public key', which is stored in the console. If hackers were to obtain the public key, it would not be enough to crack the security system, as data is still expected to be encrypted using the private key, which only Nintendo knows.

Furthermore, RSA is not only used for encrypting content, but also to check the integrity of said encryption. You see, Nintendo uses multiple keys that are used to sign (encrypt) already-encrypted data, forming a chain of encryption with the only purpose of making sure:

• Every single key used has been authorised by Nintendo.
• Data hasn't been altered and re-encrypted without authorisation.

Let me give you an example of how this works:

1. Nintendo creates a key named x.
2. Nintendo programs Starlet to trust content only signed with key x.
3. If Starlet finds itself having to decrypt a title with key y, it will only proceed if y has been signed with key x.

This is called a Chain of trust. Outside the Wii, this technique is commonly used to protect most of our communications across the globe (for instance, web browsers using HTTPS rely upon 'root certificates' to validate the authenticity of unknown certificates).

Starlet's chain

Starlet's OTP stores public keys (meaning that, for our purposes, it can only decrypt and verify the signature of content). Its chain of trust is made of the following keys :

• Root Key: Signs the CA key.
  • Starlet only needs to stores this (public) key, the rest can be decrypted (and subsequently trusted) if it's been signed by this key.
• The Certification Authority Key (CA): Signs the XS and CP keys.
• The XS Key: This key signs 'Tickets', a type of data that contains a list of AES keys needed to decrypt titles (called 'title keys').
• The CP Key: Once the title is decrypted using the respective title key, the CP key is used to sign the metadata of a title (called 'TMD').
  • While it doesn't sign the content per se, the metadata includes an SHA-1 hash that Starlet uses to verify the integrity of that data.

As you can see, all of this enables Nintendo to be the sole distributor of content, which can be a good thing for game studios concerned about piracy.

More keys

This system also contains a pair of ECC private and public keys. Elliptic Curve Cryptography (ECC) is another algorithm similar to RSA. In this case, it's only used to sign the content transferred through the SD card. This is what prevents content copied from one Wii to be used in another one.

The ECC key is signed by yet another RSA public key called MS, which will allow Starlet to trust the ECC key.

The last key used by this console is the HMAC key, which uses another algorithm that combines SHA-1 hashes and HMAC. During the boot process, Starlet checks that NAND hasn't been altered by third-party hardware. To do that, it computes the SHA-1 hash of NAND and compares it against a hardwired hash to check if they match. In addition to that, the saved hash is signed using the HMAC key to make sure it's authentic.

As a final note, the HMAC key is stored in SEEPROM (outside Starlet), not in OTP.

Observations

After all this, it's worth mentioning that when the system runs GameCube games, none of the mentioned encryption methods are used. Instead, Starlet will only check that the game only accesses its designated memory locations. This is because 1/4 of GDDR3 RAM is allocated to simulate old ARAM.

The fall of encryption

Let's start with AES keys, the algorithm may be hard to crack, but if the keys are extracted somehow (especially the common key), that layer of security would be instantly nullified. Thus, the main challenge is how to extract them.

Starlet's security diagram.

Well, a group of hackers called Team Twiizers found out that the lack of signatures on GameCube mode may be a promising attack surface . They not only discovered that 3/4 of that GDDR3 RAM were not cleared after running a GC program, but also that by bridging some address points on the motherboard (using a pair of tweezers, nonetheless) they could swap the selected banks of GDDR3 RAM, allowing access to restricted areas. Lo and behold, the AES keys were found residing in there.

Let's not forget that this only allows to decrypt the 'first layer' of security, but in order to execute unsigned programs (Homebrew), RSA has to be cracked too. Unfortunately, this can be computationally impossible... Unless there are flaws in its implementation. Well, Team Twizzers didn't stop there so they started reversing how IOS was coded, focusing on its signature verification functions.

RSA signature verification, without going into too much detail, works by comparing the hash of the computed RSA operation against the decrypted signature. After some fiddling, the group discovered something hilarious: Nintendo implemented this function using strncmp (C's 'string' compare).

For people unfamiliar with C, strncmp is a routine used for checking if two strings are equal. This method receives three parameters: two strings and one integer, the latter states the number of characters to be compared. Afterwards, strncmp starts comparing each character until the end of any string (or the character counter) is reached. Strings in C are just a chain of characters terminated by a \0 character, this means that strncmp stops comparing once any string reaches \0. Hence, by composing a Wii title in a way that its hash contains \0 at the beginning, Starlet's RSA computations will find themselves comparing very short hashes (or even empty ones) with substantial chances of collision (different data that produces the same hash value). Ultimately, using a feasible amount of brute-forcing, this enabled the comparison to return equal... Title is signed!

As if that wasn't enough, this flaw was discovered on multiple IOS versions - and even in routines found on boot1 and boot2!

The dawn of Homebrew

After this, there was only one thing left: Make the exploit permanent and implement a 'user-friendly' tool, so it could run custom programs without hassle.

Running third-party apps was initially done by using a forged save game.

So far, these exploits required the use of extra hardware, so not every user could make use of it... Until Team Twizzers discovered yet another exploit: A game buffer overflow.

I'm referring to the famous The Legend of Zelda: Twilight Princess (a game by Nintendo, by the way). TT discovered that the game's save file could be modified to overflow the number of characters used for naming the player's horse. So, when the player attempts to read the overflowed name, it would trigger a chain reaction ending in arbitrary code execution. This could be used to run, let's say, a program loader.

Since signatures could now be forged, this crafted save file was easily distributed on the net for other people to use. As a result, the homebrew community was now able to execute their custom software.

A permanent state

While further reversing IOS, it was discovered that signatures are only checked during the installation of titles, not during their execution.

Thus, TT did it again. They carefully forged an installable channel that could load arbitrary programs from the SD card. If this channel were to be installed before Nintendo had taken action to mitigate the security issues, then the Wii would enjoy homebrew permanently (independently of Nintendo patching their signature flaws in the future, which they did).

Homebrew Channel was the result of this, this title allowed any user to kickstart homebrew programs that benefited from full control of this system (with all the implications that this means).

Nintendo's response

For obvious reasons, Nintendo issued several system updates that fixed the signature exploits on multiple versions of IOS, they also took care of their flawed boot stages by shipping new hardware revisions.

Lots of these coming through.

However, there were still fundamental flaws discovered in this system:

• Broadway can reboot Starlet to any IOS version without extra permissions, allowing to exploit non-patched versions.
• Hidden IOS APIs can still be used without special privileges, allowing even more unauthorised control of the hardware.
• The disc drive can receive commands to read conventional DVDs and some IOS contained hidden calls to send those commands. This was particularly worrying for piracy reasons.

So, to wrap this up, what was left after this was just a cat-and-mouse game. Over the next months, different exploits were discovered with Nintendo subsequently trying to patch one after another. This 'game' continued until the console reached its end-of-life and no more updates were issued. We can assume the mouse won this one.

At the time of writing, the exploits mentioned in this article have already been patched, but also replaced with currently working ones.

I guess there's no arguing about the impact the hacking scene made on this system, and who can forget the enormous amount of homebrew that was made available (there was even a homebrew 'store', which was faster and freer than the official 'Wii Shop Channel').