399
edits
Changes
→Save files
* The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write.
* The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write.
Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly|FireFly]] 17:18, 18 December 2011 (CET)
Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly|FireFly]] 17:18, 18 December 2011 (CET)
::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8|Yellows8]] 18:56, 18 December 2011 (CET)
:::From my experience, each saving takes a 0x1000 block and saves is somewhere else...when you xor 2 files it doesn't mean anything because the data maybe xored with other encrypted data so no clear text. For data to be discovered the first file needs to have an encrypted data at some offset and 2nd file will have encrypted 0xff at the same offset. this is rather rare for the 3ds to delete its backups... --[[User:Elisherer|Elisherer]] 07:28, 19 December 2011 (CET)