3DS System Flaws: Difference between revisions
| Line 16: | Line 16: | ||
! Summary | ! Summary | ||
! Description | ! Description | ||
! Fixed with hardware model/revision | |||
! Newest hardware model/revision this flaw was checked for | |||
! Timeframe this was discovered | ! Timeframe this was discovered | ||
! Discovered by | ! Discovered by | ||
| Line 23: | Line 25: | ||
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc. | Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc. | ||
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized. | The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized. | ||
This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't). | |||
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas. | |||
| New3DS | |||
| End of February 2014 | | End of February 2014 | ||
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently | | [[User:Derrek|derrek]], WulfyStylez (May 2015) independently | ||
| Line 28: | Line 34: | ||
| Missing AES key clearing | | Missing AES key clearing | ||
| The hardware AES engine does not clear keys when doing a hard reset/reboot. | | The hardware AES engine does not clear keys when doing a hard reset/reboot. | ||
| None | |||
| New3DS | |||
| August 2014 | | August 2014 | ||
| Mathieulh/Others | | Mathieulh/Others | ||
| Line 34: | Line 41: | ||
| No RAM clearing on reboots | | No RAM clearing on reboots | ||
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM keeps its contents. | | On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM keeps its contents. | ||
| None | |||
| New3DS | |||
| March 2014 | | March 2014 | ||
| [[User:Derrek|derrek]] | | [[User:Derrek|derrek]] | ||
| Line 40: | Line 49: | ||
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. Therefore, only the first 32bits of the TWL console-unique keydata / TWL consoleID are actually console-unique. | | On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. Therefore, only the first 32bits of the TWL console-unique keydata / TWL consoleID are actually console-unique. | ||
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set). | This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set). | ||
| None | |||
| New3DS | |||
| 2012? | | 2012? | ||
| [[User:Yellows8|Yellows8]] | | [[User:Yellows8|Yellows8]] | ||
| Line 48: | Line 59: | ||
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys. | This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys. | ||
| | |||
| | |||
| 2011 | | 2011 | ||
| [[User:Yellows8|Yellows8]] | | [[User:Yellows8|Yellows8]] | ||