3DS System Flaws

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see here.

Stale / Rejected Efforts

• Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.

• Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

Tips and info

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). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

SD card extdata and SD savegames can be attacked, for consoles where the console-unique movable.sed was dumped(accessing SD data is far easier by running code on the target 3DS however).

System flaws

Hardware

Summary	Description	Fixed with hardware model/revision	Newest hardware model/revision this flaw was checked for	Timeframe this was discovered	Discovered by
ARM9/ARM11 bootrom vectors point at unitialized RAM	ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). 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. The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized. This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).	None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.	New3DS	End of February 2014	derrek, WulfyStylez (May 2015) independently
Missing AES key clearing	The hardware AES engine does not clear keys when doing a hard reset/reboot.	None	New3DS	August 2014	Mathieulh/Others
No RAM clearing on reboots	On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM keeps its contents.	None	New3DS	March 2014	derrek
32bits of actual console-unique TWLNAND keydata	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 Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits 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).	None	New3DS	2012?	Yellows8
DSi / 3DS-TWL key-generator	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. From the normal-key outputs, you could deduce the TWL key-generator function. This applies to the keyX/keyY too. This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.			2011	Yellows8

ARM9 software

arm9loader

Summary	Description	Successful exploitation result	Fixed in FIRM system version	Last FIRM system version this flaw was checked for	Timeframe this was discovered	Discovered by
Missing verification-block for the 9.6 keys	Starting with 9.6.0-X a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from 9.5.0-X with the original sector+0 keydata, however the below is only possible with 9.6.0-X since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs. Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it. This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code. This should give very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x save, and 7.x NCCH keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.	Recovery of 6.x save key/7.x NCCH key	None	9.6.0-X	March, 2015	plutoo
Uncleared New3DS keyslot 0x11	Originally the New3DS FIRM arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with 9.5.0-X by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11. This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11. Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with 9.6.0-X.	New3DS keyXs generation	Mostly fixed with 9.5.0-X, completely fixed with new keys with 9.6.0-X.		February 3, 2015 (one day after 9.5.0-X release)	Yellows8

Process9

Summary	Description	Successful exploitation result	Fixed in FIRM system version	Last FIRM system version this flaw was checked for	Timeframe this was discovered	Discovered by
FAT FS code null-deref	When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL. Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash: ... Starting check/repair pass. <FilePath0> and <FilePath1> share clusters. Truncating second to 3375104 bytes. <FilePath1> File size is 2787392 bytes, cluster chain length is 16384 bytes. Truncating file to 16384 bytes. Checking for unused clusters. Reclaimed 1 unused cluster (16384 bytes). Checking free cluster summary. Free cluster summary wrong (1404490 vs. really 1404491) Auto-correcting. Starting verification pass. Checking for unused clusters. Leaving filesystem unchanged.	Useless null-based-read	None	9.6.0-X	July 8-9, 2015	Yellows8
RSA signature padding checks	The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see here. The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.		None	9.5.0-X	March 2015	Yellows8
firmlaunch-hax: FIRM header ToCToU	This can't be exploited from ARM11 userland. During FIRM launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data. With 9.5.0-22 the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.	ARM9 code execution	9.5.0-22		2012, 3 days after Yellows8 started Process9 code RE.	Yellows8
Uninitialized data output for (PXI) command replies	PXI commands for various services(including some here and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error. Certain ARM11 service commands have this same issue as well.		None	9.3.0-X	?	Yellows8
FSPXI OpenArchive SD permissions	Process9 does not use the exheader ARM9 access-mount permission flag for SD at all. This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.		None	9.3.0-X	2012	Yellows8
AMPXI:ExportDSiWare export path	Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>". Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.	Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.	None	9.5.0-22	April 2013	Yellows8
DSiWare_Exports CTCert verification	Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed. On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.	When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.	Unknown, probably none.	?	April 2013	Yellows8
Gamecard_Services_PXI unchecked REG_CTRCARDCNT transfer-size	The u8 REG_CTRCARDCNT transfer-size parameter for the Gamecard_Services_PXI read/write CTRCARD commands is used as an index for an array of u16 values. Before 5.0.0-X this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).	Out-of-bounds read for a value which gets written to a register.	5.0.0-X		2013?	Yellows8
PXI cmdbuf buffer overrun	The Process9 code responsible PXI communications didn't verify the size of the incoming command before writing it to a C++ member variable.	Probably ARM9 code execution	5.0.0-11		March 2015, original timeframe if any unknown	plutoo/Yellows8/maybe others(?)
PXIAM command 0x003D0108(See also this)	When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with 5.0.0-X, the total combined size of the input data must be <=0x2800.	ARM9 code execution	5.0.0-X		May 2013	Yellows8
PS RSA commands buffer overflows	pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable. The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses svcBreak.	ARM9 code execution	5.0.0-X		2012	Yellows8
PXI pxi_id bad check	The Process9 code responsible for PXI communications read pxi_id as a signed char. There were two flaws: They used it as index to a lookup-table without checking the value at all. Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.	Maybe ARM9 code execution	3.0.0-5		March 2015, originally 2012 for the first issue at least	plutoo, Yellows8, maybe others(?)

