3DS System Flaws: Difference between revisions

Line 381:

|-

| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9

| 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]] 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.

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).

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. This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.x, and 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]], and retrieve the required OTP data using this flaw.

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

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

|

| February 2015

| [[User:Plutooo|plutoo]], Normmatt independently

| [[User:Plutooo|plutoo]], Normmatt independently, [[User:Plailect|Plailect]] (hardware-less public implementation)

|}

@@ Line 381: / Line 381: @@
 |-
 | [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
-| 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]] 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.
+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).
-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. This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.x, and 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]], and retrieve the required OTP data using this flaw.
 | Dumping of the [[OTP Registers|OTP]] area
 | [[3.0.0-5|3.0.0-X]]
 |
 | February 2015
-| [[User:Plutooo|plutoo]], Normmatt independently
+| [[User:Plutooo|plutoo]], Normmatt independently, [[User:Plailect|Plailect]] (hardware-less public implementation)
 |}