Talk:Savegames

Active discussions
Revision as of 17:29, 4 August 2011 by Luigi2us (talk | contribs)

Unknowns:

  • Hashes at the end of each DIFI blob.
  • How order / location of hash vs. partitioned blocks is determined. (since not sequentially).


I think there should be a page with infos on how to dump/restore saves. Matyapiro:So then,I show you how to do dump and restore saves. First,you should have either Nintendo DS/Lite or NDS Adapter a tool to dump DS saves. It can restore saves,but Almost saves cannot dump with NDS Adapter,but some of them can. If you have Nintendo DS or DS Lite,you should try DSaveManager. It uses FTP to dump saves,only dump. Last,I show you another save backup tool for DS. NDS Backup Tool by Rudolph. Eepinator by WinterMute


Hardware:

  • NDS Adapter Plus (by hkems)
  • DS/DSLite & DSaveManager
  • Neo SMS4 (by neoflash, untested)

But I cannot find any key word like player name,high score or play time if I decrypt the save.

How do you think about whether any other encryption or special way to read/write save used ?Matyapiro

  • I found those things in a SSFIV saved game...

The important offsets are usually constant, the values change, it's not hard to look for an offset of data that's changing predictably after you re-save.

Sometimes you have to use your imagination. To find 20,000 points in SSFIV, you'd search for "0xC8" ( 200 in decimal == "20,000" in game ) because it stores the points in multiples of 100. It's easier to see if you're editing saves in front of yourself and constantly making minor changes to it - to see where those changes show up later. --jl

So we need analyze project with each save.?Matyapiro

  • Only if you're trying to figure out where the game data is. Just common sense.
  • You can examine each save manually after making small changes ( while playing with it on the 3DS ) but we still don't know what all the hashes are being used for.

spell error?What's this? ~Partitions are "catted" together  Matyapiro

  • Concatenated. Attached, joined, appended. One follows after the other. lol.

I looked into that blockmap structure thing, but I fear I didn't get it right...

  • sectors would be 4096 bytes. The Rayman 3D save is 128mb and has 31 blockmap entries; the Ridge Racer 3D save is 1mb but only has 127 blockmap entries (however the second half of that save is mostly a mirror of the first half, except for the first (special) sector).
  • the dword at the beginning of the image tells the sector size (1<<val = sector size)?
  • blockmap entries are phys_sec,alloc_cnt,checksum instead of checksum,phys_sec,alloc_cnt. There are then two spare bytes between the blockmap and the journal.
  • bit7 of phys_sec in blockmap entries is set when the entry's checksum isn't zero