Titles - Revision history

Ihaveamac: /* Data Structure */ update DLC NCCH separation information

2019-06-25T22:45:27Z

Data Structure: update DLC NCCH separation information

← Older revision		Revision as of 02:45, 26 June 2019
Line 198:		Line 198:
	└── content		└── content
	├── <ContentID>.tmd		├── <ContentID>.tmd
	├── ~~00000000~~		├── <IndexSeparator>
	│ └── <ContentID>.app		│ └── <ContentID>.app
	└── cmd		└── cmd
Line 294:		Line 294:
	DLC titles have a different directory structure to most installed titles. This is because all DLC content for a given title is installed under the same Title ID, but DLC add-ons are usually separate purchases, hence the structure altered so any combination of DLC content can be installed. DLC titles can receive 'updates', this is usually in the form of more DLC content and/or DLC bug fixes. Individual DLC content can only be managed from with-in the application using the DLC.		DLC titles have a different directory structure to most installed titles. This is because all DLC content for a given title is installed under the same Title ID, but DLC add-ons are usually separate purchases, hence the structure altered so any combination of DLC content can be installed. DLC titles can receive 'updates', this is usually in the form of more DLC content and/or DLC bug fixes. Individual DLC content can only be managed from with-in the application using the DLC.

	'''"~~00000000~~"''' - ~~This extra directory only found in DLC titles, contains the~~ DLC [[NCCH]] ~~content~~.		'''"<IndexSeparator>"''' - DLC [[NCCH]] contents are split across different directories, depending on the Content Index. Starting with 00000000, there is a directory for every 256 contents. All the directories are created upon install, which means some may be empty if the contents within its index range are not installed.

Ihaveamac: /* Data Structure */ clarify and fix up offset and size for cmd format table

2019-06-09T01:07:28Z

Data Structure: clarify and fix up offset and size for cmd format table

← Older revision		Revision as of 05:07, 9 June 2019
Line 250:		Line 250:
	\| 0x4		\| 0x4
	\| 0x4		\| 0x4
	\| Number of AES-CMACs and Content IDs in the first list. The method to determine this is explained below.		\| Number of AES-CMACs and Content IDs in the first list (X). The method to determine this is explained below.
	\|-		\|-
	\| 0x8		\| 0x8
	\| 0x4		\| 0x4
	\| Number of Content IDs in the second list		\| Number of Content IDs in the second list (Y)
	\|-		\|-
	\| 0xC		\| 0xC
Line 265:		Line 265:
	\|-		\|-
	\| 0x20		\| 0x20
	\| 0x4 * ~~(No. of entries)~~		\| 0x4 * X
	\| List of installed Content IDs in order of Content Index, with missing contents replaced with 0xFFFFFFFF		\| List of installed Content IDs in order of Content Index, with missing contents replaced with 0xFFFFFFFF
	\|-		\|-
	\| 0x20 + 0x4 * ~~(No. of entries)~~		\| 0x20 + 0x4 * X
	\| 0x4 * ~~(No. of entries)~~		\| 0x4 * Y
	\| List of installed Content IDs in order of ID name		\| List of installed Content IDs in order of ID name
	\|-		\|-
	\| 0x20 + ~~0x8~~ * (~~No. of entries~~)		\| 0x20 + 0x4 * (X + Y)
	\| 0x10 * ~~(No. of entries)~~		\| 0x10 * X
	\| AES-CMACs for each content in the first list, generated using the process below		\| AES-CMACs for each content in the first list, generated using the process below
	\|}		\|}

Ihaveamac: /* Data Structure */ don't repeatedly mention that files are encrypted, if it's only the SD layer encryption

2019-06-07T04:35:31Z

Data Structure: don't repeatedly mention that files are encrypted, if it's only the SD layer encryption

