6,264
edits
Changes
→Hardware
! 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
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
| 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
| 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]]
| 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]]
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]]