Hacking the Wii, fact and theory

Jan 07, 2008 22:08

With the current state of the Wii, I figured it would be good to go over the recent hack and my own personal theories.

Recently, there was an amazing hack that allowed the Wii to execute non-nintendo signed code. http://www.wiili.org/index.php/Wii_homebrew Has more info. The information is quite revealing and the source is very reputable, especially since it's at the CCC convention in Germany before many other hackers. The demoed exploit worked with a drive chip like the wiiboss or wiikey to bypass the protection against running burned DVDs. The code from what most likely is lego star wars, was used to boot into their own code directly from the wii menu.

The code was signed and encrypted with with the Wii's private key, which was obtained by booting homebrew gamecube code and exploiting a bug in ati's graphic chipset's hardware to read ram that normally can not be reached. In this ram was this secret code.

Now in order to make immediate use of this hack, a user will probably need a drive chip to disable checking for a burned DVD in order to execute this. However, I have a few theories on getting around this. Back when the Wii shop was hijacked to try making a make shift browser and being directed to google, there were some interesting proof's of concepts to redirect the wii to another host. Since we now have access to Wii updates from pirated Wii discs, we should be able to modify a release, say from Mario Galaxy, and redirect the Wii to a website to download the modified firmware from and flash it for us to remove the checks without needing a modchip. This could pave the way for homebrew firmware to launch homebrew, copied games, gamecube games, and gamecube homebrew without the need to open the console.

That is only one avenue of attack. Another would be the channels/virtual console. Since we may be able to now dump an unencrypted copy of firmware, we can look to see how these channels load and use that information to decrypt a virtual console game, write a pc program to lock it to another wii, transfer it to an SD card and run it to execute GCOS, flash the firmware for us, or boot a burned disc via a secondary disc channel.

Finally, Datel released power saves recently. If we can find a bug to crash a game and get it to run our code, like the xbox softmod, we can allow it to boot from a burned disc or run some code for us to allow flashing. Sadly this is the most unlikely scenario to happen, but is a completely different venue of attack for us to use which may help us learn more. Red Steel is so poorly programmed, I am sure we can somehow use it to do this.

This is now speculation, but has anyone tried coping a game, booting the original, and swapping it out with the copy? Since we are now out of the Wii's firmware, I think, we should be free of checking if the disc is burned or not. Because of tis new method of homebrew, we might be able to say, load lego star wars, go to the title screen, swap out the disc for a copied one with different code that can load when the user starts the game.

With the Wii's semi-recent USB keyboard support, perhaps someone can simulate a keyboard through a usb interface on a computer and possibly cause a stack overflow inside the firmware as well? Playing MJPEGs on the Wii is another idea.... can we create video data that can crash the photo channel? Buffer overflows are <3.

Ideas and theories... I'm sure anyone reading this might not be very interested in something this technical, but on the offshoot that you are, I would love to hear your ideas, comments, methods, and theories as well.
Previous post Next post
Up