Extdata
This page describes the format and encryption of extdata, "extra data" stored on SD card and NAND. At:
- nand/data/<ID>/extdata/<ExtdataID-High>
- sdmc/Nintendo 3DS/<ID0>/<ID1>/extdata/<ExtdataID-High>
(ExtdataID-High is always 00000000 for SD, and always 00048000 for NAND) Some titles can have Quota.dat stored in these directories. The directory-name for these directories is the ExtdataID-Low. Then there's a sub-directory 00000000, which contains the actual extdata. Size and number of files in this dir varies per title. NAND stores the shared extdata and is structured exactly the same way, see Flash Filesystem.
Extdata image 00000001 contains a VSXE partition for the FST, the actual file data is stored in the subsequent extdata images.
Regular apps can only mount SD extdata using the same extdataID which is stored in the CXI exheader. Therefore, regular apps which have the exheader extdataID set to zero can't use extdata. This restriction doesn't apply for shared extdata with extdataID high bitmask 0x48000 stored on NAND. System apps with a certain access right can mount arbitrary extdata. All NAND extdata is shared extdata, while all SD extdata is normal extdata. Thus, normal extdata doesn't exist on NAND, and shared extdata doesn't exist on SD. The extdataID high excluding that bitmask is always zero for shared extdata.
Format
All extdata is stored in DIFF container files (follow this link for the container format description). The format description below is for the inner content of the containers.
Filesystem
Title extdata contains a series of extdata images which comprise an independent file system. The first image (00000001) contains the VSXE (FST) partition, and subsequent images each containing a single file. Other extdata images, such as Quota.dat and database extdata, exist independent of a FS.
VSXE
Start | Length | Description |
---|---|---|
0x0 | 4 | Database Magic ("VSXE") |
0x4 | 4 | Magic Number (0x30000) |
0x8 | 8 | Data Table Offset |
0x10 | 8 | File Size, divided by the value at 0x18 |
0x18 | 8 | Usually 0x1000 |
0x20 | 8 | Unknown |
0x28 | 4 | 'Action' made on most recently mounted Extdata image |
0x2C | 4 | Unknown |
0x30 | 4 | ID of most recently mounted Extdata image |
0x34 | 4 | Unknown |
0x38 | 0x100 | Mount path, from most recently mounted Extdata image |
Data Table:
Start | Length | Description |
---|---|---|
0x0 | 0x38 | Unknown |
0x38 | 8 | Folder Table Offset |
Folder Table
Header:
Start | Length | Description |
---|---|---|
0x0 | 0x4 | Equivalent to the Used Folder Entries + 1 |
0x4 | 4 | Equivalent to the Maximum Folder Entries + 1 |
0x8 | 0x20 | Unused |
Folder Entry:
Start | Length | Description |
---|---|---|
0x0 | 0x4 | Parent Folder Index |
0x4 | 0x10 | Folder Name (ASCII) |
0x14 | 0x4 | Previous Folder's Index |
0x18 | 0x4 | Last Folder Index Entry |
0x1C | 0x4 | Last File Index Entry |
0x20 | 0x4 | Unknown |
0x2C | 0x4 | Unknown |
- The folder id/index for the current entry is related to it's position in the Folder table. The folder table is accessed like an array of 0x28 byte chunks, with the header consuming index = 0, root directory at index = 1, and the subsequent folder entries following.
File Table
The location of the File table is calculated by aligning the end offset of the folder table to 0x1000 bytes.
Header:
Start | Length | Description |
---|---|---|
0x0 | 0x4 | Equivalent to the Used File Entries + 1 |
0x4 | 4 | Equivalent to the Maximum File Entries + 1 |
0x8 | 0x28 | Unused |
Folder Entry:
Start | Length | Description |
---|---|---|
0x0 | 0x4 | Parent Folder Index |
0x4 | 0x10 | File Name (ASCII) |
0x14 | 0x4 | Previous File's Index |
0x18 | 0x4 | Unknown |
0x1C | 0x4 | Unknown |
0x20 | 0x8 | Unique Extdata ID |
0x28 | 0x4 | Unknown |
0x2C | 0x4 | Unknown |
- The file id/index for the current entry is related to it's position in the File Table, much like the folder entries in the Folder Table. The file table is accessed like an array of 0x30 byte chunks, with the header consuming index = 0, and the subsequent file entries following. The relationship between the index value of the file entry, and the actual file name of the extdata image that contains it it = index+1. For instance icon (the only file in every extdata), comes right after the header, with an index value of '1', and the icon is stored in extdata image '00000002'.
- The Unique Extdata ID, is the same value found in the DIFF header of the referenced extdata image for that file. The value changes most times the file in question is modified. When mounting an extdata image in the VSXE filesystem, if the file's extdata image doesn't have the expected Unique Extdata ID, it won't be mounted.
VSXE Filesystem structure
When extdata is created, these are *always* created regardless of whether the title actually uses them.
- /icon This file contains the extdata icon displayed in data management. This icon can only be written to by titles when creating extdata, titles would have to recreate extdata to change the icon. This file can't be read directly, instead it is read via FS:ReadExtSaveDataIcon.
- /user/ Contains the title's actual extdata files.
- /boss/ Can contain SpotPass content. SpotPass content can only be downloaded to this /boss directory.
User extdata and SpotPass extdata use separate mount points at /user and /boss. Therefore one mount can't access the other directory, and also can't access /icon.(The title's SpotPass extdata can be mounted by the title itself, if it uses SpotPass)
Other optional but notable directories include:
- /user/ExBanner This directory can optionally store extended banners. When this is available, this banner is displayed instead of the CXI ExeFS banner. COMMON.bin stores the common exbanner, while <regionlang_code>.bin stores an optional separate region/language specific banner.(regionlang_code can be "JPN_JP", "USA_EN", etc)
Extdata without an independent FS
Quota.dat
- This is contained in the Quota.dat extdata image.
Start | Length | Description |
---|---|---|
0x0 | 4 | Magic ("QUOT") |
0x4 | 4 | Magic Number (0x30000) |
0x8 | 8 | Unknown |
0x10 | 0x38 | Unknown |
It's unknown what this is used for.
Database Extdata
See here.
SD Extdata
Usually the ExtdataID low is in the format '00<Unique ID>'
JPN ExtdataID | USA ExtdataID | EUR ExtdataID | Description | Extdata images |
---|---|---|---|---|
00000082 | 0000008f | 00000098 | Home Menu extdata, this contains home-menu savedata and cached icons for applications. | |
00000200 | 00000210 | 00000220 | System Settings extdata added with 2.0.0-2. | |
00000207 | 00000217 | 00000227 | Mii Maker, contains an ExBanner | cleartext |
00000208 | 00000218 | 00000228 | Streetpass Mii Plaza | 11 mb big! |
00000209 | 00000219 | 00000229 | eShop, contains store music in AAC format. | |
0000020b | 0000021b | 0000022b | Nintendo Zone | |
0000020d | 0000021d | 0000022d | Face Raiders, likely contains an ExBanner | |
000002cc | 000002cd | 000002ce | Home Menu theme | |
? | 000004aa | 000004ab | Nintendo Video Extra Data
This is where the video files are stored, and includes the thumbnail, the description, and possibly some checksum info in each video file stored in the extdata images. There are always 9 files within the subdirectory "00000000" of this folder, even without any videos downloaded. The files are "00000001" - "00000009", and "00000003" - "00000008" have the same filesize of 50.7 MB. It is possible to restore the older videos by overwriting all the files within this directory. Provided of course you have made a backup of the files before hand, by copying all the files within this directory to your computer. As far I'm aware its not possible to mix and match the files in order to get certain videos in one grouping, ie. having all 3 Zelda orchestral recordings in one group of 4 Nintendo videos. |
|
00000306 | 00000308 | 00000307 | Mario Kart 7 | |
0000030b | 0000030d | 0000030c | Nintendogs + Cats | |
00000326 | 00000326 | 00000326 | Pokédex 3D | |
00000305 | 0000032d | 0000033c | Super Street Fighter IV 3D | |
00000328 | 00000358 | 0000033b | Ridge Racer 3D | |
? | 0000034d | 00000402 | Samurai Warriors Chronicles | |
? | 0000034f | 0000038a | Dead or Alive Dimensions | |
00000481 | N/A | N/A | Monster Hunter Tri G (Download-Quests) | |
? | 00000517 | 00000518 | Swapnote | |
0000055d | 0000055d | 0000055d | Pokémon X Pokémon Y |
|
? | 00000725 | 00000724 | Ambassador Certificate | |
? | ? | 000007af | New Super Mario Bros. 2 | |
? | 00000863 | 00000864 | Animal Crossing: New Leaf | |
? | 00000a85 | 00000a86 | Professor Layton and the Miracle Mask Professor Layton and the Azran Legacy German Version ExtdataID is 00000a87 |
|
? | ? | 00000b4f | Fullblox / Crashmo | |
? | ? | 00000ba9 | Pokémon Mystery Dungeon: Gates to Infinity | |
? | ? | 00000c24 | Denpa men | |
00000c73 | 00000c73 | 00000c73 | Save Data Transfer Tool | |
? | ? | 00000d9a | Donkey Kong Country™ Returns 3D: Trailer |
|
? | ? | 00000ea6 | Etrian Odyssey IV | |
? | 00000edf | 00000ee0 | Super Smash Bros. for Nintendo 3DS | |
? | 00000f14 | 00000f1e | Phoenix Wright: Ace Attorney - Dual Destinies | |
? | 00001007 | 00001005 | Professor Layton vs Phoenix Wright: Ace Attorney | |
? | ? | 00001062 | Nintendo Pocket Football Club | |
? | ? | 0000111c | Yoshi's New Island | |
? | ? | 00001131 | Fantasy Life | |
000011c5 | 000011c5 | 000011c5 | Pokémon Omega Ruby Pokémon Alpha Sapphire |
|
? | ? | 000012ca | Mario vs. Donkey Kong: Tipping Stars | |
? | ? | 00001499 | Korg DSN-12 | |
? | ? | 000014f2 | Animal Crossing: Happy Home Designer | |
000014d1 | 000014d1 | 000014d1 | Home Menu badge | |
? | ? | 00001632 | Fullblox / Stretchmo | |
? | ? | 00001646 | Pokémon Rumble World | |
00001648 | 00001648 | 00001648 | Pokémon Sun Pokémon Moon |
|
0000165c | 0000165c | 0000165c | Home Menu saved theme layouts | |
? | ? | 00001678 | Yo-kai Watch | |
? | ? | 000018fa | Phoenix Wright: Ace Attorney - Spirit of Justice | |
? | ? | 0000198f | Animal Crossing: New Leaf - Welcome amiibo | |
? | ? | 00001a05 | Super Mario Maker | |
? | ? | 00001a2e | Swapdoodle |
ExtdataID | Description |
---|---|
0xe0000000 | Home Menu attempts to open this archive during boot, if FS:OpenArchive doesn't return an error Home Menu seems to then launch the System Transfer application. Home Menu doesn't actually use this archive at all except for checking whether it exists. |
0xf0000001 | NAND JPEG/MPO files and phtcache.bin from the camera application are stored here. This also contains UploadData.dat. |
0xf0000002 | NAND M4A files from the sound application are stored here |
0xf0000009 | Used for SpotPass content storage for notifications. |
0xf000000b | Contains idb.dat, idbt.dat, gamecoin.dat, ubll.lst, CFL_DB.dat, and CFL_OldDB.dat. These files contain cleartext Miis and some data relating (including cached ICN data) to Play/Usage Records. |
0xf000000c | Contains bashotorya.dat and bashotorya2.dat. |
0xf000000d | Home Menu SpotPass content data storage. |
0xf000000e | Contains versionlist.dat, used by Home Menu for the software update notification added with 7.0.0-13. |
Offset | Size | Description |
---|---|---|
0x0 | 0x4 | Magic number: 0x4F00 |
0x4 | 0x2 | Total Play Coins |
0x6 | 0x2 | Total Play Coins obtained on the date stored below. When the below date does not match the current date, this field is reset to zero, then the date(and other fields) are updated. Once this value is >=10, no more Play Coins can be obtained until the current date changes. |
0x8 | 0x4 | Total step count at the time a new Play Coin was obtained. |
0xC | 0x4 | Step count for the day the last Play Coin was obtained, for that day's step count(same as the step count displayed by home-menu when this file was updated). |
0x10 | 0x2 | Year |
0x12 | 0x1 | Month |
0x13 | 0x1 | Day |
The above date stores the last time new Play Coin(s) were obtained. The contents of this file is updated by home-menu. PTM:GetTotalStepCount is not checked constantly, after home-menu boot this is only checked when waking from sleep-mode. Each time home-menu updates the contents of this file, home-menu will set the Play Coin total to 300 if it's higher than the 300 Play Coin limit.
Home Menu loads this file / opens this archive during startup. When accessing this file fails, like when the file/archive is corrupted(or at least on older system-versions), the result is a brick due to Home Menu using svcBreak. Yellows8 bricked a 3DS this way due to corruption via invalid FSFile:Write flush flags. When opening this extdata archive(0xf000000b) fails, Home Menu executes svcBreak.
List of blocked users.
Empty space is filled with 0xC-long sequences of 00 00 ... 07
Tools
- extdata_tool - Extract/verifies standalone extdata images and title extdata FS.