Changes

Jump to navigation Jump to search

Savegames (view source)

Revision as of 17:42, 20 November 2019

6,302 bytes added ,  17:42, 20 November 2019
→‎Extra data: fix save struct link
Line 1: Line 1:  
This page describes the format of save files contained in NAND. These files are stored as completely unencrypted, plaintext data. Save files are not cleared upon creation, resulting in possible garbage data in unused portions of the container.
 
This page describes the format of save files contained in NAND. These files are stored as completely unencrypted, plaintext data. Save files are not cleared upon creation, resulting in possible garbage data in unused portions of the container.
   −
== Main header ==
+
= Main header =
    
The header is 0x4000 bytes long.
 
The header is 0x4000 bytes long.
    
There are 2 headers stored at 0x0 and 0x4000, presumably for commit and rollback purposes.
 
There are 2 headers stored at 0x0 and 0x4000, presumably for commit and rollback purposes.
 +
 +
Decimal versions are separated as Major, Minor, Micro, and Bugfix with each using one byte. e.g. version 3.4.5.6 would be 0x03040506.
    
{| class="wikitable"
 
{| class="wikitable"
Line 64: Line 66:  
The additional storage at the end of the header is used to store any extra header data. This data's structure is determined by offsets stored in the main part of the header.
 
The additional storage at the end of the header is used to store any extra header data. This data's structure is determined by offsets stored in the main part of the header.
   −
=== AES CMAC header ===
+
== AES CMAC header ==
 +
 
 +
This is internally referred to as MasterHeaderMac.
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 82: Line 87:  
The final CMAC key used for this is generated using GenerateAesKek with a kek source and the device key, along with and LoadAesKey and a set key seed.
 
The final CMAC key used for this is generated using GenerateAesKek with a kek source and the device key, along with and LoadAesKey and a set key seed.
   −
=== DISF ===
+
== DISF ==
    
This section contains information about the structure of the save file.
 
This section contains information about the structure of the save file.
Line 98: Line 103:  
| 0x004
 
| 0x004
 
| 4
 
| 4
−
| Version? (Upper 2 bytes must be 0x0004)
+
| Version (Major version must be 4 or 5. Only system version 5.0.0+ can read version 5 save files)
 
|-
 
|-
 
| 0x008
 
| 0x008
Line 260: Line 265:  
| Index of the active duplex master bitmap
 
| Index of the active duplex master bitmap
 
|-
 
|-
−
| 0x200
+
| 0x160
−
|
  −
| End
  −
|}
  −
 
  −
=== Duplex header ===
  −
 
  −
* Block sizes are stored as powers of 2
  −
 
  −
{| class="wikitable"
  −
|-
  −
! Start
  −
! Length
  −
! Description
  −
|-
  −
| 0x00
  −
| 4
  −
| Magic ("DPFS")
  −
|-
  −
| 0x04
  −
| 4
  −
| Version? (Upper 2 bytes must be 0x0001)
  −
|-
  −
| 0x08
   
| 8
 
| 8
−
| Master bitmap offset
+
| [5.0.0+] File allocation table IVFC master hash offset A
 
|-
 
|-
−
| 0x10
+
| 0x168
 
| 8
 
| 8
−
| Master bitmap size
+
| [5.0.0+] File allocation table IVFC master hash offset B
−
|-
  −
| 0x18
  −
| 4
  −
| Master bitmap block size power
   
|-
 
|-
−
| 0x1C
+
| 0x170
 
| 8
 
| 8
−
| Level 1 offset
+
| [5.0.0+] File allocation table IVFC level 1 virtual offset
 
|-
 
|-
−
| 0x24
+
| 0x178
 
| 8
 
| 8
−
| Level 1 size
+
| [5.0.0+] File allocation table IVFC level 1 size
−
|-
  −
| 0x2C
  −
| 4
  −
| Level 1 block size power
   
|-
 
|-
−
| 0x30
+
| 0x180
 
| 8
 
| 8
−
| Level 2 offset
+
| [5.0.0+] File allocation table IVFC level 2 virtual offset
 
|-
 
|-
−
| 0x38
+
| 0x188
 
| 8
 
| 8
−
| Level 2 size
+
| [5.0.0+] File allocation table IVFC level 2 size
−
|-
  −
| 0x40
  −
| 4
  −
| Level 2 block size power
   
|-
 
|-
 +
| 0x200
 +
|
 +
| End
 
|}
 
|}
   −
=== Integrity verification header ===
+
== Integrity verification header ==
    
* Offsets for levels 1-3 come from the metadata remap storage
 
* Offsets for levels 1-3 come from the metadata remap storage
Line 339: Line 312:  
| 0x04
 
