Model
Le Wii
Released on 19/11/2006 in America, 02/12/2006 in Japan and 08/12/2006 in Europe
Showing revision 'RVL-CPU-40', earlier revisions had a significantly larger fabrication process and later ones removed most of the GC I/O
NAND Flash is fitted on the back
Diagram
Important data buses are labelled with its width and speed

A quick introduction

Even though the Wii lacked of the state of art graphics its competitors enjoyed, new types of control and innovative software gave this console new areas to brag about.

Here we will analyse every aspect of this console, from its already-familiar hardware to its overlooked security system, including its major flaws.

Quick Note: Some sections overlap part of the previous article about the Gamecube, so instead of repeating the information I will just put a link to the respective part of the article.


Next-gen controllers

Let's start by discussing one of the most iconic aspects of this consoles: The controllers.

The main device is no other than the Wii Remote (also called ‘Wiimote’), a gadget with a similar shape of a TV remote that contains many types of input controls:

The remote is powered by Broadcom's BCM2042, a chip that includes all the circuitry necessary to become an independent Bluetooth device (CPU, RAM, ROM and, of course, a Bluetooth module). While the Wiimote is programmed to follow the Bluetooth HID protocol in order to be identified as an input device, it doesn't comply with the standard method of exchanging data (possibly to disallow being used on non-Wii systems).

Lastly, the Wiimote also includes 16 KB of EEPROM to store user data and a small speaker limited to low-quality samples.

Expansions

Nintendo shipped this system with another controller to be used on the opposite hand, the Nunchuk, this one comes with its own accelerometer, joystick and two buttons. It's connected to a 6-pin proprietary port on the Wiimote.

Image
Nunchuck and Wiimote, respectively

Other accessories were also built for this port, each one provided different types of input.


CPU

After the success of Gecko, IBM presumably grabbed this design and re-branded it as ‘750CL’ for other manufacturers to use. Then, when Nintendo requested a new CPU to use with their new console (still known as ‘Revolution’, hence the RVL prefix on their stock motherboards), IBM and Nintendo agreed on a 750CL clocked twice the speed as Gecko. This CPU is known as Broadway and runs at 729 MHz.

After having reviewed Gecko, I'm afraid there's not many changes in the new CPU. However this can be seen as a good thing: GameCube developers were able to start developing their new Wii games right away thanks to all the experience they gained with Gecko, moreover, the fact that Broadway runs twice the speed will allow them to push for more features and quality.

What about memory?

This one is an interesting bit, the old Gamecube memory layout has been re-arranged and enhanced with the following changes:

Backwards compatibility

(For now) You can think of this console as a superset of the GameCube and as such, compatibility with the previous generations of games is naturally inherited. That being said, in order to make the Wii fully backwards compatible, the old set of external ports were brought to the Wii, these include the GameCube controller and memory card ports. There is one exception however: The new memory map is incompatible with the old one, thus an emulated layer of compatibility was implemented in software (more details later on).

In terms of GameCube accessories using the Serial/Hi-Speed socket, I'm afraid the Wii didn't include these ports, so those accessories can't be used here.

In later years, the new revisions of the Wii saw these ports removed, unfortunately.


Graphics

The new graphics package is called Hollywood, it still performs the same tasks that Flipper had to do back in the day but enjoying twice the clock speed (243 MHz).

This speed increase means that more geometry can be processed during the same unit of time, so Wii games will be able to show more polygons and better-quality textures compared to GC games.

The 3D engine is still Flipper's but now called GX. So instead of repeating the pipeline overview, I will mention some interesting design changes that games had to undergo:

Standardised Widescreen

Image
4:3 mode
Super Mario Galaxy (2007)
Image
16:9 mode, as composed by the video encoder
Super Mario Galaxy (2007)
Image
16:9 mode, as displayed on a widescreen TV
Super Mario Galaxy (2007)

Gamecube games lacked of a proper support for widescreen displays (composing 16:9 frames, in contrast with the traditional 4:3). Some games provided options to activate it, although this wasn't found in the majority of games.