Kernel9

Summary	Description	Successful exploitation result	Fixed in FIRM system version	Last FIRM system version this flaw was checked for	Timeframe this was discovered	Discovered by
CFG_SYSPROT9 bit1 not set by Kernel9	Old versions of Kernel9 never set bit1 of CFG_SYSPROT9. This leaves the 0x10012000-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution. See here regarding the data stored there. From 3.0.0-X this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9.	Dumping of the OTP area	3.0.0-X		February 2015	plutoo, Normmatt independently

ARM11 software

Kernel11

Summary	Description	Successful exploitation result	Fixed in FIRM system version	Last FIRM system version this flaw was checked for	Timeframe this was discovered	Discovered by
SVC table too small	The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers. However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.		None	10.0.0-X	2012	Everyone
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.	See description	None	10.0.0-X		Everyone
0xEFF00000 / 0xDFF00000 ARM11 kernel virtual-memory	The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(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	10.0.0-X
AffinityMask/processorid validation	With 10.0.0-X the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical. The original code with the first 3 did the following: if(u32_processorcount > ~0x80000001)return 0xe0e01bfd; if(s32_processorcount > <total_cores>)return 0xd8e007fd; The following code replaced the above: if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd; In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue. The svcCreateThread changes with 10.0.0-X definitely did fix a security issue. Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;" New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;" This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <10.0.0-X. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result: Old3DS: Useless kernel-mode crash due to accessing unmapped memory. New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).	Nothing useful	10.0.0-X	10.0.0-X	svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.	Yellows8
memchunkhax	The kernel originally did not validate the data stored in the FCRAM kernel heap memchunk-headers for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn. There are multiple ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping. This was fixed in 9.3.0-X by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.	When combined with other flaws: ARM11-kernelmode code execution	9.3.0-21		February 2014	Yellows8
Multiple KLinkedListNode SlabHeap use after free bugs	The ARM11-kernel did access the 'key' field of KLinkedListNode objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new KLinkedListNode object at the right time could result in a type-confusion. Pseudo-code: SlabHeap_free(KLinkedListNode); KObject *obj = KLinkedListNode->key; // the object there might have changed! This bug appeared all over the place.	ARM11-kernelmode code exec maybe	8.0.0-18		April 2015	derrek
PXI Command input/output buffer permissions	Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with 6.0.0 PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.		6.0.0-11		2012	Yellows8
svcStartInterProcessDma	For svcStartInterProcessDma, the kernel code had the following flaws: Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction. Integer overflows for srcaddr+size and dstaddr+size are now checked(with 6.0.0-11), which were not checked before. The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with 6.0.0-11) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion).		6.0.0-11		DmaConfig issue: unknown. The rest: 2014	plutoo, Yellows8 independently
svcControlMemory Parameter checks	For svcControlMemory the parameter check had these two flaws: The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003. Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).		5.0.0-11			plutoo
Command request/response buffer overflow	Originally the kernel did not check the word-values from the command-header. Starting with 5.0.0-11, the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all. If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of ((size<<14) | 2) to write arbitrary memory to any RW userland memory in the destination process.		5.0.0-11		v4.1 FIRM -> v5.0 code diff	Yellows8
SVC stack allocation overflows	Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow. This might allow for ARM11 kernel code-execution. (Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)		5.0.0-11		v4.1 FIRM -> v5.0 code diff	plutoo, Yellows8 complementary
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		2012	Yellows8
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		2012	Yellows8
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		2012?	Yellows8

