3DS System Flaws
Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.
List of 3DS exploits
Failed attempts
Here are listed all attempts at exploiting 3DS software that have failed so far.
- Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds values, these crashes are caused by the application attempting to load a ptr from a buffer located at NULL.
- Pyramids (3DSWare), QR codes: no strings. The LZ10 compression can't be exploited either. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.
- 3DS browser, 2^32 characters long string: this is similar to the vuln fixed here, concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vuln will cause a memory page permissions fault, since the webkit code attempts to copy the string text data to the output buffer located in read-only CRO heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is that the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some very rare cases a thread separate from the string data-copy thread will crash, this might be exploitable however this is useless since it rarely crashes this way.
Current efforts
There are people working on finding exploits and documenting the 3DS. Here's a list of some current efforts being made to make homebrew on the 3DS possible:
- Neimod has been working on a RAM dumping setup for a little while now. He's desoldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS's PCB up to a custom RAM dumping setup. Recent photos show that the setup is working quite well, with the 3DS successfully booting up. Pictures of neimod's work can be found on his Flickr stream.
Fixed vulnerabilities
- The following was fixed with 7.0.0-13, see here for details. Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings cause (System Settings->Other Settings->Profile->Nintendo DS Profile) to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid).
Tips and info
The 3DS uses the XN feature of the ARM processor, and only apps that have the necessary permissions in their headers can set memory to be executable. This means that although a usable buffer overflow exploit would still be useful, it would not go the entire way towards allowing code to be run in an easy/practical fashion (ie an actual homebrew launcher) - for that, an exploit in the system is required. A buffer overflow exploit does, however, provide enough wriggle room through the use of return-oriented programming to potentially trigger a system exploit.
SD card extdata and SD savegames can be attacked, for consoles where the console-unique movable.sed was dumped.
System flaws
ARM11 kernel
| Summary | Description | Fixed in system version |
|---|---|---|
| svcBackdoor (0x7B) | This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11(with NATIVE_FIRM) requires patching the kernel .text or modifying SVC-access-control. | None |
| 0xEFF00000 ARM11 kernel virtual-mem | The ARM11 kernel-mode 0xEFF00000 virtual-mem(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup, this never seems to be used after that however. | None |
| Command input/output buffer permissions | Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with 4.0.0-7 the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution. | 4.0.0-7 |
| svcControlMemory MemoryOperation MAP memory-permissions | svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution. | 4.1.0-8 |
| svcControlMemory Parameter checks | For svcControlMemory the parameter check had these two flaws:
|
Observed fixed in 7.0. Observed vulnerable in 4.0. |
| svcReadProcessMemory/svcWriteProcessMemory memory permissions | Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs. | 4.0.0-7 |
FIRM ARM11 modules
| Summary | Description | Fixed in system version |
|---|---|---|
| "srv:pm" process registration | Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.
This was fixed in 7.0.0-13: starting with 7.0.0-13 "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s). |
7.0.0-13 |