Truth to be told, the video encoder still outputted a fixed 640x480 pixel frame, so this ‘widescreen’ feature only worked by drawing a wider internal frame and letting the video encoder squash it in order to fit in a 640x480 map, then your 16:9 TV would stretch the image so the final result could look more or less in the correct ratio. This technique is not new, it has been used in film projection and it's referred as Anamorphic widescreen.

Back to the point, the Wii now enabled this feature globally: It can be set in its system settings which will require every game to support it.

Screen Interaction

Image
Super Mario Galaxy (2007)
You can pick up the stars by pointing at them

Changes in the input system meant more available features for Wii games, since the WiiMote allowed users to point at the screen, some games like Super Mario Galaxy or The Legend of Zelda: Twilight Princess used this feature to enable the player to interact with the scenery.

At first glance, this would seem like a feature easy to implement, right? Well, it's actually more complicated. You see, the CPU doesn't know what elements the user is pointing at until the GPU renders the screen (remember that the CPU feeds the geometry but can't predict what the user will see, that's the job of the GPU).

This feature was accomplished by checking depth (z value) of objects overlapped by the cursor, this can only be done using the embedded frame buffer stored inside GX, which both Broadway and GX have access to.


Video Signal

This console includes a single proprietary connector that can provide multiple video signals at once (called A/V Multi Out), these include:


Audio

The Wii included the same Macronix DSP found in the Gamecube, take a look at that link to get the detailed analysis.

Compared to the GC, the only major change is that, since ARAM is gone, either MEM1 or MEM2 can be used to stored samples.


I/O

