10 Days Of Hacking, Day 6: The Wii

After Sega’s strong competition in the 16-bit era of gaming and later Sony overshadowing Nintendo with the PS1, Nintendo had been struggling to regain dominance in the gaming industry, but all that ended with the huge popularity and momentum Nintendo’s Wii got, but I’m not here to discuss console history, there’s another 8 Days feature for that, I’m here to discuss why some of the design choices for the Wii led to an early full blown hack of the system.

There are a lot of key factors that we must understand to know why the Wii was hacked, and more importantly: why it was so easy to hack, and we’re gonna go one by one.

WII? MORE LIKE GAMECUBE 1.5

It’s no secret to anyone that the Wii is 100% backwards compatible with GameCube software, but do you know how Nintendo pulled it off? Well it’s simple, the Wii sports an upgraded version of the GameCube’s PowerPC named Broadway CPU and an ATI GPU named Hollywood similar to the one found on the GameCube, it only takes the Wii’s CPU to drop down its clock speed to be able to execute GameCube code just like in the real GameCube, there’s no need for software emulation, the hardware is the same.
To put it into perspective, comparing a Wii to a GameCube is like comparing a PC with an i5 CPU and a GeForce 9800 with another PC that has an i3 CPU and a GeForce 9200, the former one will be able to execute the same code as the later one, but it will do it faster and with better overall performance. Matter of fact all intel CPUs are fully capable of executing code for 16-bit CPUs like the 8086, provided there’s no problems with the underlying OS, but in the case of the Wii, there’s no OS, and we’ll talk about that later.

This isn’t exactly a bad idea, you ensure backwards compatibility and you save development costs as you already have a base to work with. The problem comes when you BARELY do any changes to security and how the overall machine works, and you BARELY do a good sandbox when in legacy mode (in this case, GameCube mode), and we’re gonna talk about the problem this lead to later.

Another thing to know is that, just like the GameCube, the Wii has no Operating System, there’s no Kernel running in the background when games run, games essentially run on the raw device and have to do all memory and device management themselves.

Aside from having a basically overclocked GameCube CPU, the Wii has an ATI GPU, also similar to the one found in the GameCube, but with some differences. The most important difference is the fact that the GPU is also an IO Bridge device, which is controlled by another, smaller, ARM CPU found in the GPU itself.
This ARM CPU is in charge of all the security found on the Wii, it verifies everything that has to be executed (games, software, etc) and is also in charge of the entire boot sequence. Although the Wii itself doesn’t have an actual Operating System, not even a kernel, this ARM CPU does have a microkernel called IOS (not to be confused with Apple’s iOS). Just like the ARM is for, this microkernel is fully in charged of security, running at the same time as the main PPC CPU.

Now that we know more or less what the Wii is composed of, let’s take a look at some clever hacks that allowed this machine to be opened widely to the homebrew scene.

DUMP THAT RANDOM ACCESS MEMORY!

One of the first things we want to do when it comes to hacking a console is being able to dump the RAM.
This is normally initially done by hardware, and the Wii is no different.

When you turn on your Wii the first thing you do is enter the Wii Menu. You pop in a GameCube disc, it recognizes it as such and it reboots the Broadway into GameCube mode. All fun for now, but this is where it gets interesting.
The GameCube originally only had 16MB of RAM named MEM1 for sound and 24MB of RAM named MEM2 for games, with the Wii we also have the 16MB of MEM1 but MEM2 now has 64MB, of course when in GameCube mode you only have 24MB available, with the other 48MB not used. The funny thing is, when the Wii reboots the Broadway into GameCube mode it doesn’t really clear up the MEM2 RAM, so all the data from the Wii Menu is still there. Problem is we only have access to 24MB, so how do we dump the other part of RAM? well, this is where Team Tweezers (now known as fail0verflow) came in, and just like their name implies, they used tweezers to bridge the data bus of the Wii’s RAM while in GameCube mode to change which part of RAM they were accessing. So you still could only access 24MB, but you could move around on which range of the Wii’s MEM2 those 24MB were allocated, and as I said before, Nintendo foolishly didn’t cleared out RAM, so you could essentially dump the entire Wii RAM from inside GameCube mode.

But that’s not all folks, it so happens that in those previously unaccessible 48MB of RAM is where they used to store all the keys!

LETS COMPARE TWO BLOCKS OF DATA AS IF THEY WERE A STRING!

I have said this a lot times already, at the lowest level, a machine can’t make a difference between an int, an unsigned int, a float, a char, an unsigned char, or any other type of data. For the machine they are just a bunch of 0’s and 1’s that either have a meaning as an instruction, or it doesn’t have any meaning: a data. What the machine really cares for is the length of the data, 8-bits, 16-bits, 32-bits and 64-bits, and it is up to humans to interpret what that data is outside of a bunch of 1’s and 0’s and tell the machine what to do with it. The C compiler has defined specific data types for this sole purpose: to tell the machine the size of the data and how to use it properly, for example, the hex number 0x61 can be interpreted as the integer 97, or as the character ‘a’, the number 0xFFFFFFFF can be interpreted as the signed number -1 or as the color white or as a pointer (although rarely). The importance of knowing what the next set of data that will come to us is is huge, so huge that C forces you to tell it what each data means, but it still doesn’t stop programmers from misusing the data.