| 0x04
 
| 4
 
| 4
−
| Version? (Upper 2 bytes must be 0x0002)
+
| Version (0.2.x.x)
 
|-
 
|-
 
| 0x08
 
| 0x08
Line 359: Line 332:  
|}
 
|}
   −
==== Level information ====
+
=== Level information ===
    
* 0x18 bytes long
 
* 0x18 bytes long
Line 388: Line 361:  
|}
 
|}
   −
=== Journal header ===
+
== Journal header ==
    
{| class="wikitable"
 
{| class="wikitable"
Line 402: Line 375:  
| 0x04
 
| 0x04
 
| 4
 
| 4
−
| Version? (Must be 0x10000 or less)
+
| Version (Must be 0.0.x.x or 0.1.0.0)
 
|-
 
|-
 
| 0x08
 
| 0x08
Line 416: Line 389:  
| Block size
 
| Block size
 
|-
 
|-
 +
| 0x20
 +
| 16
 +
| Journal map header
 +
|-
 +
| 0x200
 
|  
 
|  
−
|  
+
| End
−
| The below fields are treated as a separate subheader
+
|-
 +
|}
 +
 
 +
=== Journal map header ===
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Start
 +
! Length
 +
! Description
 
|-
 
|-
−
| 0x20
+
| 0x00
 
| 4
 
| 4
−
| Version? (Must be 0 or 1)
+
| Version (Stored as a normal 32-bit integer. Must be 0 or 1)
 
|-
 
|-
−
| 0x24
+
| 0x04
 
| 4
 
| 4
 
| Main data block count
 
| Main data block count
 
|-
 
|-
−
| 0x28
+
| 0x08
 +
| 4
 +
| Journal block count
 +
|-
 +
| 0x0C
 +
| 4
 +
| Padding
 +
|-
 +
|}
 +
 
 +
== Extra data ==
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Start
 +
! Length
 +
! Description
 +
|-
 +
| 0x00
 +
| 0x40
 +
