NCCH - Revision history

TimmSkiller: Small refactor, add form type and content type, fix ncchflags[5]

2025-05-29T18:49:13Z

Small refactor, add form type and content type, fix ncchflags[5]

@@ Line 235: / Line 235: @@
 === NCCH Flags ===
 {| class="wikitable" border="1"
 |-
@@ Line 247: / Line 280: @@
 |-
 |  5
-|  Content Type Bit-masks: Data = 0x1, Executable = 0x2, SystemUpdate = 0x4, Manual = 0x8, Child = (0x4<nowiki>|</nowiki>0x8), Trial = 0x10. When 'Data' is set, but not 'Executable', NCCH is a CFA. Otherwise when 'Executable' is set, NCCH is a CXI.
+|  bits 0-1: [[NCCH#Form_Type|Content Form Type]]
 |-
 |  6
@@ Line 257: / Line 291: @@
 CXIs NCCH header signature is verified using the RSA modulus stored in the exheader, while CFAs NCCH header is verified with a fixed RSA modulus. The public exponent is 65537 for both.
-==== NCCH header example for Lego Starwars III ====
+== Examples ==
   Signature:              720FF8F83F2A1E998322A026D1434165
                           ED19642ABC1CB2722135AA202BEAD60A
@@ Line 300: / Line 336: @@
   Note: Offsets and sizes in media units have been converted to byte sizes.
-==== Plain region example for Lego Starwars III ====
+=== Plain region example for Lego Starwars III ===
 a00: 5b 53 44 4b 2b 4e 49 4e 54 45 4e 44 4f 3a 43 54  [SDK+NINTENDO:CT    [SDK+NINTENDO:CTR_SDK-0_14_23_200_none]
 a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30  R_SDK-0_14_23_20
@@ Line 317: / Line 353: @@
 ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-==== Example dependency list from the extended header ====
+=== Example dependency list from the extended header ===
 41 50 54 3A 55 00 00 00 24 68 69 6F 46 49 4F 00 APT:U...$hioFIO.
 24 68 6F 73 74 69 6F 30 24 68 6F 73 74 69 6F 31 $hostio0$hostio1

Kynex7510 at 23:22, 9 May 2025

2025-05-09T21:22:55Z

← Older revision		Revision as of 01:22, 10 May 2025
Line 255:		Line 255:
	\| Bit-masks: FixedCryptoKey = 0x1, NoMountRomFs = 0x2, NoCrypto = 0x4, using a new keyY generator = 0x20(starting with FIRM [[9.6.0-24\|9.6.0-X]]).		\| Bit-masks: FixedCryptoKey = 0x1, NoMountRomFs = 0x2, NoCrypto = 0x4, using a new keyY generator = 0x20(starting with FIRM [[9.6.0-24\|9.6.0-X]]).
	\|}		\|}
	CXIs NCCH header signature is verified using the RSA ~~public key~~ stored in the ~~accessdesc~~,~~(which follows the exheader)~~ while CFAs NCCH header is verified with a fixed RSA public ~~key~~.		CXIs NCCH header signature is verified using the RSA modulus stored in the exheader, while CFAs NCCH header is verified with a fixed RSA modulus. The public exponent is 65537 for both.

	==== NCCH header example for Lego Starwars III ====		==== NCCH header example for Lego Starwars III ====

Wwylele: /* Encryption */ Just document the encryption stuff here instead of external link

2019-05-01T16:01:07Z

Encryption: Just document the encryption stuff here instead of external link

← Older revision		Revision as of 20:01, 1 May 2019
Line 32:		Line 32:

	=== Encryption ===		=== Encryption ===
	The extended header, the [[ExeFS]], and the [[RomFS]] are encrypted using [https://github.com/3dshax/ctr/blob/master/ctrtool/ncch.c 128-bit AES CTR] unless the NoCrypto flag is set in ncchflag[7]. There are different sets of encryption parameters in use, as over the time new system updates introduced more sophisticated means of encryption. Generally, the decryption key is generated using the [[AES\|AES Engine]] key generator by selecting a particular key slot (see below), the keyX of which is usually set by the bootrom and keyY of which was originally set to the first 0x10 bytes of the NCCH signature.		The [[NCCH/Extended Header\|extended header]], the [[ExeFS]], and the [[RomFS]] are encrypted using [https://github.com/3dshax/ctr/blob/master/ctrtool/ncch.c 128-bit AES CTR] unless the NoCrypto flag is set in ncchflag[7]. There are different sets of encryption parameters in use, as over the time new system updates introduced more sophisticated means of encryption.

	~~'''NOTE: For a full understanding~~ of ~~the steps involved in decryption, consult the [https://github.com/Relys/Project_CTR ctrtool] and [https~~:~~//github.com/archshift/Decrypt9 Decrypt9] source code instead.'''.~~		All encrypted regions are grouped into two categories, each of which uses one kind of encryption scheme:

	~~Starting with [[9.6.0-24\|9.6.0-X]] Process9, there is a different method of generating the NCCH keyY which is enabled by setting the bitmask 0x20 in ncchflag[7]:~~ The ~~keyY will be set to a SHA256 hash generated with the 0x20 bytes of data constituted by the old-method-keyY and a unique content lock seed (each of which are 0x10 bytes wide)~~, ~~where seeds for downloaded titles that use~~ the ~~new crypto are stored in~~ [[~~Filesystem_services#SEEDDB~~\|~~SEEDDB~~]] ~~(nand:/data/<console-unique>/sysdata/0001000f/00000000). The decryption is transparent to ARM11 userland: When FSUSER OpenFile is used with a NCCH archive which uses this crypto~~, the ~~FS-module will add the seed-data from SEEDDB to the end of the file lowpath used for~~ [[~~FSPXI:OpenFile~~]], ~~using which Process9 then gets the hash for calculating~~ the ~~NCCH keyY. It has been observed that this new keyY generation is only used for [[RomFS]] and for [[ExeFS]] sections other than~~ "icon" and "banner" (the ~~same sections which would be used for~~ the ~~additional NCCH keyslots~~, ~~however this keyY generation can be used without any additional NCCH keyslot). Not applying~~ the ~~encryption to "icon" and "banner" was presumably done to support~~ pre-~~loading of games from the eShop (i.e. being able to download and install titles without being able to start them until official release)~~.		* The "menu info" group, including the [[NCCH/Extended Header\|extended header]], the [[ExeFS]] header, and the files "icon" and "banner" in [[ExeFS]], which are needed to display the game on the menu regardless whether system version supports the game, or whether the pre-downloaded eshop game is officially released.

	~~If a certain NCCH flag is set~~, ~~a fixed AES key is used~~. ~~There are two fixed keys~~, ~~one~~ for ~~titles~~ which ~~have~~ the system ~~category bit set~~ (~~SystemFixedKey),~~ and ~~one~~ for ~~the rest ("zeros" key~~)~~. These are debug keys, as they aren't nomally supported on retail systems~~.		* The "content" group, including the rest files (".code" and ".firm") in [[ExeFS]], and the entire [[RomFS]], which is needed for actually running the game, and which can be only decrypted on the supported system (and when the seed is officially released for eshop games).

	~~As of [[7.0.0-13\|7.0.0-X]] the system supports a new encryption method for secure-crypto (when ncchflag[3] != 0). Where a second~~ key is generated using the ~~same keyY but with another~~ [[AES\|~~keyslot~~]]. The ~~second key is used to crypt the [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "banner" (i.e. ".code"~~ and "~~.firm~~"~~). While everything else is crypted with~~ the ~~original~~ key~~. Note~~ the ~~CTR used is~~ the ~~same for both keys. This makes titles "recognizable" but not "launchable" on systems which don't support this method or~~ the ~~keyslot used~~.		The decryption key is generated using the [[AES\|AES Engine]]. The keyX and keyY for each group are set as follows:

			* The "menu info" group uses the primary key, always generated by keyX in the slot 0x2C (set by bootrom) and keyY from the first 0x10 bytes of the NCCH signature.

	~~See below for~~ the secondary ~~keyslots used in NCCH crypto(as mentioned above)~~. ~~As of [[9.6.0-24\|9.6.0-X]], Old3DS Process9 will only use secondary-keyslot 0x25 when~~ ncchflag[3] ~~is non-zero~~.		* The "content" group uses the secondary key. The slot selection for keyX depends on ncchflag[3], as listed in the table below.
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-
Line 50:		Line 52:
	! [[AES#Keyslot\|AES Keyslots]]		! [[AES#Keyslot\|AES Keyslots]]
	! Notes		! Notes
			\|-
			\| 0x00
			\| The initial version
			\| style="background: #ccffbb" \| Yes
			\| 0x2C
			\| This keyslot is initialized by bootrom. This is the same key as the primary key.
	\|-		\|-
	\| 0x01		\| 0x01
Line 69:		Line 77:
	\| [[9.6.0-24\|9.6.0-X]]'s [[FIRM#New_3DS_FIRM\|arm9loader]] changed the contents of keyslots 0x19-0x1F; 9.6.0-X was the first time they were officially used, so this is not a breaking change (there is no content that would use the old versions of those keys).		\| [[9.6.0-24\|9.6.0-X]]'s [[FIRM#New_3DS_FIRM\|arm9loader]] changed the contents of keyslots 0x19-0x1F; 9.6.0-X was the first time they were officially used, so this is not a breaking change (there is no content that would use the old versions of those keys).
	\|}		\|}

			Besides all rules above, if ncchflag[7] bitmask 0x1 is set, and a fixed AES key instead is used for both groups. There are two fixed keys, one for titles which have the system category bit set (SystemFixedKey), and one for the rest ("zeros" key). These are debug keys, as they aren't nomally supported on retail systems.

			The initial CTR for decryption each region is generated from the partition ID, as described below:

			* if the version field (NCCH header + 0x112) is 0 or 2, the 16-byte CTR is [partition_id[7], partition_id[6], ..., partition_id[0], M, 0, ..., 0], where
			** The 8-byte partition ID starts from the beginning in the reverse order. If the partition ID is viewed as a little-endian u64, and the CTR is viewed as big-endian u128, then this is to put the partition ID to the most significant bits of the CTR
			** CTR[8] is set to a magic number M. For [[NCCH/Extended Header\|extended header]], M = 1. For [[ExeFS]], M = 2. For [[RomFS]], M = 3.
			** The rest 7 bytes (the least significant bits of big-endian CTR) are set to zero

			* if the version field is 1, the 16-byte CTR is [partition_id[0], partition_id[1], ...,partition_id[7], 0, 0, 0, 0, T[0], T[1], T[2], T[3]], where
			** The 8-byte partition ID starts from the beginning in the same order.
			** Then four zeros follow.
			** Then a number T in big-endian follows. This number is the offset of each encrypted region to the NCCH beginning. So for [[NCCH/Extended Header\|extended header]], T = 0x200. For [[ExeFS]]/[[RomFS]]. T = 0x200 * ExeFS/RomFS offset in media units

			Note that due to the key generation schemes described above, ExeFS can contain regions using different keys. Regardless of this, both regions shared the same initial CTR at the beginning of ExeFS. If one region doesn't start at the beginning of ExeFS, its actual CTR at its own beginning = ExeFS CTR + (region offset / AESBlockSize=16)

	=== Format ===		=== Format ===

Qyriad: Clarify what NCCH stands for

2018-02-21T21:55:56Z

Clarify what NCCH stands for

← Older revision		Revision as of 00:55, 22 February 2018
Line 1:		Line 1:
	[[Category:File formats]]		[[Category:File formats]]
	The following text tries to document the structure of the NCCH container format. This format is used to store the content of any installed [[Titles\|title]].		The following text tries to document the structure of the NCCH (Nintendo Content Container Header) container format. This format is used to store the content of any installed [[Titles\|title]].

	== Overview ==		== Overview ==

Lynn: /* Container File Format */ colors

2016-12-11T23:09:14Z

Container File Format: colors

← Older revision		Revision as of 02:09, 12 December 2016
Line 53:		Line 53:
	\| 0x01		\| 0x01
	\| [[7.0.0-13\|7.0.0-X]]		\| [[7.0.0-13\|7.0.0-X]]
	\| style="background: ~~green~~" \| Yes		\| style="background: #ccffbb" \| Yes
	\| 0x25		\| 0x25
	\| This keyslot is [[Savegames\|initialized]] by the 6.0 gamecard savegame keyY init function during boot, using a different portion of the [[Savegames\|final]] hash (this keyslot is separate from the one used for the 6.0 save crypto).		\| This keyslot is [[Savegames\|initialized]] by the 6.0 gamecard savegame keyY init function during boot, using a different portion of the [[Savegames\|final]] hash (this keyslot is separate from the one used for the 6.0 save crypto).
Line 59:		Line 59:
	\| 0x0A		\| 0x0A
	\| [[9.3.0-21\|9.3.0-X]]		\| [[9.3.0-21\|9.3.0-X]]
	\| style="background: ~~red~~" \| No		\| style="background: #ffccbb" \| No
	\| 0x18		\| 0x18
	\| This keyslot is initialized by [[FIRM#New_3DS_FIRM\|arm9loader]] on New3DS starting with [[8.1.0-0_New3DS]], but only [[9.3.0-21\|9.3.0-X]] and later know how to use it with ncchflag[3].		\| This keyslot is initialized by [[FIRM#New_3DS_FIRM\|arm9loader]] on New3DS starting with [[8.1.0-0_New3DS]], but only [[9.3.0-21\|9.3.0-X]] and later know how to use it with ncchflag[3].
Line 65:		Line 65:
	\| 0x0B		\| 0x0B
	\| [[9.6.0-24\|9.6.0-X]]		\| [[9.6.0-24\|9.6.0-X]]
	\| style="background: ~~red~~" \| No		\| style="background: #ffccbb" \| No
	\| 0x1B		\| 0x1B
	\| [[9.6.0-24\|9.6.0-X]]'s [[FIRM#New_3DS_FIRM\|arm9loader]] changed the contents of keyslots 0x19-0x1F; 9.6.0-X was the first time they were officially used, so this is not a breaking change (there is no content that would use the old versions of those keys).		\| [[9.6.0-24\|9.6.0-X]]'s [[FIRM#New_3DS_FIRM\|arm9loader]] changed the contents of keyslots 0x19-0x1F; 9.6.0-X was the first time they were officially used, so this is not a breaking change (there is no content that would use the old versions of those keys).

Yellows8: /* Encryption */ ...

2016-07-09T22:48:31Z

Encryption: ...

← Older revision		Revision as of 02:48, 10 July 2016
Line 42:		Line 42:
	As of [[7.0.0-13\|7.0.0-X]] the system supports a new encryption method for secure-crypto (when ncchflag[3] != 0). Where a second key is generated using the same keyY but with another [[AES\|keyslot]]. The second key is used to crypt the [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "banner" (i.e. ".code" and ".firm"). While everything else is crypted with the original key. Note the CTR used is the same for both keys. This makes titles "recognizable" but not "launchable" on systems which don't support this method or the keyslot used.		As of [[7.0.0-13\|7.0.0-X]] the system supports a new encryption method for secure-crypto (when ncchflag[3] != 0). Where a second key is generated using the same keyY but with another [[AES\|keyslot]]. The second key is used to crypt the [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "banner" (i.e. ".code" and ".firm"). While everything else is crypted with the original key. Note the CTR used is the same for both keys. This makes titles "recognizable" but not "launchable" on systems which don't support this method or the keyslot used.

	See below for the keyslots used in NCCH crypto. As of [[9.6.0-24\|9.6.0-X]], Old3DS Process9 will only use keyslot 0x25 when ncchflag[3] is non-zero.		See below for the secondary keyslots used in NCCH crypto(as mentioned above). As of [[9.6.0-24\|9.6.0-X]], Old3DS Process9 will only use secondary-keyslot 0x25 when ncchflag[3] is non-zero.
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-
Line 50:		Line 50:
	! [[AES#Keyslot\|AES Keyslots]]		! [[AES#Keyslot\|AES Keyslots]]
	! Notes		! Notes
	\|-
	~~\| Any~~
	~~\| Any~~
	~~\| style="background: green" \| Yes~~
	~~\| 0x2C~~
	~~\| Original keyslot (always used unless NoCrypto flag is set in ncchflag[7])~~
	\|-		\|-
	\| 0x01		\| 0x01

Neobrain: /* Container File Format */

2016-07-09T22:16:56Z

Container File Format

← Older revision		Revision as of 02:16, 10 July 2016
Line 32:		Line 32:

	=== Encryption ===		=== Encryption ===
	The extended header, the [[ExeFS]], and the [[RomFS]] are encrypted using [https://github.com/3dshax/ctr/blob/master/ctrtool/ncch.c 128-bit AES CTR] unless the NoCrypto ~~mask~~ is set in ncchflag[7]. There are different sets of encryption parameters in use, as over the time new system updates introduced more sophisticated means of encryption. Generally, the decryption key is generated using the [[AES\|AES Engine]] key generator by selecting a particular key slot (see below), the keyX of which is usually set by the bootrom and keyY of which was originally set to the first 0x10 bytes of the NCCH signature.		The extended header, the [[ExeFS]], and the [[RomFS]] are encrypted using [https://github.com/3dshax/ctr/blob/master/ctrtool/ncch.c 128-bit AES CTR] unless the NoCrypto flag is set in ncchflag[7]. There are different sets of encryption parameters in use, as over the time new system updates introduced more sophisticated means of encryption. Generally, the decryption key is generated using the [[AES\|AES Engine]] key generator by selecting a particular key slot (see below), the keyX of which is usually set by the bootrom and keyY of which was originally set to the first 0x10 bytes of the NCCH signature.

	'''NOTE: For a full understanding of the steps involved in decryption, consult the [https://github.com/Relys/Project_CTR ctrtool] and [https://github.com/archshift/Decrypt9 Decrypt9] source code instead.'''.		'''NOTE: For a full understanding of the steps involved in decryption, consult the [https://github.com/Relys/Project_CTR ctrtool] and [https://github.com/archshift/Decrypt9 Decrypt9] source code instead.'''.
Line 42:		Line 42:
	As of [[7.0.0-13\|7.0.0-X]] the system supports a new encryption method for secure-crypto (when ncchflag[3] != 0). Where a second key is generated using the same keyY but with another [[AES\|keyslot]]. The second key is used to crypt the [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "banner" (i.e. ".code" and ".firm"). While everything else is crypted with the original key. Note the CTR used is the same for both keys. This makes titles "recognizable" but not "launchable" on systems which don't support this method or the keyslot used.		As of [[7.0.0-13\|7.0.0-X]] the system supports a new encryption method for secure-crypto (when ncchflag[3] != 0). Where a second key is generated using the same keyY but with another [[AES\|keyslot]]. The second key is used to crypt the [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "banner" (i.e. ".code" and ".firm"). While everything else is crypted with the original key. Note the CTR used is the same for both keys. This makes titles "recognizable" but not "launchable" on systems which don't support this method or the keyslot used.

	See below for the keyslots used ~~for the additional~~ NCCH ~~keyslots~~. ~~On Old3DS, as~~ of [[9.6.0-24\|9.6.0-X]], Process9 will only use keyslot 0x25 when ncchflag[3] is non-zero.		See below for the keyslots used in NCCH crypto. As of [[9.6.0-24\|9.6.0-X]], Old3DS Process9 will only use keyslot 0x25 when ncchflag[3] is non-zero.
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-
Line 48:		Line 48:
	! FW Introduced		! FW Introduced
	! Old3DS		! Old3DS
	! AES Keyslot		! [[AES#Keyslot\|AES Keyslots]]
	! Notes		! Notes
			\|-
			\| Any
			\| Any
			\| style="background: green" \| Yes
			\| 0x2C
			\| Original keyslot (always used unless NoCrypto flag is set in ncchflag[7])
	\|-		\|-
	\| 0x01		\| 0x01

Neobrain: /* NCCH Header */

2016-03-20T19:12:10Z

NCCH Header

← Older revision		Revision as of 22:12, 20 March 2016
Line 207:		Line 207:
	\| RomFS superblock SHA-256 hash - (SHA-256 hash, starting at 0x0 of the RomFS over the number of media units specified in the RomFS hash region size)		\| RomFS superblock SHA-256 hash - (SHA-256 hash, starting at 0x0 of the RomFS over the number of media units specified in the RomFS hash region size)
	\|}		\|}

			Given offsets are based on the start of the file.

	=== NCCH Flags ===		=== NCCH Flags ===

Neobrain: <@profi200> neobrain: 3DSExplorer is horribly outdated.

2016-03-20T18:26:27Z

<@profi200> neobrain: 3DSExplorer is horribly outdated.

← Older revision		Revision as of 21:26, 20 March 2016
Line 318:		Line 318:

	[https://github.com/profi200/Project_CTR/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing and decrypting (debug only) NCCH files		[https://github.com/profi200/Project_CTR/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing and decrypting (debug only) NCCH files

	~~[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCCH files~~

Neobrain at 19:23, 20 March 2016

2016-03-20T18:23:52Z

← Older revision		Revision as of 21:23, 20 March 2016
Line 1:		Line 1:
	[[Category:File formats]]		[[Category:File formats]]
	The following text tries to document the structure of the NCCH container format.		The following text tries to document the structure of the NCCH container format. This format is used to store the content of any installed [[Titles\|title]].

	== Overview ==		== Overview ==
	There are two known NCCH container ~~specialisations~~ used on the 3DS, "executable" and "non-executable", officially known as CXI and CFA respectively.		There are two known NCCH container specializations used on the 3DS, "executable" and "non-executable", officially known as CXI and CFA, respectively.

	== CXI ==		=== CXI ===

	The CXI (CTR Executable Image) ~~specialisation~~ of the NCCH container contains executable code, which runs on a single ARM11 core.		The CXI (CTR Executable Image) specialization of the NCCH container contains executable code, which runs on a single ARM11 core.

	The CXI format is structured in the following order:		The CXI format is structured in the following order:
Line 20:		Line 20:
	The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.		The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.

	== CFA ==		=== CFA ===

	The CFA (CTR File Archive) ~~specialisation~~ of the NCCH container, is not executable, but ~~are~~ used in conjunction with CXI files. ~~For instance~~ the DLP Child Container and the Electronic Manual. (There is a system update NCCH which follows this format, but is used by the 3DS rather than the Application NCCH, and only works when embedded in the [[CCI]] format because the nVer is kept in the header of retail [[CCI]] files instead of the application NCCH). There are CFA files which exist alone in a title, but these are just [[Title list\|System Data Archive]] titles and are found only in the [[Flash Filesystem#CTR partition\|NAND]].		The CFA (CTR File Archive) specialization of the NCCH container is not executable, but is used in conjunction with CXI files, e.g. the DLP Child Container and the Electronic Manual. (There is a system update NCCH which follows this format, but is used by the 3DS rather than the Application NCCH, and only works when embedded in the [[CCI]] format because the nVer is kept in the header of retail [[CCI]] files instead of the application NCCH). There are CFA files which exist alone in a title, but these are just [[Title list\|System Data Archive]] titles and are found only in the [[Flash Filesystem#CTR partition\|NAND]].

	CFA files are structured in the following order:		CFA files are structured in the following order:
Line 29:		Line 29:
	* followed by an '''optional''' read-only filesystem ([[RomFS]])		* followed by an '''optional''' read-only filesystem ([[RomFS]])

	== ~~NCCH Specs~~ ==		== Container File Format ==

	=== Encryption ===		=== Encryption ===
Line 317:		Line 317:
	== Tools ==		== Tools ==

	[https://github.com/~~3dshax~~/~~ctr~~/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing and decrypting(debug only) NCCH files		[https://github.com/profi200/Project_CTR/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing and decrypting (debug only) NCCH files

	[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCCH files		[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCCH files