Difference between revisions of "OTP Registers"
Jump to navigation
Jump to search
| Line 12: | Line 12: | ||
| 0x0 | | 0x0 | ||
| 0x100 | | 0x100 | ||
| − | | Console-unique data. This data appears 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 for the AES engine | + | | Console-unique data. This data appears 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. |
|- | |- | ||
| 0x100 | | 0x100 | ||
Revision as of 18:28, 31 March 2015
Keys seem to be stored here? Access to this region is disabled once the ARM9 writes 0x2 to REG_SYSPROT9.
Originally the console-unique TWL keyinit + region disable was done by Kernel9. 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 key generation.
On development units (UNITINFO!=0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL keydata. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the ARM9-loader. It is unknown if bootrom reads from it, but probably.
| Offset | Size | Description |
|---|---|---|
| 0x0 | 0x100 | Console-unique data. This data appears 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. |
| 0x100 | 0x8 | Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL-keydata to here. |