Changes

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

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

Starting with [[9.6.0-24|9.6.0-X]] Process9 can now generate the NCCH keyY with the first 0x10-bytes from a SHA256 hash (when ncchflag[7] has bitmask 0x20 set). This hash is generated with the data <0x10-long old-method keyY><0x10-long title-unique content lock seed>, where seeds for downloaded titles that use the new crypto are stored in [[Filesystem_services#SEEDDB|SEEDDB]] (nand:/data/<console-unique>/sysdata/0001000f/00000000). When FSUSER OpenFile is used with a NCCH archive where this crypto is used, fs-module will add the seed-data to the end of the [[FSPXI:OpenFile]] file lowpath with the seed from the SEEDDB(this is how Process9 gets the seed data which gets hashed for calculating the NCCH keyY). This new keyY generation is only used for [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "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). This functionality was likely added to support pre-loading of games from the eShop.

Starting with [[9.6.0-24|9.6.0-X]] Process9 can now generate the NCCH keyY with the first 0x10-bytes from a SHA256 hash (when ncchflag[7] has bitmask 0x20 set). This hash is generated with the data <0x10-long old-method keyY><0x10-long title-unique content lock seed>, where seeds for downloaded titles that use the new crypto are stored in [[Filesystem_services#SEEDDB|SEEDDB]] (nand:/data/<console-unique>/sysdata/0001000f/00000000). When FSUSER OpenFile is used with a NCCH archive where this crypto is used, fs-module will add the seed-data to the end of the [[FSPXI:OpenFile]] file lowpath with the seed from the SEEDDB (this is how Process9 gets the seed data which gets hashed for calculating the NCCH keyY). This new keyY generation is only used for [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "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). This functionality was likely added to support pre-loading of games from the eShop.

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.

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.

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 keysot 0x25 when ncchflag[3] is non-zero.

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.

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

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

|-

|-

|  style="background: green" | Yes

|  style="background: green" | 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).

|-

|-

|  0x0A

|  0x0A

|  style="background: red" | No

|  style="background: red" | 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 used, so this works.

|  [[9.6.0-24|9.6.0-X]]'s [[FIRM#New_3DS_FIRM|arm9loader]] also 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).

|}

|}