NCCH: Difference between revisions

Line 39:

The extended header, the [[ExeFS]] and the [[RomFS]] are encrypted using 128-bit AES CTR. See here regarding the [https://github.com/3dshax/ctr/blob/master/ctrtool/ncch.c CTR].

~~By default encrypted regions are compressed(ExeFS:/.code only) with an LZ77 variant, then encrypted.~~ The ~~spec allows for both unencrypted and uncompressed regions to exist. Development units use a fixed system~~ key ~~for system titles. For the "Secure crypto" NCCH encryption mode(the encryption mode used for retail NCCH)~~ the [[AES|~~keyY~~]] is the first 0x10-bytes of the NCCH signature~~, the AES engine internally generates the final~~-~~normal key(see [[AES|here]] for the keyslot)~~.

The key is generated using the [[AES|AES Engine]] key generator, where the keyX is set by the bootrom (keyslot 0x2C) and the keyY is the first 0x10 bytes of the NCCH signature. This method of key generation is referred to as "secure-crypto".

~~As of [[7.0.0-13]] the system now supports~~ a ~~new encryption method for the secure-cryptotype, the CTR for this is the same as before. This is enabled when~~ NCCH flag~~[3]~~ is ~~non-zero~~. ~~When enabled~~, ~~the [[RomFS]] and [[ExeFS]] files~~ which ~~don't~~ have ~~filenames "icon" or "banner"~~(~~that is~~, "~~.code~~") are ~~crypted with a different keyslot. 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)~~.

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.

~~With New3DS~~ [[9.3.0-21|9.3.0-X]] new ~~NCCH~~ crypto support ~~was added, enabled via~~ ncchflag[3]=~~0x0A~~. ~~This~~ is ~~identical to~~ the v7.0 crypto ~~except with a New3DS~~-~~only keyslot~~.

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 keyslots used for generating the second key.

{| class="wikitable" border="1"

|-

! ncchflag[3]

! FW Introduced

! Old3DS

! AES Keyslot

! Notes

|-

| 0x01

| [[7.0.0-13|7.0.0-X]]

| style="background: green" | Yes

| 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).

|-

| 0x0A

| [[9.3.0-21|9.3.0-X]]

| style="background: red" | No

| ?

|

|}

=== Format ===

