meladroit
commented
9 years ago There are a few things that make this tricky:
- We can't automatically detect title IDs for digital titles right now. (See issue #2.) We could still get around this by looking up some identifier in the save file itself.
- As you mention, the offset is different for every game. However, if we can get the title, having a lookup table for secure value offsets wouldn't be too bad.
- It looks like for at least one game (SSB) multiple files have to be updated. (Is the secure value different for each file, in that case?) At least for SSB the offset is the same for both files, but I'll have to get the implementation right from the start to accommodate for worst possible scenarios (imagine if the secure value was on every single one of Rumble World's .dat files, and the offset was different for every single one of them ...)
- Rumble World's measure sounds especially tricky. However, at least it's not a proprietary compression/checksum, just zlib with CRC32. So, potentially possible to implement here.
I'll definitely give this some thought, but it's also definitely a comparative luxury. But at least it looks like the number of games using this (that people care about, anyway) is small?
YodaDaCoda
A number of games have a 'secure value' in their save data which is generated each time the game is saved. A copy of this value is stored on the 3DS itself, and if these values don't match when the game is started, then the save is declared corrupt. The offset at which this value is stored changes per game.
More about this can be read here. http://3dbrew.org/wiki/Anti_Savegame_Restore
Here is a GBATemp thread which gives the offsets of a number of games' save files. https://gbatemp.net/threads/antisavegame-restore-secure-value-updater-ps-acnl-prw-ssb-xy-oras.396644/
It'd be handy if svdt were able to handle this so that we don't have to.