FIRM Sysmodules

Summary	Description	Successful exploitation result	Fixed in FIRM system version	Last FIRM system version this flaw was checked for	Timeframe this was discovered	Discovered by
"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. With 7.0.0-13 there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this. 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).	Access to arbitrary services	7.0.0-13		2012	Yellows8
FSDIR null-deref	FS-module may crash in some cases when handling directory reading. The trigger seems to be due to using FSDir:Close without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.		None	9.6.0-X	May 19(?)-20, 2015	Yellows8

Standalone Sysmodules

Summary	Description	Successful exploitation result	Fixed in system-module system-version	Last system-module system-version this flaw was checked for	Timeframe this was discovered	Timeframe this was added to wiki	Discovered by
SPI service out-of-bounds write	cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.		None	9.5.0-22	March 2015		plutoo
NFC module service command buf-overflows	NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>. Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module. There's no known retail titles which have access to either of these services.	ROP under NFC module.	New3DS: None	New3DS: 9.5.0-22	December 2014?		Yellows8
NEWSS service command notificationID validation failure	This module does not validate the input notificationID for "news:s" service commands. This is an out-of-bounds array index bug. For example, NEWSS:SetNotificationHeader could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).	ROP under news module.	None	9.7.0-X	December 2014		Yellows8
NWMUDS:DecryptBeaconData heap buffer overflow	input_size = 0x1E * <value the u8 from input_networkstruct+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA. This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process. There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.	Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.	None	9.0.0-20	~September 23, 2014(see the NWMUDS:DecryptBeaconData page history)	August 3, 2015	Yellows8
HID module shared-mem	HID module does not validate the index values in sharedmem(just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.	ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.	None	9.3.0-21	2014?		Yellows8
gspwn	GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text(Home Menu, Internet Browser, etc) is located beyond the area accessible by the GPU, except for CROs used by applets(Internet Browser for example). FCRAM is gpu-accessible up to physaddr 0x26400000 on Old3DS, and 0x2DC00000 on New3DS.	User-mode code execution.	None	9.6.0-X	Early 2014		smea, Yellows8/others before then
rohax	Using gspwn, it is possible to overwrite a loaded CRO0/CRR0 after its RSA-signature has been validated. Badly validated CRO0 header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to syscalls 0x70-0x72, 0x7D. This was fixed after ninjhax release by adding checks on CRO0-based pointers before writing to them.	Memory-mapping syscalls.	9.3.0-21	9.4.0-21			smea, plutoo joint effort
Region free	Only Home Menu itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with NS without signaling Home Menu to launch the app, will result in region checks being bypassed. This essentially means launching the gamecard with the "ns:s" service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware reboot.	Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation	None	9.8.0-X	June(?) 2014		Yellows8
NWM service-cmd state null-ptr deref	The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized. It's unknown whether any NWM services besides NWMUDS have this issue.	This is rather useless since it's only a crash caused by a state ptr based at 0x0.	None	9.0.0-20	2013?		Yellows8

General/CTRSDK

Summary	Description	Successful exploitation result	Fixed in version	Last version this flaw was checked for	Timeframe this was discovered	Discovered by
UDS beacon additional-data buffer overflow	Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a networkstruct. This was eventually fixed. This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version. It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this). The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.	Perhaps ROP, very difficult if possible with anything at all	?		September(?) 2014	Yellows8