Wii Stack Smashing Explanation

So there has been a lot of talk about the Zelda : Twilight Princess save hack that is floating around wiibrew, and not a lot of people actually understand what is going on here, and how simple the hack really is.

I will try to update this as I do more research, but this should make sense to those who follow Aleph1's smashing the stack for fun & profit.

The first thing that is needed to fill the buffer with "shellcode" like Aleph1 uses, is to grab the latest Devkitpro (http://www.devkitpro.org/) and start compiling your very own GC/Wii code via the libogc. Rummage through the examples until you get to the part where you can actually compile, then take a look at some of the DOL launcher sources out there (real source to come later.)

Once you have a successfully compiling piece of code, you'll need to rip the actual opcodes from the binary file to obtain what we will be needing to fill the buffer with. (explanation of how to do this also coming later.)

Now that you have the opcodes, double check for 0x00 so you don't wind up with an end of string error, and get ready to find the magic number that lets us overwrite into places of the forbidden.

So for example, in Zelda, when a dialogue box is popped up to say the horses name, it reads the save data into a buffer using a strcpy() (which its assuming is some magic number at this point), and puts that into our dialogue string. However, because we've hijacked the horse's name and are overloading it so that strcpy actually overflows into the next chunks of data in memory, we can take control of the EIP and start running our opcode we saved earlier.

So much like Aleph1's demonstration, we have [bogus nops][opcode][eip rewrite], the dialogue calls strcpy, hits the eip rewrite, jumps us back to our opcode, and we have full control. Power to the PPC!

Now this is speculation, I haven't actually coded this hack and I don't know how the Wii save compression/decompression works, so there could be some more complicated steps in this procedure. However, because this relies on a strcpy() on an invalid name, one could speculate that many games are vulnerable to this. Nintendo does not require a full security assessment when validating games, so it is very feasible that other Nintendo games & 3rd party games are equally vulnerable (any game that saves some sort of name, and later calls an unsafe strcpy.) I might go through my collection and see if I can come up with a list. If I can figure out how they are compressing the saves without an official NDEV kit, I'll try to post some of my findings.

**** Note about Wii Patch 3.3

So essentially the reason why this was broken so quickly was Nintendo literally introduced a kernel function that checks for a Zelda hack memory file (its like a more complicated md5/sig checker.) What they are supposed to do is introduce a stack protection scheme into the kernel, but could they do this without rewriting half of their kernel calls?? Probably not, and they don't want to spend the hundreds of thousands of dollars that would cost them just to prevent a few homebrewers from running their favorite software on the thing.

I believe the PS3 & Xbox 360 are both safe from this type of attack because of stack protection measures, they probably introduced this into the Xbox 360 early on just because its such a buggy system in the first place :) If I'm wrong on that one, please correct me! The PSP was 100% vulnerable, and you can see it with the Lumines & GTA exploit. There was also a common TIFF library exploit I believe it was, that allowed the < 2.00 psps from being cracked. But I'll leave that for another day :)