| [[Filesystem_services#SaveDataCreationInfo|SaveDataCreationInfo]]
 +
|-
 +
| 0x40
 +
| 8
 +
| Save owner ID
 +
|-
 +
| 0x48
 +
| 8
 +
| Timestamp
 +
|-
 +
| 0x50
 +
| 4
 +
| Flags?
 +
|-
 +
| 0x54
 +
| 4
 +
| Unused?
 +
|-
 +
| 0x58
 +
| 8
 +
| Size of usable save data
 +
|-
 +
| 0x60
 +
| 8
 +
| Journal size
 +
|-
 +
| 0x68
 
| 8
 
| 8
−
| Journal block count
+
| Commit ID
 
|-
 
|-
 
| 0x200
 
| 0x200
 
|  
 
|  
 
| End
 
| End
 +
|}
 +
 +
= Remap Storage =
 +
 +
Remap Storage is used to remap segments of data from virtual offsets to physical offsets. This allows extending the save file without having to relocate existing data.
 +
 +
Each Remap Storage has three components: [[#Remap storage header|a header]], a remapping table, and the main data storage.
 +
 +
A remap storage can contain a varying number of segments, each representing a chunk of contiguous virtual storage. A segment can be composed of one or more entries. Each of these entries are mapped from their virtual locations to their physical locations by entries in the remapping table. A physical offset corresponds to that offset in the main data storage.
 +
 +
When a segment is extended a new remapping entry is appended to the physical storage, allowing expansion without relocating the existing entries.
 +
 +
Each virtual offset has two parts, a segment index and an offset. The size of these sections is controlled by the remap header.
 +
 +
Example: 0x3000000000000100<br />
 +
If 4 bits were reserved for the segment index, the offset would be split like this, representing offset 0x100 of segment 3.<br />
 +
Segment index: 0x3 Offset: 0x000000000000100
 +
 +
== Remap storage header ==
 +
 +
{| class="wikitable"
 +
|-
 +
! Start
 +
! Length
 +
! Description
 +
|-
 +
| 0x00
 +
| 4
 +
| Magic ("RMAP")
 +
|-
 +
| 0x04
 +
| 4
 +
| Version (Must be 0.0.x.x or 0.1.x.x)
 +
|-
 +
| 0x08
 +
| 4
 +
| Number of remapping entries
 +
|-
 +
| 0x0C
 +
| 4
 +
| Number of remapping segments
 +
|-
 +
| 0x10
 +
| 4
 +
| Number of bits reserved for the segment index in virtual offsets
 +
|-
 +
| 0x40
 +
|
 +
| End
 +
|}
 +
 +
== Remapping Entry ==
 +
 +
{| class="wikitable"
 +
|-
 +
! Start
 +
! Length
 +
! Description
 +
|-
 +
| 0x00
 +
| 8
 +
| Virtual offset
 +
|-
 +
| 0x08
 +
| 8
 +
| Physical offset
 +
|-
 +
| 0x10
 +
| 8
 +
| Size
 +
|-
 +
| 0x18
 +
| 4
 +
| Alignment
 +
|-
 +
| 0x1c
 +
| 4
 +
| Padding?
 +
|-
 +
|}
 +
 +
= Duplex Storage =
 +
 +
A Duplex Storage contains four separate elements: [[#Duplex header|a header]], a bitmap, and two identically-sized chunks of data.
 +
 +
As hinted by the name, a Duplex Storage contains two main chunks of data. To store X bytes, two chunks of data each with size X are required.
 +
 +
== Bitmap ==
 +
 +
This main data storage is split into blocks of the size indicated in the duplex header. The bitmap contains as many bits as the main data has blocks. If the main data is 0x40000 bytes long with a block size of 0x4000 bytes, the bitmap would contain 0x10 bits.
 +
 +
The bitmap controls which data chunk is active for each block. e.g. If bit 3 of the bitmap is a 0 then block 3 of data chunk 0 is active and block 3 of data chunk 1 is inactive. This means that when data from block 3 is read, the data from chunk 0 will be returned and the data from chunk 1 will be completely ignored.
 +
 +
== Hierarchical Duplex Storage ==
 +
 +
Multiple Duplex Storages can be chained together to gain various benefits. With a Hierarchical Duplex Storage, the bitmap for the main data is stored inside another Duplex Storage.
 +
 +
The bitmap for this second Duplex Storage is stored in a special Duplex Storage. The data of this top level contains a master bitmap that is typically 0x40 bytes long. A bit in the save file header controls which master bitmap is active.
 +
 +
This allows for atomic operations on the Hierarchical Duplex Storage. When writing to the storage, data will be written to the inactive blocks and inactive bitmaps. When the data is committed the bit in the save file header is flipped, changing which master bitmap is active.
 +
 +
== Duplex header ==
 +
 +
* Block sizes are stored as powers of 2
 +
 +
{| class="wikitable"
 +
|-
 +
! Start
 +
! Length
 +
! Description
 +
|-
 +
| 0x00
 +
| 4
 +
| Magic ("DPFS")
 +
|-
 +
| 0x04
 +
| 4
 +
| Version (0.1.x.x)
 +
|-
 +
| 0x08
 +
| 8
 +
| Master bitmap offset
 +
|-
 +
| 0x10
 +
| 8
 +
| Master bitmap size
 +
|-
 +
| 0x18
 +
| 4
 +
| Master bitmap block size power
 +
|-
 +
| 0x1C
 +
| 8
 +
| Level 1 offset
 +
|-
 +
| 0x24
 +
| 8
 +
| Level 1 size
 +
|-
 +
| 0x2C
 +
| 4
 +
| Level 1 block size power
 +
|-
 +
| 0x30
 +
| 8
 +
| Level 2 offset
 +
|-
 +
| 0x38
 +
| 8
 +
| Level 2 size
 +
|-
 +
| 0x40
 +
| 4
 +
| Level 2 block size power
 
|-
 
|-
 
|}
 
|}
   −
=== Save FS header ===
+
= Save FS =
 +
 
 +
== Save FS header ==
    
* Structure is different than 3DS.
 
* Structure is different than 3DS.
Line 454: Line 643:  
| 0x04
 
| 0x04
 
| 4
 
| 4
−
| Version? (Upper 2 bytes must be 0x0006)
+
| Version (0.6.x.x)
 
|-
 
|-
 
| 0x08
 
| 0x08
Line 464: Line 653:  
| Block Size
 
| Block Size
 
|-
 
|-
−
|  
+
| 0x18
−
|  
+
| 0x30
−
| The below fields are treated as a separate subheader
+
| FAT header
 +
|-
 +
|}
 +
 
 +
== File allocation table ==
 +
 
 +
The savedata FS uses an allocation table to keep track of block allocation. This FAT contains doubly-linked lists of the blocks allocated to each file. Each entry in the FAT is 8 bytes in size.
 +
 
 +
FAT entry 0 is reserved for the list of free blocks. Because of this, the FAT entry for block n is found at FAT index n+1. The indexes stored in FAT entries refer the index of the next/previous FAT entry in the chain, not the index of the next/previous block.
 +
 
 +
The FAT header is internally called AllocationTableControlArea. The FAT itself is called AllocationTableMeta. The actual save FS data is called AllocationTableData.
 +
 
 +
=== File allocation table header ===
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Start
 +
! Length
 +
! Description
 
|-
 
|-
−
| 0x18
+
| 0x00
 
| 8
 
| 8
 
| Block size
 
| Block size
 
|-
 
|-
−
| 0x20
+
| 0x08
 
| 8
 
| 8
 
| FAT offset
 
| FAT offset
 
|-
 
|-
−
| 0x28
+
| 0x10
 
| 4
 
| 4
 
| FAT entry count
 
| FAT entry count
 
|-
 
|-
−
| 0x2C
+
| 0x14
 
| 4
 
| 4
 
| Padding
 
| Padding
 
|-
 
|-
−
| 0x30
+
| 0x18
 
| 8
 
| 8
 
| Data offset
 
| Data offset
 
|-
 
|-
−
| 0x38
+
| 0x20
 
| 4
 
| 4
 
| Data block count
 
| Data block count
 
|-
 
|-
−
| 0x3C
+
| 0x24
 
| 4
 
| 4
 
| Padding
 
| Padding
 
|-
 
|-
−
| 0x40
+
| 0x28
−
| 8
+
| 4
 
| Directory table block index
 
| Directory table block index
 
|-
 
|-
−
| 0x48
+
| 0x2C
−
| 8
+
| 4
 
| File table block index
 
| File table block index
 
|-
 
|-
 
|}
 
|}
   −
=== Remap storage header ===
+
=== File allocation table entry ===
    
{| class="wikitable"
 
{| class="wikitable"
Line 514: Line 721:  
! Description
 
! Description
 
|-
 
|-
−
| 0x00
+
| 0
 +
| 4 (High bit)
 +
| Set if entry is the first entry in the list.
 +
|-
 +
| 0
 +
| 4 (Lower 31 bits)
 +
| Previous entry index. First entry in list if 0.
 +
|-
 
| 4
 
| 4
−
| Magic ("RMAP")
+
| 4 (High bit)
 +
| Set if the allocation segment has multiple blocks.
 
|-
 
|-
−
| 0x04
   
| 4
 
| 4
−
| Version? (Must be 0x10000 or less)
+
| 4 (Lower 31 bits)
 +
| Next entry index. Last entry in list if 0.
 +
|-
 +
|}
 +
 
 +
If the allocation segment has multiple blocks, the first entry will be followed by a range descriptor entry. The last entry in the segment will contain a duplicate of this entry.
 +
 
 +
{| class="wikitable"
 
|-
 
|-
−
| 0x08
+
! Start
−
| 4
+
! Length
−
| Number of remapping entries
+
! Description
 +
|-
 +
| 0
 +
| 4 (High bit)
 +
| Always set.
 +
|-
 +
| 0
 +
| 4 (Lower 31 bits)
 +
| First entry in this segment.
 
|-
 
|-
−
| 0x0C
   
| 4
 
| 4
−
| Number of remapping segments
+
| 4 (High bit)
 +
| Never set.
 
|-
 
|-
−
| 0x10
   
| 4
 
| 4
−
| Number of bits reserved for the segment index in virtual offsets
+
| 4 (Lower 31 bits)
 +
| Last entry in this segment.
 
|-
 
|-
−
| 0x40
  −
|
  −
| End
   
|}
 
|}
   −
=== Extra data ===
+
== Save File Table ==
 +
 
 +
The save file table is similar to the RomFS file table, except the save file table uses linked lists instead of dictionaries.
 +
 
 +
The table contains a list of directory entries and a list of file entries. Their respective types are:<br />
 +
'''SaveFsList<SaveFileTableEntry<SaveDirectoryInfo>>'''<br />
 +
'''SaveFsList<SaveFileTableEntry<SaveFileInfo>>'''
 +
 
 +
=== Save File Table Entry ===
 +
 
 +
SaveFileTableEntry<class T>
    
{| class="wikitable"
 
{| class="wikitable"
Line 548: Line 784:  
|-
 
|-
 
| 0x00
 
| 0x00
−
| 0x40
+
| 4
−
| [[Filesystem_services#Save_Struct|Save Struct]]
+
| Next entry index. A value of 0 indicates the end of the list.
 
|-
 
|-
−
| 0x40
+
| 0x04
−
| 8
+
| sizeof(T)
−
| Save owner ID
+
| Value of type T.
 
|-
 
|-
−
| 0x48
+
|}
−
| 8
+
 
−
| Timestamp
+
=== Save File Info ===
 +
 
 +
Holds the information of a single file.
 +
 
 +
{| class="wikitable"
 
|-
 
|-
−
| 0x50
+
! Start
−
| 4
+
! Length
−
| Unknown
+
! Description
 
|-
 
|-
−
| 0x54
+
| 0x00
 
| 4
 
| 4
−
| Unused?
+
| Starting block index.
 
|-
 
|-
−
| 0x58
+
| 0x04
 
| 8
 
| 8
−
| Size of usable save data
+
| File length in bytes.
 
|-
 
|-
−
| 0x60
+
| 0x0C
 
| 8
 
| 8
−
| Journal size
+
| Reserved.
 
|-
 
|-
−
| 0x200
  −
|
  −
| End
   
|}
 
|}
   −
== Files ==
+
=== Save Directory Info ===
   −
=== Directory Table Entry ===
+
Holds the information of a single directory.
−
 
  −
* Index 0 is the start of a linked list that contains all invalid/inactive directories.
  −
* Index 1 is the start of a linked list that contains all valid/active directories.
  −
* Index 2 is the root directory.
      
{| class="wikitable"
 
{| class="wikitable"
Line 596: Line 829:  
| 0x00
 
| 0x00
 
| 4
 
| 4
−
| Parent directory node index
+
| First child directory index. 0 if none.
 
|-
 
|-
 
| 0x04
 
| 0x04
−
| 64
+
| 4
−
| Filename
+
| First child file index. 0 if none.
 
|-
 
|-
−
| 0x44
+
| 0x08
−
| 4
+
| 0xC
−
| Next sibling directory node index
+
| Reserved.
 
|-
 
|-
−
| 0x48
+
|}
−
| 4
+
 
−
| First child directory node index
+
== Save FS List ==
 +
 
 +
SaveFsList<class T>
 +
 
 +
This is a linked list that is used internally by '''Save File Table''' as a key-value store. Integer/string pairs are used as keys. The list is represented as a single array so that it can be easily stored and read from a file. Entry indexes 0 and 1 are reserved.
 +
 
 +
Index 0 is the start of a list containing all free entries. When an item in the list is removed, the entry it was using is added to this list for future reuse.
 +
 
 +
Index 1 is the start of a list containing all currently used entries.
 +
 
 +
The first 8 bytes of the list are used as follows. Indexes 0 and 1 are included in these counts.
 +
 
 +
{| class="wikitable"
 
|-
 
|-
−
| 0x4c
+
! Start
−
| 8
+
! Length
−
| First child file node index
+
! Description
 
|-
 
|-
−
| 0x54
+
| 0x00
−
| 8
+
| 4
−
| Unused?
+
| The size of the list. Freed entries that have not been reused are included in the count.
 
|-
 
|-
−
| 0x5c
+
| 0x04
 
| 4
 
| 4
−
| Next directory node index in the chain of invalid or valid directories. If this is the first block in a list of length 0, this value will contain the total number of directory nodes.
+
| The current capacity of the list based on the number of bytes allocated.
 
|-
 
|-
 
|}
 
|}
   −
=== File Table Entry ===
+
=== Save FS List Key ===
−
 
  −
* Index 0 is the start of a linked list that contains all invalid/inactive files.
  −
* Index 1 is the start of a linked list that contains all valid/active files.
      
{| class="wikitable"
 
{| class="wikitable"
Line 637: Line 879:  
| 0x00
 
| 0x00
 
| 4
 
| 4
−
| Parent directory node index
+
| 32-bit integer.
 
|-
 
|-
 
| 0x04
 
| 0x04
−
| 64
+
| 0x40
−
| Filename
+
| 0x40-byte string.
 
|-
 
|-
−
| 0x44
+
|}
−
| 4
+
 
−
| Next sibling file node index
+
=== Save FS List Entry ===
 +
 
 +
{| class="wikitable"
 
|-
 
|-
−
| 0x48
+
! Start
−
| 4
+
! Length
−
| Index of the block that the file starts at
+
! Description
 
|-
 
|-
−
| 0x4c
+
| 0x00
−
| 8
+
| 0x44
−
| File size in bytes
+
| Key.
 
|-
 
|-
−
| 0x54
+
| 0x44
−
| 8
+
| sizeof(T)
−
| Unused?
+
| Value.
 
|-
 
|-
−
| 0x5c
+
| 0x44 + sizeof(T)
 
| 4
 
| 4
−
| Next file node index in the chain of invalid or valid files. If this is the first block in a list of length 0, this value will contain the total number of file nodes.
+
| Next entry node index. A value of 0 indicates the end of the list.
 
|-
 
|-
 
|}
 
|}
Shchmue
77

edits

Retrieved from "https://switchbrew.org/wiki/Special:MobileDiff/5201...8367"

Navigation menu