3DS System Flaws: Difference between revisions
| Line 25: | Line 25: | ||
| Mathieulh/Others | | Mathieulh/Others | ||
|- | |- | ||
| No clearing | | 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. | ||
| March 2014 | | March 2014 | ||
| [[User:Derrek|derrek]] | | [[User:Derrek|derrek]] | ||
|- | |||
| 32bits of actual console-unique TWLNAND keydata | |||
| 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). | |||
| 2012? | |||
| [[User:Yellows8|Yellows8]] | |||
|- | |- | ||
| DSi / 3DS-TWL key-generator | | DSi / 3DS-TWL key-generator | ||