So... I've taken it upon myself to take a peek at the savedata the Wii uses. I transferred over three savedata files to my SD card and popped them into a hex editor.
Thus far I've discovered several things.
1. There's a header at 0xF120 in every savedata file. Byte 0xF121 always appears to be 0x01, and 0xF124-0xF127 is the 4-character game code for the game. This same code is the folder name for where the data is stored.
2. At 0xF128, your MAC address is stored in hex.
3. At 0xF14B, there's a filename. Not sure what the maximum length is; I've seen "RPSports.dat" (for Wii Sports), "zeldaTp.dat" (for TLoZ: Twilight Princess), and "SYSTEM" without an extension (for Super Monkey Ball). These filenames appear to be largely internal (i.e. only recognized by the game itself), as I believe they're being recognized by the Wii itself as "AP0000000100000002" (as I explain later on).
4. The last 772 bytes of the file appear to be a summary section of some sort. The first 4 bytes are 0x00, followed by 64 bytes that are the same per system; I assume that it's a checksum for the first folder in the archive. I haven't tested with other systems yet, so I'm not making any solid assumptions about that. This is followed by 64 bytes of 0x00.
After these first 132 bytes comes (for my savedata at least) "Root-CA00000001-MS00000002". At first I thought this was an identifier for some sort of CAB file, but after some investigation that doesn't seem too likely. I think it may be a folder name for Nintendo's own proprietary archive format. I'll explain why later.
Next is 42 bytes of 0x00. Then, on my system, I see "NG040f3499". Not sure what that is; it might be my serial number. I haven't even checked that yet. I get the feeling it may be a folder name - a subfolder of the first folder, maybe. Kinda like a file listing - display the folder name first, then the files/folders in it, then for each file/folder, list some information about it.
Next is 54 bytes of 0x00. Then comes a 64-byte-long block of binary - I'm guessing that it's a CRC, or a SHA-1, or something like this. It's the same in all the savedata I've seen, which suggests to me that it's a checksum for the "NG040f3499" folder, which seems to always contain the same folders/filenames, so a constant checksum would make sense.
... OK, I'm starting to confuse myself here. Anyways, here's what it looks like:
I'm still trying to figure out why things are ordered the way they are.
5. Replacing the - with \ seems to make sense. I tacked on 'archive:\' to make it look like a sensible path. The 0x02 seems to indicate that it's a child of the previously-listed item.
(0x02 - child of archive:\Root\CA00000001\ MS00000002)::NG040f3499
(0x02 - child of archive:\Root\CA00000001\ MS00000002\NG040f3499)::A P0000000100000002
It looks like AP0000000100000002 is a reference to the file in the archive - the one whose filename is stored at 0xF14B.
6. Most interesting to me is byte 0xF0DC. Why, you ask? Well, it's very intriguing :) Stored in big-endian hex there is a number indicating the length of the file! Subtract 28 from this number and you get *exactly* how many bytes remain in the file after 0xF0DC. This... is sexy. In other words, go to 0xF0BF, move forward the number of bytes indicated by the number at 0xF0DC, and you'll be at the end of the file.
Why is this "sexy?" Well, I get the feeling that it would be pretty difficult for Nintendo to change the way this works. From what I've heard, all the games for the Wii are loader-independent - that they're 100% pure machine code, and that they can run by themselves without really needing to be loaded by the OS. In other words, the game is independent of the Wii OS. I assume this is to make it so that a wide variety of changes can be made to the OS without affecting how gameplay works. This might not be true, since making a game OS-independent could be *really* difficult, and unnecessarily complicated. Of course, if there's a general template that developers can use for this when they make their games, it could actually be pretty simple, since much of the work could be done for them by the devkit.
If this is true, it means that an OS patch *would not* change the way savedata is stored on the Wii. Which means that - IF THIS IS TRUE, OF COURSE, and that's a BIG IF - any exploit based on savedata for the Wii would be unfixable.
So, what's next? Obviously (for a hacker such as myself ;)), to pad extra data onto the file... or to change the value at 0xF0DC. Gotta see what this does!
If I find out anything else, I'll be updating this post, of course.