Changes

130 bytes added ,  02:09, 12 December 2016
m
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 ===
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 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 48: Line 48:  
!  FW Introduced
 
!  FW Introduced
 
!  Old3DS
 
!  Old3DS
!  AES Keyslot
+
[[AES#Keyslot|AES Keyslots]]
 
!  Notes
 
!  Notes
 
|-
 
|-
 
|  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).
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 ===
Line 317: Line 319:  
== 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
 
7

edits