Digging Into The Twilight Hack That Brought Us Wii Homebrew

With each new game console, there’s an effort to get around whatever restrictions exist to run your own software on it. In the case of the Nintendo Wii, the system was cracked through one of its most popular games — The Legend of Zelda: Twilight Princess. How this hack works was recently covered in detail by [Skawo].

The key for this ‘Twilight Hack‘ is to use a modified game save that allows you to run arbitrary code from an SD card, something which was first patched out of the Wii firmware with version 3.3. As shown in the video using the source code, the basic concept is that the name of Link’s horse in the game is changed in the save file to be longer than the allocated buffer, which leads to a buffer overflow that can be used to reach the application loader code.

Interestingly, while the horse’s name can only be 8 characters long, and the buffer is 16 bytes (due to ShiftJIS two-byte encoding), the save file loading code allocates no less than 100 bytes, for some reason. Since the code uses strcpy() instead of strncpy() (or C11’s strncpy_s()), it will happily keep copying until it finds that magic 0x00 string terminator. Basically the horse can have any name that fits within the save file’s buffer, just with no null-byte until our specially crafted payload has been copied over.

Although it took Nintendo a few months to respond to this hack, eventually it was patched out in a rather brutal fashion by simply searching for and wiping any modified save files. Naturally this didn’t stop hackers from finding ways to circumvent this save file check, which led to more counter-fixes by Nintendo, which led to more exploits, ad nauseam.

Even with firmware update 4.0 finally sunsetting the Twilight Hack, hackers would keep finding more ways to get their previous Homebrew Channel installed, not to mention so that they could keep watching DVDs on a Wii.

40 thoughts on “Digging Into The Twilight Hack That Brought Us Wii Homebrew

    1. And even if a time traveler had brought C11 with them, strncpy_s() is mostly a lie. It’s optional and the spec for _s functions is bad.

      This leads to a situation where there is still no good portable always-null-terminating strncpy() alternative.

  1. Personally I don’t see why Nintendo didn’t see Wii home brew as an opportunity to make their product better and thus make more money.
    Okay, patch the loose code that led to the exploits, but then if they, instead of starting a turf war, themselves just added a channel or game disk, enabling the functionality, they could have taken advantage of the demographic need and largely kept control of things for the majority.

    1. Similar to what Microsoft has done with recent Xboxes; if you sign up for a (paid) developer account, you can put your xbox into dev mode and run whatever code you want. This probably slightly reduces the number of people trying to jailbreak them.

  2. Still don’t understand why Nintendo wouldn’t sell two versions, open source and closed source. Since tinkerers are a minority, it would hardly make a splash in their investors’ annual reports.

    By now Wii is so outdated, might as well just open it up, btw. No compute.

  3. Nintendo is a very closed hardware ecosystem. Ive sat out since the wii, consoles which end as bricks offends my hacker sensibilities. The og NES is not a brick, gameboys up until DS are not bricks.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.