Validating and writing system software to the filesystem
The RSA keyslots are set by boot ROM to have four private RSA keys.
The exponent value in the RSA registers is write-only and not readable.
only 31 bits of the TWL console-unique keydata / TWL console ID are actually console-unique.
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND.
While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately.
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.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
After 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.
SD card extdata and SD savegames can be attacked, for consoles where the console-unique was dumped(accessing SD data is far easier by running code on the target 3DS however).
ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11).
The 3DS uses the XN feature of the ARM11 processor.
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).