Anatomy of the Zelda Save

Discussion in '3DS - Flashcards & Custom Firmwares' started by how_do_i_do_that, Aug 8, 2011.

Aug 8, 2011
  1. how_do_i_do_that
    OP

    Member how_do_i_do_that Blue Wizard is about to die.

    Joined:
    May 16, 2008
    Messages:
    4,805
    Country:
    Antarctica
    Anatomy of the Zelda Save


    Hardware Requirements:
    • Zelda OoT game
    • 3DS
    • NDS adaptor plus
    Other Requirements:
    • XOR decryptor/encryptor
    • Intermediate or higher understanding of hex editing
    Disclaimer
    This is not a tutorial or a guide. I will not be explaining anything beyond what is already written.

    If your going to post about when a save editor is going to be made, THIS ISN'T FOR YOU.

    Contents
    When starting the game for the first time. You can see that it has 3 save slots to choose from like below.
    [​IMG]

    As with the Master quest has 3 save slots as well.

    Locating the data in the save:
    Making easy to identify locations in the file, being unimaginative in naming makes all the difference for speed.

    For the Regular game saves I used
    Slot 1 : Link (was used to unlock masters)
    Slot 2 : Link 1 (created but not used)
    Slot 3 : Link 2 (created but not used)

    For the Master game save slots
    Slot 1 : Link M (used)
    Slot 2 : Link M1 (created but not used)
    Slot 3 : Link M2 (created but not used)

    Doing a search for Link as text in the save turns up nothing. Turning to hex, Link is represented as 4C696E6B, which still turns up nothing. Since it is based on a game that was on a cartridge, it likely used a char array, every character being follows with a null makes it 4C0069006E006B00. I used 4C0069006E006B since I do not know how the text is terminated in the save. It turns out to be a fixed number of fields.

    What turns up is 7 fields are identified in a game save where you do not have the master quest unlocked.
    [​IMG]

    In a save that has the master quest unlocked, 8 fields are identified.
    [​IMG]

    [​IMG]

    The locations moves around every time you use the in-game save function. This is evident from the searches of just 3 save dumps.

    In the 3rd save dump, locating the Slot 1 regular save turns up as the 5th location in the save dump.
    Warning: Spoilers inside!

    In the other 2 save dumps the location of the Slot 1 regular save is in different location. After a few more save dumps the locations changes again.

    From the random order and random locations would make a fixed location save editor impractical.

    The likelyhood that the game creates a backup for every save slot is very likely, with a total of 12 in all.


    The save dump looks like a container for bin files and the system.dat file that shows up. The contents are basically a header, then followed by the system.dat and then the saveXX.bin files. Each saveXX.bin looks like a wrapper and contains the contents of a save slot. I do not have a save dump from the N64 or the GC to compare to the 3DS to see how much of the saveXX.bin is an actual wrapper. Since we are nowhere near to just taking a saveXX.bin from a save dump, we'll have to deal with editing the save dump and adjusting the CRC and checksums.


    After using every save slot, it resulted in 15 occurances of Link (4C0069006E006B)
    [​IMG]




    Onto the inventory.


    Possible inventory locations was and compared to a normal save and a blank save.

    Blank save slot:
    Warning: Spoilers inside!

    Used save slot:
    Warning: Spoilers inside!


    Using things that are reasonablely known like the numbers of various items it was located to this area in the save.
    Warning: Spoilers inside!

    We have in the picture:

    30 sticks, in hex : 1E
    50 slingshot bullets, in hex : 32
    27 arrows, in hex : 1B

    The sticks are visible at CAA6 address, the hex number 28 is the code to determine the item.
    You will notice that the arrow contents are on the right side and not on the left side like the sticks next to it.

    Be aware that in EEPROM saves, a chunk of data is in reverse order every other chunk.
     
    Margen67 likes this.
  2. Cyan

    Global Moderator Cyan GBATemp's lurking knight

    Joined:
    Oct 27, 2002
    Messages:
    16,414
    Location:
    Engine room, learning
    Country:
    France
    It seems that every dumped saves are different, the Game slot is located in a different location in the decrypted file.

    • Does it have fixed order? like first slot can be placed where the second slot emplacement was on the previous save, and second takes first slot place?
    Or are each save slot always sorted in the same oder ? Slot1, followed by Slot2, then followed by Master's quest's slots, etc.

    • After few saves and redump, will the data location can be back at the same place it was previously?
    Or is there a random header length? (Though It should not really be random, else the game couldn't read it back.)

    Some addresses are identical in your save2 and 3, but not in the same order.
    Like there are "Link" occurrence in 0xC01C in save2 and save3, but there are different number of occurrence before that address in save2 and save3, but the same total number of occurrence. so it seems there are known address to put a save slot as it match the same address in both save files, but maybe not always written in the same order.
    Maybe (just imagine it) the save file can have 20 possible addresses to store all the 6 game slots, and it uses one of the twenty in a random order to fill the 6 save slots?
     
    Margen67 likes this.
  3. how_do_i_do_that
    OP

    Member how_do_i_do_that Blue Wizard is about to die.

    Joined:
    May 16, 2008
    Messages:
    4,805
    Country:
    Antarctica
    Inventory contents are relatively fixed to where the name is. Other than that the actual location in the save dump is not fixed.

    you can use a previous save dump, to overwrite any newer one you got. That is because of the checksums and crc used by the 3ds system to prevent tampering with the save file.

    The addresses reoccurs, but has no relation to if it is a save slot for the same game or is a backup.



    I'll have to pick up another copy of the game to see if I can use a dump from one game and put it on another. The save dump is tied to the region locked game so a dump from outside the region will automatically not work.


    Your going to have to wait for the 3DS Save DeEncrypter v1.5 with the improved CRC and checksum support before you can try save editing.


    Here is my most recent dump of the game: http://dl.dropbox.com/u/12315555/zelda_oot_005.sav
    You can decrypt it and look at the order of the games. There isn't a visible order to the saves.
     
    Margen67 likes this.
  4. Cyan

    Global Moderator Cyan GBATemp's lurking knight

    Joined:
    Oct 27, 2002
    Messages:
    16,414
    Location:
    Engine room, learning
    Country:
    France
    I don't even have that game.
    I'm more curious to understand how it's saved internally in that file than modifying the content for cheating in game.

    I find it strange that the "Link" occurrence is always at a different place (or more precisely stored in a different order).
    There is certainly a logical pattern to decide where each data have to be placed.


    Could you check where your current save slot (completed slot, with the full items) is placed after each re-play/save/re-dump?
    To see if there's a fixed pattern.
     
    Margen67 likes this.
  5. how_do_i_do_that
    OP

    Member how_do_i_do_that Blue Wizard is about to die.

    Joined:
    May 16, 2008
    Messages:
    4,805
    Country:
    Antarctica
    Margen67 likes this.
  6. ichichfly

    Member ichichfly GBAtemp Advanced Fan

    Joined:
    Sep 23, 2009
    Messages:
    618
    Country:
    Germany
    what have you used to get the blocks in the right order I mean the blockmaps, journal and so on ?
     
    Margen67 likes this.
  7. how_do_i_do_that
    OP

    Member how_do_i_do_that Blue Wizard is about to die.

    Joined:
    May 16, 2008
    Messages:
    4,805
    Country:
    Antarctica
    Comparisons to older save dumps mostly. And using a new save to locate the sticks since it is the first item you will get after the sword and shield and before entering the Tree.
     
    Margen67 likes this.
  8. kevan

    Member kevan Imagination rules the world

    Joined:
    Dec 4, 2009
    Messages:
    1,378
    Location:
    Place
    Country:
    Australia
    0_0.....
     
    Margen67 likes this.
  9. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,717
    Country:
    United Kingdom
    For reference "every character being follows with a null" is aka U16 unicode. That looks like hex workshop so check the "either" box under ASCII and unicode string in the file box.
    Worth a read
    http://www.joelonsoftware.com/articles/Unicode.html

    Anyhow grabbed your files and decrypted them.

    I am not sure the saves start at link but rather a few bytes before. Without checking your 3 backup saves idea works for me- similar things exist in many saves most notably pokemon.

    Assuming then we have backup saves those are going to want to be figured out but possibly more importantly is the first 1000 hex.
    Comparing the first 1000 hex from the 005 file to the 006
    0000 to 0600 appears identical (I will note a bit of what could be padding probably is not looking at the lines above) After this there something new to 08C0- possible length of section 2C0?

    Copied and pasted 0600 to 1000 into a new file.
    Setting column width to 20 hex looks good. If the FFFF FFFF stuff is indeed most entry padding than section padding that means each entry is 1C long
    2C0 appears to be a bit short on length as well- the extra section from the 006 file only makes 200 hex.

    Doing the same in the original files (well my first 1000 file) makes it seem like the first 140 hex is something else. The first 140 might also be able to be broken up into files A0 long. Moreover the first 140 could have entries A hex long.
    That it is the same for both files is interesting though especially given the later differences. I then looked at http://3dbrew.org/wiki/Savegames but it did not do much for me at the moment as I am not entirely sure how that and the dumper files line up although it does provide several clues to various things I see.

    Still the "backups" (the link says it is more partitions- some use backups, some ignore and some actually make use of them) might not be at game level but rather system/SDK level (it covers wear levelling in some detail there) and it looks like that format is going to have to be accounted for before pushing forward properly but some stuff could still be inferred. It also says things kick off at 2000 hex which means you also have the 1000 hex to 2000 hex section to deal with (I see ZELDA in plain ASCII in there), in 005 this pattern repeats (not necessarily in hex) every 1000 hex until C000 which marks the first save point.
    Curiously there are only two "SAVE" sections in the 006 file where there are three in the 005.

    I then went and did a strings search in the entire file. Some noise of course but some interesting stuff
    http://pastie.org/2341805 (apologies for this but it was quite long)

    I looked at a few more things and it seems to hold.
     
    Margen67 likes this.
  10. how_do_i_do_that
    OP

    Member how_do_i_do_that Blue Wizard is about to die.

    Joined:
    May 16, 2008
    Messages:
    4,805
    Country:
    Antarctica
    I used Link as a point of search, since it is the only thing I can control.
     
    Margen67 likes this.
  11. Immortal_no1

    Member Immortal_no1 GBAtemp Regular

    Joined:
    Jul 17, 2003
    Messages:
    266
    Country:
    United Kingdom
    It all starts 28 bytes before Link, this is what i was looking at last night:


    57 04 00 00 01 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 31 00 00 00 00 00 06 01 02 00 5A 45 4C 44 41 5A 02 00
    W............€..............L.i.n.k. .1.........ZELDAZ..

    66 02 00 00 01 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 32 00 00 00 00 00 06 01 02 00 5A 45 4C 44 41 5A 02 00
    f............€..............L.i.n.k. .2.........ZELDAZ..

    1B 04 00 00 00 00 00 00 00 00 00 00 4C 7C 00 00 00 00 00 00 2B 00 00 00 2B 00 00 00 4C 00 69 00 6E 00 6B 00 00 00 00 00 00 00 00 00 04 01 02 00 5A 45 4C 44 41 5A 52 00
    ............L|......+...+...L.i.n.k.............ZELDAZR.

    11 02 00 00 01 00 00 00 00 00 00 00 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 4D 00 32 00 00 00 07 01 02 00 5A 45 4C 44 41 5A 02 00
    .............€..............L.i.n.k. .M.2.......ZELDAZ..

    11 02 00 00 01 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 32 00 00 00 00 00 06 01 02 00 5A 45 4C 44 41 5A 03 00
    .............€..............L.i.n.k. .2.........ZELDAZ..

    @0xC000
    67 04 00 00 00 00 00 00 00 00 00 00 97 6B 01 00 00 00 00 00 25 00 00 00 25 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 4D 00 00 00 00 00 06 01 02 00 5A 45 4C 44 41 5A 78 00
    g...........—k......%...%...L.i.n.k. .M.........ZELDAZx.

    1B 04 00 00 00 00 00 00 00 00 00 00 4C 7C 00 00 00 00 00 00 2B 00 00 00 2B 00 00 00 4C 00 69 00 6E 00 6B 00 00 00 00 00 00 00 00 00 04 01 02 00 5A 45 4C 44 41 5A 52 00
    ............L|......+...+...L.i.n.k.............ZELDAZR.

    57 04 00 00 01 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 31 00 00 00 00 00 06 01 02 00 5A 45 4C 44 41 5A 02 00
    W............€..............L.i.n.k. .1.........ZELDAZ..

    BB 00 00 00 01 00 00 00 F1 FF 00 00 AB 6A 01 00 01 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 4D 00 32 00 00 00 07 01 02 00 5A 45 4C 44 41 5A 00 00
    ».......ñÿ..«j..............L.i.n.k. .M.2.......ZELDAZ..

    66 02 00 00 01 00 00 00 00 00 00 00 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 4D 00 31 00 00 00 07 01 02 00 5A 45 4C 44 41 5A 03 00
    f............€..............L.i.n.k. .M.1.......ZELDAZ..

    57 04 00 00 01 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 31 00 00 00 00 00 06 01 02 00 5A 45 4C 44 41 5A 02 00
    W............€..............L.i.n.k. .1.........ZELDAZ..

    66 02 00 00 01 00 00 00 00 00 00 00 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 4D 00 31 00 00 00 07 01 02 00 5A 45 4C 44 41 5A 02 00
    f............€..............L.i.n.k. .M.1.......ZELDAZ..

    67 04 00 00 00 00 00 00 00 00 00 00 97 6B 01 00 00 00 00 00 25 00 00 00 25 00 00 00 4C 00 69 00 6E 00 6B 00 20 00 4D 00 00 00 00 00 06 01 02 00 5A 45 4C 44 41 5A 79 00
    g...........—k......%...%...L.i.n.k. .M.........ZELDAZy.


    The 5th Byte shows 00 for Link and Link M, shows 01 for all others, most Likely this is the last used Save File for each type.


    Bytes 21 & 25 Appear to show the relation to the others, For example:
    21&25 on Link M is 25 & 25
    21&25 on Link is 2B & 2B
    All the others are at 00 && 00 suggesting these are backups of the current

    Byte 37 - 41 on: Save banks
    Link M shows 20 00 4D 00 00 (notice 00 - 0)
    Link M1 shows 20 00 4D 00 31 (notice 31 - 1)
    Link M2 shows 20 00 4D 00 32 (notice 32 - 3)

    Link shows 00 00 00 00 00 (notice 00 - 0)
    Link 1 shows 20 00 31 00 00 (notice 31 - 1)
    Link 2 shows 20 00 32 00 00 (notice 32 - 2)


    The appearence of 4C 00 69 00 6E 00 6B 00 may be a Magic number

    The Last 2 bytes: could specify save counters? I haven't had a look too much into these.
    Link 52 00
    Link 52 00
    Link M 78 00
    Link M 79 00

    Link 1 02 00
    Link 2 03 00
    Link M1 02 00
    Link M2 02 00


    The CRC for the Filesystem on save 006 is Filesystem 1A6BA6A2D7C3BEE871D19C7982017254684E728619662629DBABB71296F10F45

    And the Checksum for the location where your latest save is: (i think this was the right one, in a bit of a hurry at the moment)
    0xC000 -> 0xCFFF
    Checksum = 73EEB421AD01CFC50801B3BC75343DD9A54010468D7C6A7DFD4DD5BC7F0915E6
    Offsets = 0xB080
     
    Margen67 likes this.
  12. Cyan

    Global Moderator Cyan GBATemp's lurking knight

    Joined:
    Oct 27, 2002
    Messages:
    16,414
    Location:
    Engine room, learning
    Country:
    France
    I see that it's in fact a Partition+File system, that's why the saves are not always saved in the same order in that file. It could be sorted by date, or file size, etc. instead of fixed address in a simple binary file.
    Once the format will be known, someone will certainly release a save file explorer/extractor/creator common for all games.

    If the CRC calculation is not known, at least file explorer and extractor will be possible.
     
    Margen67 likes this.
  13. Immortal_no1

    Member Immortal_no1 GBAtemp Regular

    Joined:
    Jul 17, 2003
    Messages:
    266
    Country:
    United Kingdom
    That's my plan, i know the locations of the partitions and the files within the locations but the addresses must have offsets that i haven't found yet, but as you can read in my post at Today, 12:04 AM on http://gbatemp.net/t303517-3ds-save-deencr...able?&st=45
    i'm working on it
     
    Margen67 likes this.
  14. damysteryman

    Member damysteryman I am too busy IRL these days...

    Joined:
    Oct 4, 2007
    Messages:
    1,182
    Country:
    Antarctica
    This interesting topic caught my eye today, so I did a bit of reading.

    http://3dbrew.org/wiki/Savegames
    I assume that this is the format you are looking for?
     
    Margen67 likes this.
  15. Immortal_no1

    Member Immortal_no1 GBAtemp Regular

    Joined:
    Jul 17, 2003
    Messages:
    266
    Country:
    United Kingdom
    FAST6191 put me onto that, it's in the same format that i'm using for my application.
    Wish i had of found that earlier!

    The Wear leveling is what i was talking about earlier this is what i believe is being done on the Zelda save, The area on the Filesystem is interesting and had a look over it, it has the offset values that i was looking at a couple of days ago but i can't seem to relate those values to the RE:M gamesave, they do however appear to match up more closely with the Zelda game
     
    Margen67 likes this.
  16. Immortal_no1

    Member Immortal_no1 GBAtemp Regular

    Joined:
    Jul 17, 2003
    Messages:
    266
    Country:
    United Kingdom
    how_do_i_do_that, can you backup your latest game save, then use the Create Reset Data function on the 3DS Save De/Encrypter v1.4 restore Zelda to it's blank Factory default, then start up the game and wait for the game to save on Boot. Once it's saved can you Eject the cartridge and extract the game save and upload it and post the link. I'll do the same for the UK Zelda to see if it will help with region changing of gamesaves. Follow the process exactly if you can to remove possible issues. Make a note of the time and date when you do it too and post that info 'to the second if possible'
     
    Margen67 likes this.
  17. how_do_i_do_that
    OP

    Member how_do_i_do_that Blue Wizard is about to die.

    Joined:
    May 16, 2008
    Messages:
    4,805
    Country:
    Antarctica
    Margen67 likes this.
  18. Immortal_no1

    Member Immortal_no1 GBAtemp Regular

    Joined:
    Jul 17, 2003
    Messages:
    266
    Country:
    United Kingdom
    Geez, did the same with mine, boy oh boy... the differences... some areas though look interesting, will get back to you on those in a bit, i need to try something out.

    http://dl.dropbox.com/u/37744708/Zelda_Blank.sav

    21:10:35 - Saved

    Same:
    FS Address
    0x4000
    0x16000

    FS Offset
    0x0400

    FST Offset
    0x200

    Entry #1
    system.dat
    34 bytes

    Same 2 Checksum areas:
    Checksum = AD7FACB2586FC6E966C004D7D1D16B024F5805FF7CB47C7A85DABD8B48892CA7
    Offsets = 0x18040 0x19040 0x1B040

    Checksum = F1D2B81B4F6D9653913FC766E78767B2D7092A1F7338C82FA2B884EA7A30E269
    Offsets = 0x17040

    One checksum didn't match:

    UK
    Checksum = 0FBFB279DEE6C7B415527C2B9183A29ECC1BA9FF0D969C1BC3B2CF448A412932
    Offsets = 0x3040

    USA
    Checksum = AD37DC7C0D6EA741C4DFE1AE5B708E8070C4A6CC5138DE9594DE3DAD327B7788
    Offsets = 0x3040

    Checksum was in the same place but had different data hense the checksum was different. This area was one of the Filesystem SAVE areas
     
    Margen67 likes this.
  19. how_do_i_do_that
    OP

    Member how_do_i_do_that Blue Wizard is about to die.

    Joined:
    May 16, 2008
    Messages:
    4,805
    Country:
    Antarctica
    You'll need to get saves from other regions if you want a better comparison.
     
    Margen67 likes this.

Share This Page