Filesystem services: Difference between revisions

← Older edit Newer edit →

@@ Line 964: / Line 964: @@
 | Unknown. There's code for this in spider v9.9, but that code isn't actually used.
 | Yes
-| ?
+| No
 | No
 | Yes
@@ Line 1,002: / Line 1,002: @@
 |-
 | 0x2345678E
-| FSPXI: Program Access (limited subset of merged main title + update/patch title access). For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
+| FSPXI: Program Access (limited subset of merged main title + update/patch title access). For fs:LDR(used by the "loader" FIRM ARM11-process), only <code>exefs:/.code</code>. Not accessible with fs:USER.
 | Yes
 | Yes
@@ Line 1,128: / Line 1,128: @@
 == Binary LowPath ==
 The format of the data that a binary LowPath points to is custom per archive.
-=== SelfNCCH File Path Data Format ===
-{| class="wikitable" border="1"
-|-
-!  Index word
-!  Description
-|-
-| 0
-| Type:
-* 0x0: RomFS
-* 0x1: error 0xD9004676
-* 0x2: ExeFS
-* 0x3: Error 0xE0E046BE.
-* 0x4: FS-module crashes on this
-* 0x5: Update RomFS?
-|-
-| 1-2
-| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
-|}
-Note that ExeFS files only support reading from offset=0 and with size=file_size.
 === SystemSaveData / Extdata / Shared Extdata Archive Path Data Format ===
@@ Line 1,505: / Line 1,484: @@
 ==== FS Limitations ====
+- FSPXI allows all access types.
 - When used through fs:LDR by loader, FS only provides access to <code>exefs:/.code</code>.
@@ Line 1,532: / Line 1,513: @@
 |}
-=SEEDDB=
+=Anti Savegame Restore=
-With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.
+Anti Savegame Restore, internally referred to as ''Save Data Rollback Prevention'', is a feature originally implemented in the FS module with [[4.0.0-7]], which prevents the user from restoring previous versions of a savegame image. This feature is not used (in practice) for gamecard games. When an old version of the save is detected, the application will display an error regarding old savegame version, then delete and recreate the save data (similar to when it is corrupted).
+==Implementation==
+When creating the savedata, the application generates a secure value (a 64 bit unsigned integer), then stores it in either the [[DISA_and_DIFF#DISA_header|DISA save image header]] or the [[Filesystem_services#Anti_Savegame_Restore_Save_Data|Anti Savegame Restore Save Data]]. The application then uses the anti-savegame-restore commands ([[FS:SetSaveDataSecureValue]], [[FS:GetSaveDataSecureValue]], [[FS:SetOtherSaveDataSecureValue]], [[FS:GetOtherSaveDataSecureValue]], [[FS:SetThisSaveDataSecureValue]], [[FS:GetThisSaveDataSecureValue]], [[FS:SetSaveArchiveSecureValue]] and [[FS:GetSaveArchiveSecureValue]]) to verify the value known to the game for comparison with the value returned by FS, and to update the value in the corresponding storage location.
+Each time the application writes to the savegame, the value should be updated by both the application and through FS. Usually, applications update this value by incrementing it. However, generating a new random-number or other methods of updating it can be used as well.
+==Anti Savegame Restore Save Data==
+The save data used for this feature is stored in [[System_SaveData|System Save Data]] ID 0x00010011 and contains only one file, named <code>DB</code>:
+===Main Structure===
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x1000 || Header
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x1 || u8, version (usually 0)
+|-
+| 0x1 || 0x3 || padding
+|-
+| 0x4 || 0x4 || u32, number of secure value entries
+|-
+| 0x8 || 0xFF8 || completely unused, padding
+|}
+|-
+| 0x1000 || 0x1C000 (8 * 14336) || [[Filesystem_services#SecureValueKey|Secure value keys]]
+|-
+| 0x1D000 || 0x1C000 (8 * 14336) || u64s, Secure values
+|}
+===SecureValueKey===
+Depending on which command is used, secure value keys can be interpreted as:
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x8 || u64, Title ID
+|}
+or:
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x4 || u32, [[Filesystem_services#SecureValueSlot|Secure Value Slot]]
+|-
+| 0x4 || 0x4 || u32, Unique ID
+|}
+==Applications using this feature==
+* Animal Crossing: New Leaf
+* Pokemon X & Y
+* Pokemon Omega Ruby & Alpha Sapphire
+* Pokemon Omega Ruby & Alpha Sapphire Demo
+* Pokemon Shuffle
+* Super Smash Bros
+* Pokemon Red,Blue and Yellow (GB(C) VC)
+* Rusty's Real Deal Baseball
+* Megami Meguri
+=SEEDDB and TITLETAG=
+With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with save ID 0x0001000F was added. This save data contains both the NCCH seed database (SEEDDB) and the title tag database (TITLETAG).
+These databases are managed by the commands [[FS:AddSeed]], [[FS:GetSeed]], [[FS:DeleteSeed]], [[FS:GetNumSeeds]] and [[FS:ListSeeds]] for SEEDDB, and [[FS:AddTitleTag]], [[FS:GetTitleTag]], [[FS:DeleteTitleTag]], [[FS:GetNumTitleTags]], and [[FS:ListTitleTags]] for TITLETAG respectively.
+Both the [[Home_Menu|HOME Menu]] and the [[NIM_Services|NIM]] module have access to these commands.
+==SEEDDB==
+Stored in the system savedata archive 0x0001000F as a file named <code>SEEDDB</code>, it contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].
+The file follows a simple key-value format allowing the storage of seed data for up to 2000 unique title IDs.
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x1000 || Header
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x1 || u8, version (usually 0)
+|-
+| 0x1 || 0x3 || padding
+|-
+| 0x4 || 0x4 || u32, number of seed entries
+|-
+| 0x8 || 0xFF8 || completely unused, padding
+|}
+|-
+| 0x1000 || 0x3E80 (8 * 2000) || u64s, Title IDs
+|-
+| 0x4E80 || 0x7D00 (16 * 2000) || Seed data, 16 bytes per seed
+|}
+==TITLETAG Database==
-The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].
+Stored in the system savedata archive 0x0001000F as a file named <code>TITLETAG</code>, it contains information used by the [[Home_Menu|HOME Menu]] to handle cases when a to-be-released title has been purchased already, that is, to properly install the seed required for [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].
+When a to-be-released title is purchased, the [[NIM_Services|NIM]] module installs a [[Filesystem_services#TitleTag|title tag]] with enough information about the title for the [[Home_Menu|HOME Menu]] to be able to initiate a seed import once the title has been released (and thus, the title's NCCH content lock seed). Until the title's seed is released, and while the title tag remains in the database, the HOME Menu will prevent the user from launching the software as it would not run without the seed. Once released, information from the title tag is used to download the seed, and, if successful, the title tag is removed from the database, making the software playable.
+The file follows a simple key-value format allowing the storage of title tag data for up to 2000 unique title IDs.
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x1000 || Header
+{| class="wikitable" border="1"
+|-
+! Offset !! Size !! Description
+|-
+| 0x0 || 0x1 || u8, version (usually 0)
+|-
+| 0x1 || 0x3 || padding
+|-
+| 0x4 || 0x4 || u32, number of entries
+|-
+| 0x8 || 0xFF8 || completely unused, padding
+|}
+|-
+| 0x1000 || 0x3E80 (8 * 2000) || u64s, Title IDs
+|-
+| 0x4E80 || 0x3E800 (0x80 * 2000) || [[Filesystem_services#TitleTag|Title Tag]] data, 0x80 bytes per entry
+|}
 = Common Types =