Changes

| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] and instead blocked access to the [[OTP Registers|OTP Registers]] itself, presumably under the assumption that an attacker would never gain code execution under Kernel9. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!) to an attacker with sufficient privileges. Since it's never locked, you can dump it once you get ARM9 code execution.

| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] and instead blocked access to the [[OTP Registers|OTP Registers]] itself, presumably under the assumption that an attacker would never gain code execution under Kernel9. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!) to an attacker with sufficient privileges. Since it's never locked, you can dump it once you get ARM9 code execution.

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, which is exploitable through a hardware vulnerability (see arm9loaderhax / description).

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, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).

This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.

This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.