Changes

| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution. See [[OTP Registers|here]] regarding the data stored there.

| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution. See [[OTP Registers|here]] regarding the data stored there.

From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9. This is exploitable on N3DS however if you downgrade to 1.0 and reencrypt the NAND with keyslot 0x4 instead of 0x5.

From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9.

 

This flaw resurged when it gained a new practical use for retrieving the OTP data for a New3DS console, in order to generate the keydata used in arm9loader. This was performed by downgrading to a vulnerable system version and installing the relevant Old3DS firmware to NAND. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) it is possible to boot a New3DS in this state, and retrieve the required OTP data.

| Dumping of the [[OTP Registers|OTP]] area

| Dumping of the [[OTP Registers|OTP]] area

| [[3.0.0-5|3.0.0-X]]

| [[3.0.0-5|3.0.0-X]]