This allows retrieving the exponent by doing a discrete logarithm of the output.īy setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the Pohlig-Hellman algorithm. However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. The exponent value in the RSA registers is write-only and not readable. The RSA keyslots are set by boot ROM to have four private RSA keys. RSA keyslots don't clear exponent when setting modulus Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered. The algorithm for generating the normal-keys for keyslots is cryptographically weak. This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys. From the normal-key outputs, you could deduce the TWL key-generator function. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).Īfter using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique. On top of this, the lower u32's highest bit is always ORed. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On retail the 8-bytes at ARM9 address 0x01FFB808 are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.ģ2bits of actual console-unique TWLNAND keydata The hardware AES engine does not clear keys when doing a hard reset/reboot. None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.ĭerrek, WulfyStylez (May 2015) independently It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015. This requires *very* *precise* timing for triggering the hardware fault. 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. Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. Newest hardware model/revision this flaw was checked forĪRM9/ARM11 bootrom vectors point at uninitialized RAMĪRM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). SD card extdata and SD savegames can be attacked, for consoles where the console-unique d was dumped(accessing SD data is far easier by running code on the target 3DS however). From ROP one could then exploit system flaw(s), see below. A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a SVC for this, but only RO-module has access to it). The 3DS uses the XN feature of the ARM11 processor. RAM dumping can be done through homebrew now, making this method obsolete regardless. He has published photos showing his setup to be working quite well, with the 3DS successfully booting up, but however, his flickr stream is now private along with most of his work and this method has been unreleased. He has de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS's PCB up to a custom RAM dumping setup. In the early days of 3DS hacking, Neimod was working on a RAM dumping setup for a while.
0 Comments
Leave a Reply. |