Changes

== Overview ==

== Overview ==

Console-unique keys seem to be derived from here, though it is unknown how. Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

Console-unique keys are derived from here. Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

This is very likely the console-unique data store, including [[CTCert]] and other unit info values, that ends up in ITCM at 0x01FFB800. Bootrom would decrypt it, check for magic (0xDEADB00F), and then set CFG_UNITINFO, etc to match the specific console at hand. This is a guess based on the matching size of both sets of data (ITCM's is padded to 0x100, specifically) and the lack of another known source for this data on the system (it is not sourced from eMMC). On top of this, the latter half of this data is likely used as console-unique keydata, thus explaining ITCM's copy being memcleared and the OTP lock mechanism existing. Refer to [[Memory_layout#ARM9_ITCM]] for what is contained in the decrypted OTP.

This is the console-unique data store, including [[CTCert]] etc, that ends up in ITCM at 0x01FFB800. After decryption, the first 0x90-bytes of plaintext are copied to 0x01FFB800 if hash verification passes. Refer to [[Memory_layout#ARM9_ITCM]] for what is contained in the decrypted OTP.

On [[FIRM]] versions prior to [[3.0.0-6|3.0.0-X]], this region was left unprotected. On versions since [[3.0.0-6|3.0.0-X]], this has been fixed, and the region disable is now done by Kernel9 after doing console-unique TWL keyinit, by setting bit 1 of [[CONFIG|REG_SYSPROT9]]. However, with the [[New_3DS]] FIRM ARM9 binary this is now done in the [[FIRM]] ARM9 binary loader, which also uses the 0x10012000 region for New 3DS key generation.

On [[FIRM]] versions prior to [[3.0.0-6|3.0.0-X]], this region was left unprotected. On versions since [[3.0.0-6|3.0.0-X]], this has been fixed, and the region disable is now done by Kernel9 after doing console-unique TWL keyinit, by setting bit 1 of [[CONFIG|REG_SYSPROT9]]. However, with the [[New_3DS]] FIRM ARM9 binary this is now done in the [[FIRM]] ARM9 binary loader, which also uses the 0x10012000 region for New 3DS key generation.

On development units ([[CONFIG|UNITINFO]] != 0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL Console ID. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the [[FIRM|ARM9-loader]]. It is unknown if bootrom reads from it, but it is likely.

On development units ([[CONFIG|UNITINFO]] != 0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL Console ID. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the [[FIRM|ARM9-loader]].

 

Normally [[Bootloader|Boot9]] will pass plaintext_otp+0x90 to the AES keyinit function, but when hash verification fails it will pass 0x10012000(otp+0) instead.

== Sections ==

== Sections ==

| 0x0

| 0x0

| 0x100

| 0x100

| Console-unique data. This data appears to be random, even when multiple consoles' dumps from this area are XORed. None of the raw data here seems to match any of the console-unique keys (tested: keyX, keyY and normal-key, both big and little u32 endianness for all keyslots) for the AES engine. It's unknown whether there's any encryption on this area.

| Console-unique data encrypted with AES-CBC. The normalkey and IV are stored in Boot9. The last 0x20-bytes of plaintext are a SHA256 hash over the first 0xE0-bytes of plaintext.

|-

|-

| 0x100

| 0x100

| 0x8

| 0x8

| Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL Console ID here. This sets the registers at 0x4004D00 for ARM7.

| Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL Console ID here. This sets the registers at 0x4004D00 for ARM7.

|}

|}