3DS System Flaws: Difference between revisions
| Line 100: | Line 100: | ||
! Public disclosure timeframe | ! Public disclosure timeframe | ||
! Discovered by | ! Discovered by | ||
|- | |||
| Generating the keysector console-unique keys with ITCM+Boot9 | |||
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP. | |||
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially. | |||
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous). | |||
| See description. | |||
| None | |||
| | |||
| 2015 | |||
| January 6, 2017 | |||
| [[User:Yellows8|Yellows8]] | |||
|- | |- | ||
| Rearrangable keys in the NAND keystore | | Rearrangable keys in the NAND keystore | ||