The Wii uses hardware to verify the SHA-1 signatures, which is much more effecient than software, but uses software to verify the RSA signatures. When validating content, be it games or other software, the Wii decrypts the RSA signature to produce what should be the software’s hash, then it calculates the real software’s hash and compares both the one generated by the RSA and the one generated by calculations done on the software, this is how they compare both hashes:

strncmp(RSAhash, CalculatedHash, n)

For those not knowing what this is, it’s a standard C function that takes two arrays of chars and compares them until either it finds a null byte (0x00), which is the standard array terminating char, on either of them or it reaches the number specified in the function, the number specified is used to tell the functions that neither of the two strings should have a size bigger than n, this is mostly done to prevent reading data that shouldn’t be read, or going outside the range of accessible RAM.
Now pay close attention to what I said: one of the reasons for this function to exit is if it finds a null byte (0x00), if we take into consideration that the software hash is calculated, in other words, it’s generated by being treated as integers, there can be 00’s in there, which when treated as an integer it doesn’t matter, but when treated as a string it means everything. So if both the RSA hash and the calculated hash have a 0x00, it doesn’t matter what ever comes after that, as it is not checked, imagine we have these two hashes:

1a 0b 88 9e 00 5c
1a 0b 88 9e 00 6c

Of course they are not the same, but since strncmp will stop comparing them when it reaches the null byte, it will report that they are the same, as strncmp only “sees” the first part before the 0x00, which actually matches.
Of course we don’t want to take any risk, so what we want to do is create an RSA key that will generate a hash that simply starts with the null byte and create software that, when hashed, will generate another hash that starts with 0x00, which can easily be done by bruteforcing, just change some bytes of the software (without breaking it) until the generated hash starts with 0x00, so you can fakely sign your own homebrews, system menu, IOS’s and even some parts of the boot sequence of the Wii.

This is what I like to call, epic fail.

EASIER THAN THE PSP!

I mentioned this earlier, other than the microkernel IOS running on the ARM Chip, the Wii has no actual Operating System, games run in bare metal on the Broadway, just like they did on the PS2 and consoles before it. Not even the PSP was like this, and we have to remember that the PSP was released in 2004 while the Wii was released in 2006, why Nintendo decided not to do this I have no idea, but I guess they wanted to cut as many costs as possible to have the maximum profit.
If you remember what I said with the PS2, we really didn’t need to hack any kernel or do any other thing than being able to run our own code, once we can run our code, we got full control of the system. This is not true of the PSP where we have usermode and kernelmode exploits, even if you hack a game and are able to run your own code, this code will run with some privileges level, as opposed to doing whatever you want, if you wanted full access you have to hack the kernel.
This is not true of the Wii, once you hack a game and gain the ability to execute code, you pretty much have the whole system hacked. This was shown by fail0verflow with their Twilight hack, where they hacked The Legend of Zelda: The Twilight Princess with simple buffer overflows like the ones we use on the PSP, it is also worth noting that the first PSP exploit I found, Pool Hall Pro, also existed on the Wii, but while the PSP version only allowed you to use VHBL, the Wii version granted you full access, cause there was no more barriers to defeat.

But this is not all of it, when installing software, the Wii only checks the package it’s going to install, if it’s authentic, it’ll install it, and once installed, it no longer checks it anymore, so any piece of software installed on the Wii’s NAND can be ran easily as it is not checked at all, the problem is getting it in there, but as I said, since games run in bare metal, once you hack a game or other software and are able to execute your own code, all you have to do is copy your software to the NAND and the Wii will have no problem loading it, that is how the Homebrew Channel came into existence, once again, by fail0verflow.

So we are now fully capable of running our own code and homebrews and are even able to make it permanent by installing onto NAND, what’s next? what is there that we haven’t done yet? oh that’s right! burning our own DVD’s!
Which brings me to my next point

GOD? WOD? WHAT ABOUT DVD?

The last nail in the coffin that was actually bad for the Wii as it is mainly used for piracy.
GameCube Optical Discs and their successors, Wii Optical Discs, are a special type of proprietary discs made by Nintendo to prevent easy access to the contents of the disc outside of the game systems, so when you pop the disc in a PC, the PC will not recognize it. In actuality, these discs are modified DVD’s, and the laser used to read them are modified DVD lasers, fully capable of reading DVD’s with very little need to modify the hardware.
But even so, the motherboard on the WOD drive has DVD playback disabled, so it will refuse to even read anything that is not a Wii game.

Nintendo originally planned for DVD-Video playback but scratched it in the last minute, instead of removing the code and all DVD commands from the drive, they simply disabled it.
IOS by default will not let you enable the DVD commands, unless told by software, and as we already know, we can run our own software. Eventually it was possible to play DVD-Video and other DVD formats with mplayer, but being able to play DVD-Video implies also being able to play burned DVD-Video which also implies being able to play pirated games, which is the really sad side effect of all this hacking.

CONCLUSION

Although I try to hide it, it is no secret that I dislike the Wii, a lot, I consider it a terrible successor to my beloved GameCube, but I did love all the clever hacking behind it and had a great laugh with all the stupid mistakes made by Nintendo. I recently bought a Wii not long ago for the sole purpose of playing Super Smash Bros, and when I was done I didn’t want the system to gather dust so I decided to see what I could do with it, and came across with the work of some of my favorite hackers, the fail0verflow team, hermes, waninkoko, and others, there’s a lot the Wii has to offer in terms of homebrews and hacking, and we can all learn from it, that’s why it deserves a spot in my 10 Days of Hacking.

Liked this article? Check Day 5: The PSP, and Day 7: The XBOX 360