Currently, only [[ExeFS]]:/.code can be compressed (with a LZ77 variant). A flag in the [[NCCH/Extended Header#System Info|exheader]] determines if this is the case.

On retail for SD applications, exheader_systeminfoflags.flag bit1 must be set.

Retail CFAs use NCCH product code "CTR-P-CTAP", while retail title/gamecard CXIs use NCCH product code "CTR-P-XXXX". This product code is the NCCH [[Serials|serial code]]. The region-locking info checked by home menu is stored in the [[SMDH#BNR Region|icon]].

Retail CFAs use the default NCCH product code "CTR-P-CTAP", while retail title/gamecard CXIs use NCCH product code "CTR-X-XXXX". This product code is the NCCH [[Serials|serial code]]. The region-locking info checked by home menu is stored in the [[SMDH#BNR Region|icon]].

All of the hashes stored in this NCCH header are over the cleartext data. The ExeFS/RomFS superblock starts at offset 0x0 in the ExeFS/RomFS, and the size is specified by the hash region fields. ~~Interestingly,~~ Nintendo's NCCH validation code seems to have the size of this region fixed to 0x200 bytes (for ExeFS at least).

All of the hashes stored in this NCCH header are over the cleartext data. The ExeFS/RomFS superblock starts at offset 0x0 in the ExeFS/RomFS, and the size is specified by the hash region fields. Nintendo's NCCH validation code seems to have the size of this region fixed to 0x200 bytes (for ExeFS at least).

As of [[5.0.0-11]] the application [[ExeFS]]:/.logo can be loaded from the plaintext region between the access descriptor and the plain region, all applications built since [[5.0.0-11]] store the logo here. The size of this logo is always 0x2000-bytes.

As of [[5.0.0-11]] the application [[ExeFS]]:/logo can be loaded from the plaintext region between the access descriptor and the plain region, all applications built since [[5.0.0-11]] store the logo here. The size of this logo is always 0x2000-bytes.

The plain region mainly contains tags for each SDK library used when building the CXI. The version used for the "FIRMWARE" tag is the kernel/FIRM [[Configuration_Memory|version]], this version can also be stored in the exheader "kernel release version" ARM11 kernel descriptor field. As of [[2.2.0-X]] the NATIVE_FIRM kernels check the CXI exheader "kernel release version" field, if it is stored in the CXI exheader. If the kernel/FIRM version specified by this field is higher than the version of the running NATIVE_FIRM, the kernel will return error-code 0xD9001413.

Line 188:

Line 211:

|-

| 3

| Crypto Method: When this is non-zero, a NCCH crypto method using two keyslots is used(see above)~~. v7.0 keyslot(Old3DS/New3DS) = 0x01, v9.3 keyslot(New3DS only) = 0x0A~~.

| Crypto Method: When this is non-zero, a NCCH crypto method using two keyslots is used(see above).

|-

| 4

@@ Line 39: / Line 39: @@
 The extended header, the [[ExeFS]] and the [[RomFS]] are encrypted using 128-bit AES CTR. See here regarding the [https://github.com/3dshax/ctr/blob/master/ctrtool/ncch.c CTR].
-By default encrypted regions are compressed(ExeFS:/.code only) with an LZ77 variant, then encrypted. The spec allows for both unencrypted and uncompressed regions to exist. Development units use a fixed system key for system titles. For the "Secure crypto" NCCH encryption mode(the encryption mode used for retail NCCH) the [[AES|keyY]] is the first 0x10-bytes of the NCCH signature, the AES engine internally generates the final-normal key(see [[AES|here]] for the keyslot).
+The key is generated using the [[AES|AES Engine]] key generator, where the keyX is set by the bootrom (keyslot 0x2C) and the keyY is the first 0x10 bytes of the NCCH signature. This method of key generation is referred to as "secure-crypto".
-As of [[7.0.0-13]] the system now supports a new encryption method for the secure-cryptotype, the CTR for this is the same as before. This is enabled when NCCH flag[3] is non-zero. When enabled, the [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "banner"(that is, ".code") are crypted with a different keyslot. 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).
+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.
-With New3DS [[9.3.0-21|9.3.0-X]] new NCCH crypto support was added, enabled via ncchflag[3]=0x0A. This is identical to the v7.0 crypto except with a New3DS-only keyslot.
+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 keyslots used for generating the second key.
+{| class="wikitable" border="1"
+|-
+!  ncchflag[3]
+!  FW Introduced
+!  Old3DS
+!  AES Keyslot
+!  Notes
+|-
+|  0x01
+|  [[7.0.0-13|7.0.0-X]]
+|  style="background: green" | Yes
+|  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).
+|-
+|  0x0A
+|  [[9.3.0-21|9.3.0-X]]
+|  style="background: red" | No
+|  ?
+|
+|}
 === Format ===
+Currently, only [[ExeFS]]:/.code can be compressed (with a LZ77 variant). A flag in the [[NCCH/Extended Header#System Info|exheader]] determines if this is the case.
 On retail for SD applications, exheader_systeminfoflags.flag bit1 must be set.
-Retail CFAs use NCCH product code "CTR-P-CTAP", while retail title/gamecard CXIs use NCCH product code "CTR-P-XXXX". This product code is the NCCH [[Serials|serial code]]. The region-locking info checked by home menu is stored in the [[SMDH#BNR Region|icon]].
+Retail CFAs use the default NCCH product code "CTR-P-CTAP", while retail title/gamecard CXIs use NCCH product code "CTR-X-XXXX". This product code is the NCCH [[Serials|serial code]]. The region-locking info checked by home menu is stored in the [[SMDH#BNR Region|icon]].
-All of the hashes stored in this NCCH header are over the cleartext data. The ExeFS/RomFS superblock starts at offset 0x0 in the ExeFS/RomFS, and the size is specified by the hash region fields. Interestingly, Nintendo's NCCH validation code seems to have the size of this region fixed to 0x200 bytes (for ExeFS at least).
+All of the hashes stored in this NCCH header are over the cleartext data. The ExeFS/RomFS superblock starts at offset 0x0 in the ExeFS/RomFS, and the size is specified by the hash region fields. Nintendo's NCCH validation code seems to have the size of this region fixed to 0x200 bytes (for ExeFS at least).
-As of [[5.0.0-11]] the application [[ExeFS]]:/.logo can be loaded from the plaintext region between the access descriptor and the plain region, all applications built since [[5.0.0-11]] store the logo here. The size of this logo is always 0x2000-bytes.
+As of [[5.0.0-11]] the application [[ExeFS]]:/logo can be loaded from the plaintext region between the access descriptor and the plain region, all applications built since [[5.0.0-11]] store the logo here. The size of this logo is always 0x2000-bytes.
 The plain region mainly contains tags for each SDK library used when building the CXI. The version used for the "FIRMWARE" tag is the kernel/FIRM [[Configuration_Memory|version]], this version can also be stored in the exheader "kernel release version" ARM11 kernel descriptor field. As of [[2.2.0-X]] the NATIVE_FIRM kernels check the CXI exheader "kernel release version" field, if it is stored in the CXI exheader. If the kernel/FIRM version specified by this field is higher than the version of the running NATIVE_FIRM, the kernel will return error-code 0xD9001413.
@@ Line 188: / Line 211: @@
 |-
 |  3
-|  Crypto Method: When this is non-zero, a NCCH crypto method using two keyslots is used(see above). v7.0 keyslot(Old3DS/New3DS) = 0x01, v9.3 keyslot(New3DS only) = 0x0A.
+|  Crypto Method: When this is non-zero, a NCCH crypto method using two keyslots is used(see above).
 |-
 |  4