Talk:Wii Savegame Parser

Hi all, I'm getting interested in the hack of the savegames. It looks a first step to hack all the encryption 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 comparisons 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. Instead 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 it's 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 independent 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.

Elliptical Hash Info

There is new information about the hash used in the save game file. See the forum post here: http://forums.nintendo-scene.com/index.php?topic=797.0. "The crypto used for wii savegame files is sect233r1"

This refers to hash 6 from the output of the Savegame Parser. I was able to verify this by compiling OpenSSL, checkkey.c (from the forum and running it with the data from one of my save games. Here is the output (for what it's worth):

D:\>WiiCheckKey.exe 0010A5965B39842061168F9E548CD0C1DB77181BD470905071C41D7BB62C 0128946F2BEB5F3A621F1964212DED020C1239E256B50B60E321B1C95450 Read key data: PUBX: 0010A5965B39842061168F9E548CD0C1DB77181BD470905071C41D7BB62C PUBY: 0128946F2BEB5F3A621F1964212DED020C1239E256B50B60E321B1C95450 Checking key: **** Valid public key ****

It's interesting hash3 and hash5 didn't come up as valid keys. I don't know if that's a parser problem of something else.

--PaceMaker