← Older revision		Revision as of 08:35, 7 June 2019
Line 211:		Line 211:
	\|}		\|}

	"'''<ContentID>.tmd'''" - (The Content ID is a u32, initially: '''00000000''' when the title is first installed. Changing by an increment of +'''0x1''' for each title update the 3DS installs) This is the [[Title metadata]] associated with the title~~, it is encrypted with a console-unique [[AES\|keyslot]]~~. The decrypted TMD is available on Nintendo's CDN server at "http://nus.cdn.c.shop.nintendowifi.net/ccs/download/TitleIDhere/tmd.OptionallyTitleVersionHere". 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 "<ContentID>.tmd" is redundant, because important title data is extracted and imported into the [[Title Database\|title.db]] and ".cmd" files, but is however kept as a reference.		"'''<ContentID>.tmd'''" - (The Content ID is a u32, initially: '''00000000''' when the title is first installed. Changing by an increment of +'''0x1''' for each title update the 3DS installs) This is the [[Title metadata]] associated with the title. The decrypted TMD is available on Nintendo's CDN server at "http://nus.cdn.c.shop.nintendowifi.net/ccs/download/TitleIDhere/tmd.OptionallyTitleVersionHere". 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 "<ContentID>.tmd" is redundant, because important title data is extracted and imported into the [[Title Database\|title.db]] and ".cmd" files, but is however kept as a reference.


	"'''<ContentID>.app'''" - (The Content ID is a u32, taken from the title's [[TMD]]) These files are [[NCCH]] files~~, where the entire file is encrypted with a console-unique [[AES\|keyslot]](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 ([[NCCH#CFA\|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 "XXXXXXXX.app" file in the title's TMD(see above for retrieving decrypted TMD), interpreting the Content Index is as follows (does not apply to DLC content):		"'''<ContentID>.app'''" - (The Content ID is a u32, taken from the title's [[TMD]]) These files are [[NCCH]] files. 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 ([[NCCH#CFA\|CFA]]) such as the electronic manual and DLP Child containers. Determining the function of the NCCH, is done by finding the Content Index of the "XXXXXXXX.app" file in the title's TMD(see above for retrieving decrypted TMD), interpreting the Content Index is as follows (does not apply to DLC content):

	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
Line 234:		Line 234:


	"'''<ContentID>.cmd'''" - (The Content ID is a u32, initially: '''00000001''' when the title is first installed. Changing by an increment of +'''0x1''' for each time the 3DS adds/removes '.app' files) This file contains data taken from the title's [[TMD]]. See the below table for the format of the cleartext .cmd file. The [[Title Database\|Title.db]] contains the Content ID for the '.cmd' file, but does not contain a hash of the '.cmd' file~~. In addition it is also encrypted with a console-unique [[AES\|keyslot]]~~. This acts as part of the DRM for installed titles, along with the [[Title Database\|title.db]].		"'''<ContentID>.cmd'''" - (The Content ID is a u32, initially: '''00000001''' when the title is first installed. Changing by an increment of +'''0x1''' for each time the 3DS adds/removes '.app' files) This file contains data taken from the title's [[TMD]]. See the below table for the format of the cleartext .cmd file. The [[Title Database\|Title.db]] contains the Content ID for the '.cmd' file, but does not contain a hash of the '.cmd' file. This acts as part of the DRM for installed titles, along with the [[Title Database\|title.db]].

	The below AES-CMACs(including the last 0x10-bytes of the header) are only used for SD titles, for NAND [[Title_list\|download-play]] titles, and non-system DSiWare titles. For other titles, these MACs are set to all-zero.		The below AES-CMACs(including the last 0x10-bytes of the header) are only used for SD titles, for NAND [[Title_list\|download-play]] titles, and non-system DSiWare titles. For other titles, these MACs are set to all-zero.
Line 284:		Line 284:


	'''"00000001.sav"''' - This is the title's ~~encrypted~~ [[Savegames\|savegame]]. Renaming these savegames causes home-menu to hang while launching titles, modifying these saves results in the same corruption errors as other savegames.		'''"00000001.sav"''' - This is the title's [[Savegames\|savegame]]. Renaming these savegames causes home-menu to hang while launching titles, modifying these saves results in the same corruption errors as other savegames.


	'''"00000000.ctx"''' - This file ~~encrypted with a console-unique [[AES\|keyslot]]~~ is temporarily stored on SD card while a title is being downloaded from the eShop, it is deleted after the download is completed. This contains an AP0000000000000000 cert used to sign the data following the cert, this cert is signed by the [[CTCert]].		'''"00000000.ctx"''' - This file is temporarily stored on SD card while a title is being downloaded from the eShop, it is deleted after the download is completed. This contains an AP0000000000000000 cert used to sign the data following the cert, this cert is signed by the [[CTCert]].
	The unknown signed data is likely an ECDSA public key. There's .ctx files stored under the /title directory for NAND CTR/TWL titles, however those use the [[CTXT]] format which is completely different from this SD .ctx format. These .ctx files for NAND/SD titles only exist for titles where installation was not yet finalized(like when a system update install was not yet finalized).		The unknown signed data is likely an ECDSA public key. There's .ctx files stored under the /title directory for NAND CTR/TWL titles, however those use the [[CTXT]] format which is completely different from this SD .ctx format. These .ctx files for NAND/SD titles only exist for titles where installation was not yet finalized(like when a system update install was not yet finalized).

Ihaveamac: /* Data Structure */ cmacs for twlnand have been figured out

2019-06-07T02:16:32Z

Data Structure: cmacs for twlnand have been figured out

← Older revision		Revision as of 06:16, 7 June 2019
Line 281:		Line 281:
	For SD contents, each AES-CMAC is generated by combining the NCCH header without the signature (0x100-0x1FF), the Content Index and Content ID at the end, both as u32. Then calculate the SHA256 of the data and generate the AES-CMAC using the [[AES Registers#Keyslots\|SD/NAND AES-CMAC key]].		For SD contents, each AES-CMAC is generated by combining the NCCH header without the signature (0x100-0x1FF), the Content Index and Content ID at the end, both as u32. Then calculate the SHA256 of the data and generate the AES-CMAC using the [[AES Registers#Keyslots\|SD/NAND AES-CMAC key]].

	For TWLNAND contents, the process is ~~currently unknown, but it appears to use a different keyslot~~(~~cmd file was identical~~ even ~~after a system format~~).		For TWLNAND contents, the same process is used(even for SRL contents) with the keyslot for NAND dbs.

Ihaveamac: /* Data Structure */ add note about twlnand cmd files

2019-06-07T01:47:33Z

Data Structure: add note about twlnand cmd files

← Older revision		Revision as of 05:47, 7 June 2019
Line 281:		Line 281:
	For SD contents, each AES-CMAC is generated by combining the NCCH header without the signature (0x100-0x1FF), the Content Index and Content ID at the end, both as u32. Then calculate the SHA256 of the data and generate the AES-CMAC using the [[AES Registers#Keyslots\|SD/NAND AES-CMAC key]].		For SD contents, each AES-CMAC is generated by combining the NCCH header without the signature (0x100-0x1FF), the Content Index and Content ID at the end, both as u32. Then calculate the SHA256 of the data and generate the AES-CMAC using the [[AES Registers#Keyslots\|SD/NAND AES-CMAC key]].

	For TWLNAND contents, the process is currently unknown.		For TWLNAND contents, the process is currently unknown, but it appears to use a different keyslot(cmd file was identical even after a system format).

Ihaveamac: /* Data Structure */ add more cmd format details

2019-06-07T00:34:04Z

Data Structure: add more cmd format details

← Older revision		Revision as of 04:34, 7 June 2019
Line 236:		Line 236:
	"'''<ContentID>.cmd'''" - (The Content ID is a u32, initially: '''00000001''' when the title is first installed. Changing by an increment of +'''0x1''' for each time the 3DS adds/removes '.app' files) This file contains data taken from the title's [[TMD]]. See the below table for the format of the cleartext .cmd file. The [[Title Database\|Title.db]] contains the Content ID for the '.cmd' file, but does not contain a hash of the '.cmd' file. In addition it is also encrypted with a console-unique [[AES\|keyslot]]. This acts as part of the DRM for installed titles, along with the [[Title Database\|title.db]].		"'''<ContentID>.cmd'''" - (The Content ID is a u32, initially: '''00000001''' when the title is first installed. Changing by an increment of +'''0x1''' for each time the 3DS adds/removes '.app' files) This file contains data taken from the title's [[TMD]]. See the below table for the format of the cleartext .cmd file. The [[Title Database\|Title.db]] contains the Content ID for the '.cmd' file, but does not contain a hash of the '.cmd' file. In addition it is also encrypted with a console-unique [[AES\|keyslot]]. This acts as part of the DRM for installed titles, along with the [[Title Database\|title.db]].

	The below AES-~~MACs~~(including the last 0x10-bytes of the header) are only used for SD titles, ~~and~~ for NAND [[Title_list\|download-play]] titles. For other titles, these MACs are set to all-zero.		The below AES-CMACs(including the last 0x10-bytes of the header) are only used for SD titles, for NAND [[Title_list\|download-play]] titles, and non-system DSiWare titles. For other titles, these MACs are set to all-zero.

	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
Line 250:		Line 250:
	\| 0x4		\| 0x4
	\| 0x4		\| 0x4
	\| Number of ~~entries? Usually~~ the ~~same as the following u32~~.		\| Number of AES-CMACs and Content IDs in the first list. The method to determine this is explained below.
	\|-		\|-
	\| 0x8		\| 0x8
	\| 0x4		\| 0x4
	\| Number of ~~AESMACs? Usually~~ the ~~same as the preceding u32.~~		\| Number of Content IDs in the second list
	\|-		\|-
	\| 0xC		\| 0xC
Line 262:		Line 262:
	\| 0x10		\| 0x10
	\| 0x10		\| 0x10
	\| ~~AESMAC~~ over ~~contents?~~		\| AES-CMAC over first 0x10
	\|-		\|-
	\| 0x20		\| 0x20
	\| 0x4*(No. of entries)		\| 0x4 * (No. of entries)
	\| List of ~~contentIDs~~ in ~~(usually) descending~~ order		\| List of installed Content IDs in order of Content Index, with missing contents replaced with 0xFFFFFFFF
	\|-		\|-
	\| 0x20 + 0x4*(No. of entries)		\| 0x20 + 0x4 * (No. of entries)
	\| 0x4*(No. of entries)		\| 0x4 * (No. of entries)
	\| List of ~~contentIDs~~ in ~~(usually) ascending~~ order		\| List of installed Content IDs in order of ID name
	\|-		\|-
	\| 0x20+0x8*(No. of entries)		\| 0x20 + 0x8 * (No. of entries)
	\| 0x10*(No. of entries)		\| 0x10 * (No. of entries)
	\| ~~These are AESMACs, one~~ for each content.		\| AES-CMACs for each content in the first list, generated using the process below
	\|}		\|}

	~~Entries format:~~		The number of AES-CMACs depends on the highest Content Index installed. For example, a title with 5 contents, but only 1 and 3 are installed, will still result in 3 AES-CMACs, with the 2nd one being unused.
	~~{\| class="wikitable" border="~~1"
	\|-		For SD contents, each AES-CMAC is generated by combining the NCCH header without the signature (0x100-0x1FF), the Content Index and Content ID at the end, both as u32. Then calculate the SHA256 of the data and generate the AES-CMAC using the [[AES Registers#Keyslots\|SD/NAND AES-CMAC key]].
	~~! Start~~
	~~! Size~~		For TWLNAND contents, the process is currently unknown.
	~~! Description~~
	\|-
	~~\| 0x0~~
	~~\| 0x4~~
	~~\| ContentID~~
	\|-
	~~\| 0x4~~
	~~\| 0x8~~
	~~\| Unknown~~
	\|}

	'''"00000001.sav"''' - This is the title's encrypted [[Savegames\|savegame]]. Renaming these savegames causes home-menu to hang while launching titles, modifying these saves results in the same corruption errors as other savegames.		'''"00000001.sav"''' - This is the title's encrypted [[Savegames\|savegame]]. Renaming these savegames causes home-menu to hang while launching titles, modifying these saves results in the same corruption errors as other savegames.

Hiccup at 10:07, 4 May 2017

2017-05-04T08:07:18Z

← Older revision		Revision as of 12:07, 4 May 2017
Line 211:		Line 211:
	\|}		\|}

	"'''<ContentID>.tmd'''" - (The Content ID is a u32, initially: '''00000000''' when the title is first installed. Changing by an increment of +'''0x1''' for each title update the 3DS installs) This is the [[Title metadata]] associated with the title, it is encrypted with a console-unique [[AES\|keyslot]]. The decrypted TMD is available on Nintendo's CDN server at "http://nus.cdn.c.shop.nintendowifi.net/ccs/download/TitleIDhere/tmd". 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 "<ContentID>.tmd" is redundant, because important title data is extracted and imported into the [[Title Database\|title.db]] and ".cmd" files, but is however kept as a reference.		"'''<ContentID>.tmd'''" - (The Content ID is a u32, initially: '''00000000''' when the title is first installed. Changing by an increment of +'''0x1''' for each title update the 3DS installs) This is the [[Title metadata]] associated with the title, it is encrypted with a console-unique [[AES\|keyslot]]. The decrypted TMD is available on Nintendo's CDN server at "http://nus.cdn.c.shop.nintendowifi.net/ccs/download/TitleIDhere/tmd.OptionallyTitleVersionHere". 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 "<ContentID>.tmd" is redundant, because important title data is extracted and imported into the [[Title Database\|title.db]] and ".cmd" files, but is however kept as a reference.

Yellows8 at 00:16, 24 January 2017

2017-01-23T23:16:53Z

← Older revision		Revision as of 02:16, 24 January 2017
Line 1:		Line 1:
	The Nintendo 3DS utilizes a similar title-based organization as seen in the Wii and DSi platforms. The update server is located [http://nus.cdn.c.shop.nintendowifi.net/ccs/download/ here]~~. When using SSL, the update/shop servers must be accessed via SSLv3~~.		The Nintendo 3DS utilizes a similar title-based organization as seen in the Wii and DSi platforms. The update server is located [http://nus.cdn.c.shop.nintendowifi.net/ccs/download/ here].

	For a list of 3DS titles see the [[Title list]].		For a list of 3DS titles see the [[Title list]].

WulfyStylez: .cmd files

2016-11-02T05:06:41Z

.cmd files

← Older revision		Revision as of 08:06, 2 November 2016
Line 249:		Line 249:
	\|-		\|-
	\| 0x4		\| 0x4
	\| ~~0x1C~~		\| 0x4
	\| ~~For NAND titles'~~ .~~cmd these 2 words are usually value 1,~~ the ~~rest of~~ the ~~header is all~~-~~zero~~. ~~The last~~ 0x10~~-bytes of this header is an AES MAC~~?		\| Number of entries? Usually the same as the following u32.
			\|-
			\| 0x8
			\| 0x4
			\| Number of AESMACs? Usually the same as the preceding u32.
			\|-
			\| 0xC
			\| 0x4
			\| Unknown, usually (always?) 1.
			\|-
			\| 0x10
			\| 0x10
			\| AESMAC over contents?
	\|-		\|-
	\| 0x20		\| 0x20
	\| ~~0x8~~*(No. of entries)		\| 0x4*(No. of entries)
	\| ~~Entries for each content begin here with size 0x8~~.		\| List of contentIDs in (usually) descending order
			\|-
			\| 0x20 + 0x4*(No. of entries)
			\| 0x4*(No. of entries)
			\| List of contentIDs in (usually) ascending order
	\|-		\|-
	\| 0x20+0x8*(No. of entries)		\| 0x20+0x8*(No. of entries)
	\| 0x10*(No. of entries)		\| 0x10*(No. of entries)
	\| These are ~~MACs~~, one for each content.		\| These are AESMACs, one for each content.
	\|}		\|}

Neobrain: /* Installing other-model system-titles */

2016-07-09T08:14:48Z

Installing other-model system-titles

← Older revision		Revision as of 12:14, 9 July 2016
Line 296:		Line 296:

	=Installing other-model system-titles=		=Installing other-model system-titles=
	~~It's unknown what code handles~~ the ~~below behaviour~~(~~NIM, AM, or AMXPXI~~).		When finalizing title-install of already downloaded Old3DS system-titles to a New3DS NAND image with New3DS NATIVE_FIRM, the end result is that the New3DS version (TID-low bitmask 0x20000000) of those titles gets deleted.

	~~When finalizing title-install of already downloaded Old3DS system-titles to a New3DS nandimage with New3DS NATIVE_FIRM, the end result~~ is ~~that the New3DS version~~(~~TID-low bitmask 0x20000000~~) ~~of those titles gets deleted~~.		It's unknown where this behaviour is implemented (might be NIM, AM, or AMXPXI).