The I/O subsystem of this console is a truly game changer (if you'll pardon the pun). The interfaces are now controlled by a single module that will take care of security too, I'm talking about Starlet.

The hidden co-processor

Starlet is just an ARM926ET-S core that is wired up to most of the internal components of this console. It resides inside Hollywood and contains its own ROM and RAM too, so you can consider it an independent computer running alongside the main CPU.

External I/O on the Wii
The dark & small front slot is an SD card reader

This ‘I/O CPU’ is programmed to arbitrate access to different I/O from Broadway, and in doing so it also takes care of security (which decides to whether to allow access or not), this is specially crucial when it comes to granting access to NAND, which is where the main operating system and user data is stored.

The chip also inherits some technology from ARM, for instance, implemented in this chip is the Advanced Microcontroller Bus Architecture or ‘AMBA’, a protocol that facilitates the communication between other devices using a set of specialised buses.

That being said, Nintendo wired up the I/O in a way that makes use of two AMBA buses:

Maintaining compatibility

Image
Wii using Gamecube equipment

The Wii maintains full backwards compatibility with Gamecube games even though the original I/O system has changed drastically. This is because Starlet can be reprogrammed when a Gamecube game is executed to virtually re-map the I/O just like the original Gamecube would expect to find.

Additionally, the Real-Time Clock chip includes some spare ROM that stores bitmap fonts used by Gamecube games (the Latin and Japanese set) and SRAM to save IPL-related settings.


Operating System

There are two operating systems residing in the Wii, one is executed on Broadway (main CPU) and the other one on Starlet (I/O CPU). Both reside inside those 512 MB of NAND memory and can be updated.

Starlet's OS

Starlet is already an interesting piece of hardware, but its software is even more intriguing. You see, not only this OS has complete access to every single corner of this console, but it's also the first thing that runs when the power button is pressed.

Starlet runs a system unofficially referred as Input/Output Operating System or ‘IOS’ (please, do not confuse this with Apple's iOS). IOS is a fully-featured operating system and it's basically composed of:

With this in mind, the main job of IOS is to simplify the job of the main CPU by abstracting I/O and security. For that reason, programmers don't have to worry about those matters. In order to accomplish this, Starlet reserves between 12 and 16 MB of GDDR3 RAM for its own tasks, only the rest is used by Broadway.

Broadway and Starlet communicate with each other using an Inter-Process Communication or ‘IPC’ protocol: In a nutshell, this works by both CPUs sharing two registers each. One CPU can write on the other's registers (the written data can then be translated into a command or a value) and from there, the latter CPU can perform a function in response.

The update design of IOS is a bit tricky: Updated IOS versions are not installed on top of old ones, but in other slots instead. This is purely for compatibility reasons, since it allows to keep older Wii software working using the same IOS version which was develop for.

Nintendo often released IOS updates to improve hardware support (which was necessary when a new accessory was released). There's only one exception when IOS updates actually replace older ones: When an certain version was discovered to have an exploitable vulnerability, this was only for security reasons.

When a Gamecube game is inserted, a different thing happens: Startlet boots a MIOS instead. This one just limits Starlet to emulate the original IPL.

Broadway's OS

This one is commonly know as the System Menu and effectively runs on the main PowerPC CPU (Broadway).

Image
System menu with lots of channels installed
Image
Settings menu used to change settings
Image
The message board stores letters grouped by date

Compared to IOS, I wouldn't consider this a ‘fully fledged’ OS, but more like a ‘program’ that allows the user to perform the following operations:

  • Start the Wii/Gamecube game: Only if there is a valid one inserted.
  • Change consoles settings: Includes time, date, video mode or sensor location, among others.
  • Run apps: One of the novelties of this console is the ability to install small Wii games (called ‘WiiWare’), retro games (‘Virtual Console’ games) or just convenient applications (such as an internet browser). Nintendo called these channels, but they are also referred as titles in a more lower level.
    • Users can download/buy these through a pre-installed channel called Wii Shop Channel.
    • VC channels embedded an emulator to run the game itself, notice that such emulator is not shared across the system to enable optimisations for specific games.
  • Send/Receive messages: Wiis have a unique ID (burned in their SEEPROM chip) which can be shared to exchange messages with other Wiis. Messages can be seen on the Message Board.
    • Nintendo and Wii games also used this medium for newsletter as well.

Just like IOS, Nintendo released multiple updates to this system too. Some fixed security holes, others added more features (a notable one was the ability to use the SD card to store channels too).

Any program running on Broadway (including the System Menu) relies on a specific IOS version to work. When game or a channel is booted, Starlet reboots itself using the required version of IOS needed.

Update medium

Nintendo refers to them as System updates, they contain the two OSs in the same package and use ordinal numbers for versioning, the last version known is 4.3E released in June 2010.

System update packages are found on Nintendo's Servers or in game discs. Users can manually check for updates using the System Menu, however these are automatically triggered if a game requires a specific version of IOS which is not installed and the disc happens to contain the required packages.

Boot sequence

So far we have discussed two very different OS that reside in this console and run concurrently, this seems fairly simple, however both have to be carefully coordinated during the start of the console in order to work properly afterwards. That being said, the boot process of this console is as follows:

  1. User taps the ON button on the console.
  2. Boot0 stage: Starlet runs a small program found in its embedded Mask ROM (1.5 KB).
  1. Boot1 stage: Starlet runs a small program found in that aforementioned 96 KB of NAND.
  1. Boot2 stage: Starlet loads the initial IOS (needed for the System Menu) and then gives power to Broadway.
  2. Broadway starts the System Menu, the user is now in control.

Games

While new games did not always come with considerable graphical leaps, they did surprise users with the amount of features they could now offer. This was thanks to the amount of services Nintendo deployed after this console launched, ranging from the new set of controls to a standardised online infrastructure (WiiConnect24) which enabled free online gaming.

Medium

Wii games are distributed using a proprietary disc format called Wii Optical Disc (I know, the name can't get be more obvious). Anyhow, Panasonic designed this format based on the traditional DVD disc while adding non-standard features like a burst cutting area on the inner section of the disc to prevent unauthorised reproductions. Matsushita took care of manufacturing the drive.

Image
Standard games are presented in a physical box and disc
Image
Small games (Wiibrew) and old titles (Virtual console) can be purchased and downloaded through the Shop Channel

Space available ranges between 4.7 GB (if single-layer) or 8.54 GB (if double-layer). Wii discs often contain two partitions: The first one stores system updates and the other one, the actual game.

Some games like Super Smash Bros Brawl included more partitions to store multiple Virtual Console games, which could be executed inside the main game.

Development

As part of the tradition, Nintendo provided a development kit. This one was called NDEV and shaped like a big black brick, it came with enhanced I/O and two times the amount of MEM2 (128 MB in total) for debugging purposes.

The official software suite provided was named Revolution SDK and it included various tools, compilers, debuggers and frameworks used to carry out development (mostly in C/C++). Nintendo distributed subsequent updates through a web portal called WarioWare.com (now offline) that only approved developers could access.

The official SDK makes a constant use of IOS calls to interact with the Wii hardware, this is why IOS updates are often correlated to SDK updates.

Return to Home

After going through all the software advancements of this console, it may surprise you that games still run on bare metal, which means that they have complete control of Broadway, but not of Starlet (hence, security mechanisms are implemented here). Needless to say, while games can certainly enjoy this full-control, their behaviour is still subject to Nintendo's approval in order to authorise their distribution.

Image
Home menu showing in-game
Image
This screen has to be included as well

Having said that, there's one feature found in most, if not all, games and that is the ‘Go Home’ interface, which allows to return to the System menu. However, how are they are all able to implement the same UI if there's no OS to communicate to?

The answer is simple, Nintendo included in their SDK some mandatory libraries that drew that screen.

This is actually one of the 200 or so requirements games had to include, as ruled by the ‘Wii Programming Guidelines’ document (found of the official SDK). Other requirements include displaying the ‘Wii Strap reminder’ screen (which is just a bmp image) at the start of the game, they also specified how to interact with it.

Personalised game

Image
The Mii channel allows to fiddle with your own 'Mii'...
Image
...So then it appears in your games
Wii Music (2008)

Another new feature I would like to emphasise is the introduction of Mii, some sort of avatars that users could create using a dedicated channel called Mii Channel.

But the fun didn't stop there, since games could also fetch these new-created Miis to enhance gameplay with a more personal addition.


Anti-Piracy & Homebrew

With the amount of features that this console offered, it's no surprise that hackers would want to break the security measures to execute their own software. The Wii ended up having a fantastic Homebrew library, nonetheless.

Copy protection

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

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

Image
The disc drive won't let anyone pass this screen until a valid disc is found

Modchip developers discovered that the drive contained a debug interface called ‘Serial Writter’, although this port is locked until a secret key is entered. But once that key was discovered, 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 use for modchips was piracy. The disc content was encrypted, so more research and tools were needed to run Wii homebrew. Gamecube homebrew, on the other hand, was already possible by following some exploits found back in the days of the original Gamecube.

System encryption

This is probably the most complex section of this console, yet its widespread research opened the door for lots of new developers and amazing programs.
The Wii designed its internal security using cryptographic ciphers (AES, RSA, ECC, SHA-1 and HMAC), let's take a look at each group:

Shared encryption

Communication with many components (NAND, game disc and SD card) is encrypted to avoid being tampered with. Nintendo chose a symmetric key system meaning that it uses a single cipher to decrypt and encrypt its data. Specifically, it uses 128-bit AES keys.

Starlet has three 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 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 this key inside IOS too for no clear reason.
  • NAND Key: This key is randomly generated during manufacturing process (meaning that it's unique for every Wii) and it's used to protect the NAND chip.

As you can imagine by now, Starlet is in charge of handling encryption/decryption of protected content, this is why this CPU is the only one that has access to the most sensible data.

Chain of trust

Titles contain another layer of security, RSA-2048. This is an asymmetric cipher algorithm (meaning that we need two keys to decrypt and encrypt the content, so it's not enough by obtaining one key). In a nutshell, this allows Nintendo can encrypt tiles using their ‘private key’, while the Wii decrypts them using the ‘public key’.

Not only RSA allows to protect content, but it can also be used to check the integrity of encryption. You see, Nintendo uses multiple keys that are used to sign (encrypt) one on top of the other, forming a chain of encryption with the only purpose of verifying author of those keys (Nintendo) and avoiding alterations. In our case, Starlet only trusts content signed with key ‘x’, so if it has 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 and it's commonly used to protect most of our communications in other areas as well (for instance, HTTPS).

Starlet's OTP stores public keys (meaning that, for our purposes, it can only decrypt and verify the signature of content). The chain of trust is made of the following 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 our 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.
  • The Certification Authority Key or ‘CA’: Signs the XS and CP 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.

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

More keys

This system also contains its own ECC private and public keys, ECC (Elliptic Curve Cryptography) 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 by another one.

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

The final key used by this console is the HMAC key, which uses another algorithm that combines SHA1 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 SHA1 hash of NAND and compares it against a saved hash to check whether they match. In addition to that, the saved hash is signed using the HMAC key to validate its authenticity.

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


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 can only access to certain memory locations. This is because 1/4 of GDDR3 RAM is used 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 (specially the common key), that layer of security would be instantly nullified. Then, the main challenge is how to extract them.

Image
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 area of exploitation, and not only they discovered that 3/4 of that GDDR3 RAM was not cleared after running a GC program, but they also found out that by bridging some address points on the motherboard (using a pair of tweezers, nonetheless) they could switch the accessible banks of GDDR3 RAM, allowing to fetch hidden data from those restricted areas. Lo and behold, they found the AES keys stored 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 implemented, focusing in 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, these guys discovered something hilarious: Nintendo implemented this function using strcmp (C's string compare).

For people unfamiliar with C, strcmp is a function used for checking if two strings are equal. This method receives two strings and an integer (representing the number of characters to be compared) as parameters, then it starts comparing each character until the end of any string is reached. Strings in C are just a chain of characters terminated by a \0 character, this means that strcmp stops comparing once any string reaches \0. Hence, by composing a Wii title in a way that its hash has zeroes at the beginning, Starlet RSA computations will input a \0 string, making strcmp always return equalTitle is signed!

As if that wasn't enough, this flaw was discovered on multiple IOS versions (even in 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 unsigned programs without hassle.

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

Unfortunately, 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 save could be modified to overflow the number of characters used to name the player's horse, so when it runs it would trigger a chain reaction can could potentially execute, let's say, a program loader.

Since signatures were no longer an issue, this forged save file could be distributed on the net for other people to use. This effectively happened, opening the door for the Homebrew community.

A permanent state

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

The most user-friendly hack of all
Unofficial Homebrew channel (2008)

Thus TT did it again, they carefully forged an installable channel that had the ability to load arbitrary programs from the SD card. If this channel was installed before Nintendo could take action, then the Wii could enjoy homebrew in a permanent state ( independently of Nintendo patching their signature flaws in the future, which they did).

Homebrew Channel was the result of this, it allowed any developer and hacker to write fully-fledged programs that could benefit from full control of this system.

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 also releasing new hardware revisions.

Image
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 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 them one after another. This ‘game’ continued until the console reached end of life and no more updates were issued (we can assume the mouse won this one).

At the time of writing, the exploits previously mentioned in this article have already been patched. But I guess there's no arguing about the impact they made afterwards, and who can forget the enormous amount of homebrew that was made available (somebody even created a homebrew ‘store’, which was faster and freer than the official one).


That's all folks

Happy new year 2020!

This one took me quite a while, I naively predicted that since most of the content was already done for the Gamecube, I would just have to write short paragraphs and add links here and there…

I think it turned out more informative than I expected, so I hope you found it a nice read.

Until next time!
Rodrigo


Sources / Keep Reading

General

CPU

Graphics

I/O

Operating System

Games

Security

Photography

Interesting


Contributing

This article is part of the Architecture of Consoles series. If you found it interesting please consider donating, your contribution will be used to get more tools and resources that will help to improve the quality of current articles and upcoming ones.

Paypal

A list of desirable tools and latest acquisitions for this article are tracked in here:

## Interesting hardware to get (ordered by priority)

- Nothing else, unless you got something in mind worth checking out

## Acquired tools used

- Cheap Wii with accessories (£15)

Changelog

Always nice to keep a record of changes.

## 2020-01-06

- Spelling & Grammar corrections

## 2020-01-05

- More accurate references to official documents
- Extended (small) audio section
- Referenced Wiimote's speaker
- Added footer
- Public release

## 2020-01-04

- Second draft done
- hola carlos

## 2019-12-31

- First draft done

Rodrigo Copetti

Rodrigo Copetti

Hope you enjoyed the article! If you want to know more about the author tap here and if you'd like to support him tap here instead

rss linkedin twitter facebook reddit