3DS System Flaws: Difference between revisions

Line 535:

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]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.

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

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

Decrypting New3DS sector 0x96 keyblock.

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

|

@@ Line 535: / Line 535: @@
 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]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.
-| Dumping of the [[OTP Registers|OTP]] area
+| Dumping the [[OTP Registers|OTP]] area.
+Decrypting New3DS sector 0x96 keyblock.
 | [[3.0.0-5|3.0.0-X]]
 |