SD Filesystem

From 3dbrew
Revision as of 02:32, 23 August 2012 by 3dsguy (talk | contribs) (giving a similar format to the Flash Filesystem)
Jump to: navigation, search

The 3DS uses an SD Card for general storage of additional game data, music and photos taken with the 3DS.

(Most 3DS SD card data is stored under "/Nintendo 3DS/<ID0>/<ID1>", where ID0 is the first 0x10-bytes from a SHA256 hash.

(the 3D videos are in .avi format and the video frames use MJPG.)


Additional game data is stored here:

/Nintendo 3DS/<SomeID>/<SomeID>/extdata/00000000

See the extdata page for more extdata info and the extdataIDs list.

All "extra data" under extdata is encrypted. Extdata can't be decrypted with the xorpad fail used for old FLASH saves. All "extra data" files can't be copied to other 3DS SD cards, they are locked to the console.


Introduced with the 2.0.0-2 update, this directory contains two files which are used to manage 3DS titles installed to the SD Card and are part of the DRM for SD Card Titles. They are encrypted.


"title.db" - The "title.db" file (among other things perhaps), archives data about titles installed on the SD Card which includes their Product Code, whether the title uses an electronic manual, Title ID, Title size and Title Version(the title version determines the name of the .cmd file which contains data from the title TMD used for anti-tampering purposes). This file does not store a hash of the .cmd file for each given title, but the title.db expects to find a .cmd with a name specific to the title version, and the nature of the .cmd file makes re-naming/editing or using under a different title ID(by the end user) detectable (finding/creating an additional .cmd file for a specific title i.e. having two different sets of app data from the same version/title ID is not feasible for retail units). This data is taken from the title's TMD and executable NCCH during install, this is also party why the encrypted TMD found in each title directory is redundant, as the important information is moved to the ".db" and ".cmd" files during title installation.

  • Since this file controls what SD Card titles are accessible to the 3DS, it is possible to move between different versions of an SD Card title if you have the title.db and title data for each version of that specific title.
  • This file isn't updated when downloading a title, until installation is complete. So if the download is un-expectedly interrupted/canceled this prevents title rights from being written to the title.db. If the title rights are erroneously written, the eShop would mistake the title for being installed, and not allow the title to be re-downloaded(of course erroneous title rights can be deleted from system settings, but the end user would not be expected know to do this). Also in the case of title updates, this has the added benefit of allowing the user to revert to the version of the title before the update, if the update is canceled before completion.

"import.db" - The function of the file is not well understood. It appears to be related to the download/install of titles, as in the progress of downloading titles this file will have changed but the title.db will not be modified until the title has been properly downloaded. This file doesn't contain any title specific data which the 3DS has been noted to use in relation to titles on the SD Card, even though this file is modified when titles are installed/deleted. Infact, no matter what titles you install, if you use an old copy of the "import.db" with a recent copy of the "title.db", this creates no noticeable issues.

Note: It is quite unlikely that the either the import.db or title.db contain the cached icon and names of installed titles. The amount of data which changes in those two file when a title installed/deleted is not sufficient to contain the size of data required for the icons and names of the application, they are most likely cached in the NAND.


SD Card titles (3DS eShop downloads) are stored in this directory:

/Nintendo 3DS/<SomeID>/<SomeID>/title/

And follow this directory structure:

/<Title ID High>/<Title ID Low>/Content/XXXXXXXX.tmd
/<Title ID High>/<Title ID Low>/Data/00000001.sav
/<Title ID High>/<Title ID Low>/00000000.ctx

For list of eShop titles see the Title list

"XXXXXXXX.tmd" - (file name starts with 00000000.tmd and increases with an increment of "1" for each title version the 3DS is introduced to) This is the Title Metadata associated with the title, it is encrypted with a per-console key. The decrypted TMD is available on Nintendo's CDN server at "". Though CDN version of the title TMD has a certificate chain attached at the end of the TMD, so removing it will give you the 1:1 decrypted TMD. After installation the "00000000.tmd" is redundant, because important title data is extracted and imported into the title.db and ".cmd" files.

"" - (There is no pattern to the file name, however for a given title, ".app" file names are not reused) These files are NCCH files, where the entire file is encrypted with a per-console key(this is on top of the encryption of the NCCH contents). There can be more than one NCCH in this directory, as seen with .CCI files, the game executable (CXI) can be accompanied with additional non-executable NCCH files (CFA) such as the electronic manual and DLP Child containers. Determining the function of the encrypted NCCH, is done by finding the Content Index of the "" file in the title's TMD(see above for retrieving decrypted TMD), interpreting the Content Index is as follows:

Index Content Type
0000 Main Executable (.CXI)
0001 Home Menu Manual (.CFA)
0002 DLP Child Container (.CFA)

Unlike the TMD, a decrypted version of the NCCH files cannot be retrieved from Nintendo's CDN, the NCCH files do exist on Nintendo's CDN but are encrypted. Of course editing/deleting ".app" files will have an effect. Deleting/renaming the manual ".app' will cause the manual not to load when clicked on. And deleting/renaming the executable ".app" will cause the application to not load, and the 3D Banner does not show(The banner is loaded each time from the game's executable NCCH when the home menu loads, it is not cached like the icon and name).

"XXXXXXXX.cmd" - (file name starts with 00000001.cmd and increases with an increment of "1" for each title version the 3DS is introduced to) This file contains data taken from the title's TMD during install. The data includes the title ID, file names and hashes (possibly sizes aswell) of the .app files to prevent tampering. This file appears to be signed(or contains a hash of itself), and keeps a record of its true file name(alternatively it could store the title version, which can be used to determine its true file name). In addition it is also encrypted with a per-console key.

"00000001.sav" - This is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write. Renaming these savegames causes home-menu to hang while launching titles, modifying saves throws the usual checksum/hash corruption like gamecard flash saves.

"00000000.ctx" - This file is used only while a title is being downloaded from the eShop, it is deleted after the download is completed.(Might be moved to NAND after installation is completed?)


"Private" data is stored here:

/Nintendo 3DS/Private/<Title ID Low>/
00020400 - Nintendo 3DS Camera 
00020500 - Nintendo 3DS Sound

"Private" data for 3DS Sound/Camera are cleartext. Under the camera priv dir is phtcache.bin, this seems to list the pictures on SD card? When you want to install and see pictures with 3DS,rename to 8 numbers.mpo and save it on /DCIM . Under the sound priv dir is: voice/XX/*.m4a. Where XX is 01-10, with sound saved as .m4a.