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)

Things that need to be looked into

• What is the relationship between hash1 and the header?
• Is the header a image? What format?
• Why does hash2 always start with a zero? It tells me we're off by one byte somewhere.
• What does the per file padding really look like?
• Verify all hash sizes.