Talk:Wii Savegame Parser

Talk: Savegame Parser

Hi all, Im getting interested in the hack of the savegames. It looks a first step to hack all the ecryption protections of the Wii, because it could provide many information about algorithms used by the console. In other hand, I'm interested in security and it seems to be a entertainment exercising the knowledgement.

I'm using a Wii and games bought in Germany. I've made several comparisions between savegames of Zelda and WiiSports.

I've converted the script to C# and written a small application which parses the savegames.

Comparing the data with the parser, the first remark is with the magic value right after the Mac Address. Istead of a 0xF5550000 I've got a 0x90900000. Hmmmmm... Different zone?

It is interesting for me the size of the hashes. The most used standard algorithms are: MD4 16 bytes (algorithm broken) MD5 16 bytes (algorithm broken, but still in use because its an internet standard) RIPEMD 16 bytes SHA-1 20 bytes SHA-224 28 bytes SHA-256 32 bytes SHA-348 48 bytes SHA-512 64 bytes I don't know any hash algorithm with a digest of 60bytes like the most of the hashes sizes in the savegame file. Could it be a signed hash? In that case, the size of the signature depends on the size of the key. Hmmm more investigation is needed here.

The hash #1 is a 16 bytes array. It seems to be depending on the game. I have the same hash for all the WiiSports savegames and another for the all the Zelda ones. I would say it is some kind of hash of the header.

First experiment: I've saved twice in different cards the same savegame of Zelda. I've compared the two serialized files, and the only differences are in the Hashes #2, #5 and #6. The rest of the files are identical. In that case, I can suppose that some kind of Initialization Vector is used. But in this case the encrypted data is the same, which makes me think that its better some kind of timestamp, probably in the Hash #2, which makes different the other two hashes. So they don't use IV for encryption.

Second experiment: I've saved two games (Zelda and Wiisport) in different days. When comparing the files, I'm trying to check which data is the same, so it depends only on the Wii. Basically the header is different, the hash #1 too (which I think depends on the game) too, the block sizes are different and the encrypted data too. But hash #3, all the RootCA information and hash #4 are identical, which means they are independendent of the game and the time.

Hmmm I'll continue investigating. Greetings! Aykito.

Why is it rejecting/accepting modified files inconsistently?

I've been tinkering with the save files and the results are bizarre. For example, I took a Wii Sports file and changed the "number of files" to 2, and it copied back to the system just fine. I tried some other values and it wouldn't copy anymore, so I tried 2 again and it still wouldn't! But after changing back to 1, it would copy again, and I checked no other bytes were changed. WTF? This happens in other cases too, such as the file size. It accepts the first change, but after that only the original file. 142.59.173.240 22:00, 22 March 2007 (PDT)

Format Testing

• 0x0000 - 0xF0C0: Header - Guessing it's an Image since it's the same for all saves from same game.
• 0xF0C0 - 0xF0C4: Magic = 0x00000070 (112L)
• 0xF0C4 - 0xF0C8: Magic = 0x426b0001 (1114308609L)
• 0xF0C8 - 0xF0CC: Wii ID (same as certificate in later section)
• 0xF0CC - 0xF0D0: Number of files in this save file.
• 0xF0D0 - 0xF0D4: Size of all files in this save file.
• 0xF0D4 - 0xF0D8: Magic = 0x00000000 (0L)
• 0xF0D8 - 0xF0DC: Magic = 0x00000000 (0L)
• 0xF0DC - 0xF0E0: Post Header Length (This plus the data at 0xF0D0 equals the file size)
• 0xF0E0 - 0xF120: 64 (0x40) bytes of Zeros
• 0xF120 - 0xF124: Magic = 0x00010000 (65536L)
• 0xF124 - 0xF128: Four character program ID, e.g. "RSPE"
• 0xf128 - 0xF130: MAC address of Wii. (plus two wasted bytes)
• 0xF130 - 0xF140: 16 byte hash. Probably hashes Header (0x0000-0xF0C0) since it changes as that data changes.

-- Per File Data --

• 0xF140 - 0xF144: Magic = 0x03adf17e (61731198L)
• 0xF144 - 0xF148: File Size of this file (For this example, assume size of 0x20000)
• 0xF148 - 0xF149: Unknown Byte, values are 0x30, 0x34 and 0x3C
• 0xF149 - 0xF14A: Unknown Byte, values are 0x00
• 0xF14A - 0xF14B: Unknown Byte, values are 0x01
• 0xF14b : Zero terminated file name, e.g. 'RPSports.dat'

Unclear how things are ordered:

• Possible string file name filler
• File Data, length from 0xF144
• Possible Data Filler to round data out to 64 byte boundary

-- Done with Per File Data -- Addresses assume file size of 0x20000

• 0x2F1C0 - 0x2F1FC: Hash data, 60 (0x3C) bytes long. This is suspect since it always starts with a zero byte* .
• 0x2F1FC - 0x2F200: Magic = 0x00000000 (0L)
• 0x2F200 - 0x2F204: Magic = 0x00010002 (65538L)
• 0x2F204 - 0x2F240: Hash data, 60 (0x3C) bytes long
• 0x2F240 - 0x2F280: 64 (0x40) bytes of zeros
• 0x2F280 - 0x2F2C0: String "Root-CA00000001-MS00000002" followed by 37 (0x25) zeros. (64 bytes total)
• 0x2F2C0 - 0x2F2C4: Magic = 0x00000002 (2L)
• 0x2F2C4 - 0x2F304: String "NG00000000" with 53 (0x35) zeros. This is the same Wii ID as above. (64 bytes total)
• 0x2F304 - 0x2F344: Hash data, 64 (0x40) bytes long.
• 0x2F344 - 0x2F380: 60 (0x3C) bytes of zeros
• 0x2F380 - 0x2F384: Magic = 0x00010002 (65538L)
• 0x2F384 - 0x2F3C0: Hash data, 60 (0x3C) bytes long.
• 0x2F3C0 - 0x2F400: 64 (0x40) bytes of zeros
• 0x2F400 - 0x2F440: String "Root-CA00000001-MS00000002-NG00000000" followed by 26 zeros (64 bytes total)
• 0x2F440 - 0x2F444: Magic = 0x00000002 (2L)
• 0x2F444 - 0x2F484: String "AP0000000100000002" followed by 45 zeros (64 bytes total)
• 0x2F484 - 0x2F488: Magic = 0x00000000 (0L)
• 0x2F488 - 0x2F48C: Hash data, 60 (0x3C) bytes long

• Yeah the math is off by one for the ending address.