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.

Encryption

These files are encrypted with AES-CTR, the keyslot is initialized by movable.sed. The same keyslot is used for the NAND/SD extdata MAC. The NAND extdata images are stored in cleartext. The WCHAR LowPath "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>/<PathToImage>" text path is hashed with SHA-256, including the WCHAR null-terminator. A separate hash is used for Quota.dat. The base CTR seems to be then generated by XORing the calculated hash: CTRword[i] = Hashword[i] ^ Hashword[4+i].

The base CTR is fixed therefore the CTR never changes after each write. Thus it is possible to obtain some cleartext by XORing one file(like newly created extdata) with a newer file, where the newer file overwrote zeros in the original file with non-zero data.

Format

Extdata uses dual 'partitions' of IVFC hash trees to store data. The order of data in Extdata is as follows:

• AES MAC
• DIFF Header
• Secondary DIFI Partition descriptor
• Primary DIFI Partition descriptor
• Secondary Partition IVFC Hash Tree
• Primary Partition IVFC Hash Tree
• DATA Partition (If applicable)

Only one Partition is active at a given time, this is determined by the DIFF header. Normally the 'data' contained in extdata is stored at level4 of the IVFC hash tree, and hence there are two versions of the 'data' stored in the Extdata image (although only one is 'active'). However if DIFI flags[0] is set, this indicates it is a DATA partition and the 'data' is stored outside the IVFC hash tree, at a relative offset defined by the DIFI partition (in this case there will be only one version of the 'data' stored in the Extdata image).

Chain Of Trust

The chain of trust in extdata is as follows:

• MAC verifies DIFF Header
• DIFF Selects and verifies via Active DIFI partition descriptor
• Active DIFI partition descriptor points to the location of active IVFC tree (and data if applicable), and provides the hash blob to verify Level 1 of the IVFC hash tree
• Each IVFC level verifies the next level, until Level 4(data).

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
0000020d	0000021d	0000022d	Face Raiders, likely contains an ExBanner
0000020b	0000021b	0000022b	Nintendo Zone
?	000002cd	?	Home Menu theme cache
?	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)
?	?	00000a86	Professor Layton and the Miracle Mask
?	?	00000c24	Denpa men
00000c73	00000c73	00000c73	Save Data Transfer Tool
?	?	00000d9a	Donkey Kong Country Returns 3d Trailer
?	?	00000f1e	Professor Layton and the Azran legacy
?	?	00001005	Professor Layton vs Phoenix Wright: Ace Attorney
?	?	00000ea6	Etrian Odyssey IV
?	000014d1	?	Unknown, Home Menu attempts to open this during startup. This normally doesn't exist?

NAND Shared Extdata

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	?
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	?
0xf000000e	This appears to contain a list of title-versions for eShop titles(even titles that aren't installed). This is probably used by Home Menu for the software update notification added with 7.0.0-13.

Shared Extdata 0xf000000b gamecoin.dat

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 / opens this archive during startup, when this is corrupted(or at least on older system-versions) the result is a brick.

Tools

• extdata_tool - Extract/verifies standalone extdata images and title extdata FS.