Changes

4 bytes added ,  08:18, 14 May 2015
no edit summary
Line 22: Line 22:  
| ARM9's exception vectors are hardcoded to point at ARM9 RAM. While the bootrom does set them up to point to itself at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection to induce an invalid instruction will cause execution to fall into ARM9 RAM.  
 
| ARM9's exception vectors are hardcoded to point at ARM9 RAM. While the bootrom does set them up to point to itself at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection to induce an invalid instruction will cause execution to fall into ARM9 RAM.  
 
Since RAM isn't cleared on boot, one can immediately start execution of their own code here to dump bootrom, OTP, etc.
 
Since RAM isn't cleared on boot, one can immediately start execution of their own code here to dump bootrom, OTP, etc.
| Middle of 2014, May 2015
+
| May 2015
| derrek, WulfyStylez independently
+
| WulfyStylez
 
|-
 
|-
 
| Missing AES key clearing
 
| Missing AES key clearing
Line 70: Line 70:  
This allows an hardware-based NAND-attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process eventually you'll find some garbage that jumps to your code.
 
This allows an hardware-based NAND-attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process eventually you'll find some garbage that jumps to your code.
   −
This should give you very early ARM9 code execution (pre-ARM9 kernel). For example, you can dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset0.
+
This should give you very early ARM9 code execution (pre-ARM9 kernel). For example, you can dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset0 and has dumped the OTP area of the Old3DS.
 
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
 
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
 
| None
 
| None