By entering this site you need to consent to the use of cookies and their functional use according to this privacy policy. Cookies help us to provide the functional services of the website. Kindly read the below message of use and consent to the use.
The following cookies are stored and shared when accessing this website:
- Internal cookies for the MediaWiki site. This is used for user authentication and article modifications.
- Third-party cookies from Google providing services for Google AdSense and Google Analytics
We will never use data collected outside of the above scope.
| 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).