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

• In the early days of 3DS hacking, Neimod was working on a RAM dumping setup for a while. 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. 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. RAM dumping can be done through homebrew now, making this method obsolete regardless.

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). A 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 uninitialized 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 has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.	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/VRAM 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.	None	New3DS	2011	Yellows8
3DS key-generator	The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered. Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.	None	New3DS	February 2015	Yellows8, plutoo
RSA keyslots don't clear exponent when setting modulus	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. However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output. By 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. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent. This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.	None	New3DS	March 2016	Myria
CFG11_GPUPROT allowing acccess to AXIWRAM/FCRAM-BASE-memregion	CFG11_GPUPROT can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below). See also "kernelhax via gspwn" below.	None	New3DS	February 7, 2017	Yellows8

Boot ROM

Summary	Description	Fixed with hardware model/revision	Newest hardware model/revision this flaw was checked for	Timeframe this was discovered	Discovered by
FIRM partitions known-plaintext	The FIRM partitions are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it. This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5). However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax. This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.	None	New3DS		Everyone
Boot9 AES keyinit function issues	Boot9 seems to have two bugs in the AES key-init function, see here.	None	BootROM issue.	2015	Yellows8
New3DS has same boot ROM as Old3DS	The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG9_SYSPROT9 bit1 not set by Kernel9").	None	New3DS	October 2014	Everyone
sighax: Boot9 improper validation of FIRM partition RSA signatures	The FIRM partitions are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways: Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice. Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature. Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block. Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid. As a result of the above, we estimate that one in 243 (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.	None	New3DS	July 2015	derrek
Boot9 FIRM loading doesn't blacklist memory-mapped I/O	Boot9's FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, a malicious FIRM can be used to overwrite: a) boot9 data-abort handler, coupled with a 4th section that tries to NDMA copy to NULL, causing a data abort b) boot9 IRQ handler (this has the disadvantage that you must restore the original handler, then call it manually when your payload runs)	None	New3DS	2015(?)	derrek (2015?), Normmatt and SciresM independently (January 2017).
"superhax": Boot9 FIRM loading blacklist check is flawed	Boot9 only makes sure the start and end address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart || blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure The boot9 vector table (0x08000000) contains 6 entries, each 8-bytes wide (0x30 bytes); Only 0x08000000 through 0x08000040 are blacklisted, and boot9 doesn't use the region after the vector table (this is convenient because we can put any payload we want after it and not worry about overwriting chunks of boot9 code) To exploit this, craft a FIRM section payload that's loaded a few bytes before 0x08000000, add padding to get to 0x08000000 and overwrite the vector table; You could overwrite the data-abort vector and craft a 4th FIRM section that causes a data-abort OR you can just overwrite the IRQ function pointer at 0x08000004 (make sure your payload replaces the original boot9 function pointer); you can point the rest of the vectors to infinite loops since they shouldn't be triggered.	None	New3DS	August 2015	plutoo, 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	Public disclosure timeframe	Discovered by
Generating the keysector console-unique keys with ITCM+Boot9	Boot9 decrypts the 0x100-byte OTP using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into ITCM. This is the exact same region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP. Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially. It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).	See description.	None		2015	January 6, 2017	Yellows8
Rearrangable keys in the NAND keystore	Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.	arm9loaderhax given existing ARM9 code execution	None	11.3.0-X	Early 2016	27 September 2016	Myria, dark_samus; mathieulh (independently); plutoo (independently) + others
Uncleared OTP hash keydata in console-unique 0x11 key-generation	Kernel9Loader does not clear the SHA_HASH register after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of OTP data used to seed the console-unique NAND keystore decryption key set on keyslot 0x11. Retrieving this keydata and the NAND keystore of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current New3DS-only AES keyXs including the newer batch introduced in 9.6.0-X. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS. This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <3.0.0-X. This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.	Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)	None	11.3.0-X	~April 2015, implemented in May 2015	13 January 2016	WulfyStylez, Dazzozo, shinyquagsire23 (complimentary + implemented), plutoo, Normmatt (discovered independently)
enhanced-arm9loaderhax	See the 32c3 3ds talk. Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.	arm9loaderhax which automatically occurs at hard-boot.	See arm9loaderhax / description.	See arm9loaderhax / description.	Theorized around mid July, 2015. Later implemented+tested by plutoo and derrek.	32c3 3ds talk (December 27, 2015)	Yellows8
arm9loaderhax: 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 gives 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, access to uncleared OTP hash keydata	None	11.3.0-X	March 2015		plutoo
arm9loader runs on Old3DS	Despite being written only for New3DS, all of arm9loader runs fine on Old3DS. It's not until booting Kernel9 that a New3DS FIRM partition would crash on an Old3DS. As a result, if a bug exists in arm9loader to get control, it can be exploited on Old3DS by writing New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS.	arm9loader bugs also compromise Old3DS	None	11.3.0-X	Sometime in 2015		plutoo presumably
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	Public disclosure timeframe	Discovered by
Leak of normal-key matching a key-scrambler key	New 3DS firmware versions 8.1.0 through 9.2.0 set the encryption key for Amiibo data using a hardcoded normal-key in Process9. In firmware 9.3.0, Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9. Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.	Deducing the keyX for keyslot 0x39 and the key scrambler algorithm	New 3DS 9.3.0-X, sort of	10.0.0-X	Sometime in 2015 after the hardware key-generator was broken.	32c3 3ds talk (December 27, 2015)	Yellows8
Leak of normal-key matching a key-generator key	During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content (CIA). Common-key index1 was intended to be a hardware generated key. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release. Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered. Note that the devkit key-generator was discovered to be the same as the retail key-generator.	Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.	pre-1.0.0-X		Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk	January 20, 2016	jakcron
Factory firmware is vulnerable to sighax	During the 3DS's development, presumably boot9 was written (including the sighax vulnerability). This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.	Deducing the mechanics of the sighax vulnerability in boot9 without having a dump of protected boot9. ARM9 code execution on factory/earlier firmware.	1.0.0-X	1.0.0-X	May 9, 2017	May 19, 2017	SciresM, Myria
twlhax: Corrupted SRL header leads to memory overwrite	During TWL_FIRM boot, the ARM11 process TwlBg puts launcher.srl, the DSi bootloader, into FCRAM. TWL_FIRM Process9 then parses the SRL header to place launcher.srl's code where DSi mode can execute it. DSi-mode memory is in FCRAM, but interleaved. Each byte of DSi-mode memory also exists at some address in 3DS FCRAM space. Process9 does not validate the RSA signature on launcher.srl, unlike SRLs loaded from cartridge or NAND (DSiWare). A compromised ARM11 can, in a manner similar to firmlaunchhax, send a launcher.srl with a modified SRL header. By setting the SRL header's ARM7/ARM9 load addresses and sizes carefully, accounting for the different memory map and for DSi mode's interleaved memory, it is possible to overwrite part of Process9's stack and take control with a ROP chain. Fixed in 11.8.0-X by... (fill me in)	ARM9 code execution (whilst still in 3DS mode)	11.8.0-X	11.8.0-X		August 11, 2018	smea
safefirmhax	SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by just checking 3dbrew/ninupdates title-listings. The fix for firmlaunch-hax was only applied to NATIVE_FIRM in 9.5.0-X, leaving SAFE_FIRM exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.	ARM9 code execution	11.3.0-X		2012-2013?	Wiki: January 2, 2017	Everyone
safefirmhax 1.1	Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack. This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.	ARM9 code execution	11.4.0-X		safefirmhax fix	Wiki: April 10, 2017	Everyone
ntrcardhax	When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read. However that register is shared between the ARM9 and the ARM11. An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow. With a custom banner for a NTR flashcart, this leads to code execution in Process9. This was fixed by adding bound checks on the read data.	ARM9 code execution	10.4.0-X		March 2015	32c3 3ds talk (December 27, 2015)	plutoo
Title downgrading via AM(PXI)	When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error. However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the Title_Database, Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way. 11.0.0-X fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.	Bypassing title version check at installation, which then allows downgrading any title.	11.0.0-X, for key system titles.	NATIVE_FIRM / AM-sysmodule 11.0.0-X	?		?
Anti-downgrade list did not include all system titles initially	The anti-downgrade list did not include legacy FIRMs until 11.8.0-X. Therefore, legacy FIRMs could still be downgraded.	Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).	11.8.0	11.8.0	?	Wiki: August 5, 2018	Everyone
TWL_FIRM cmd-9 unchecked offset	In 1.0.0-X's TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were). Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid). Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read. offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted. In 2.0.0-X TWL_FIRM, those commands were stubbed out.	ARM9 code execution	2.0.0-X	2.0.0-X	January 2018	Wiki: August 5, 2018	Riley
FIRM launch doesn't check target FIRM version	When executing a FIRM launch, Process9 doesn't validate that the target FIRM isn't an old version. This allows booting an exploitable FIRM from a newer FIRM, if you can get the exploitable FIRM installed. (11.0.0-X now prevents installing old versions of system titles, but this doesn't affect titles already installed.) This had a use after 9.6.0-X: on a compromised 3DS running 9.2.0, you could install the 9.6.0 NATIVE_FIRM to FIRM0/FIRM1, but avoid putting it into the NATIVE_FIRM title. This would boot the 9.2.0 system software but with the 9.6.0 Process9 and Kernel11. With a user-mode exploit in a sufficiently-privileged application (e.g. mset), you could trigger a FIRM launch back to NATIVE_FIRM, which would load the 9.2.0 Process9 and Kernel11. 9.6.0's keyslots 0x15 and 0x16 are unknown to 9.2.0, so 9.2.0 would not clear them. You then could do firmlaunchhax against 9.2.0 to get ARM9 access with keyslots 0x15 and 0x16 set to their proper 9.6.0 values, allowing decrypting 9.6.0's encrypted titles. Once the New3DS keystore was dumped, this became moot.	Decrypting 9.6.0 NCCH files without dumping New3DS keystore	None (but now moot)	9.6.0-X	March 2015	August 12, 2018	Yellows8, Myria
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
AMPXI:ValidateDSiWareSectionMAC AES keyslot reuse	When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this. This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.	See description.	None	11.3.0-X	March 15, 2015	December 29, 2015	Yellows8
pxips9 AES keyslot reuse	This requires access to the ps:ps/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk). When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.	Reusing the previously used keyslot, for crypto with PS.	None	11.3.0-X	Roughly the same time(same day?) as firmlaunch-hax.	December 29, 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 this is used in conjunction with seedminer to be able to decrypt & modify DSiWare TAD containers and inject them with exploitable DSiWare titles such as sudoku (sudokuhax) and Flipnote JPN (ugopwn)	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.	None.	11.10.0-X	April 2013		Yellows8
seedminer: movable.sed keyY vulnerable to brute-force	Half of the movable.sed keyY's 128 bits are leaked through the LFCS, which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.	Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.	None.	11.8.0-X	December 2017	January 2018	zoogie
Improper validation of DSiWare title SRLs	The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export.	This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.	None.	11.10.0-X	2015?	December 2016	Everyone
DSiWare import/export functions allow TWL system titles as arguments	AM ImportTwlBackup/ExportTwlBackup unnecessarily allow TWL system titles such as DS Download Play to import/export from userland and System Settings -> Data Management (only am:sys is needed for userland). This is difficult to abuse for dsihax injection because no TWL system title has a save file, and any import with a save included will result in FS err C8804464. However, there is at least one dsihax primary that can load a payload from a non-NAND source, and not error if it can't access its public.sav (JPN Flipnote Studio v0).	When combined with other public vulns, arm9 code execution.	None.	11.10.0-X	May 2018	Sept 2018	zoogie
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
CFG9_SYSPROT9 bit1 not set by Kernel9	Old versions of Kernel9 never set bit1 of CFG9_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. 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, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description). This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types here) and using an Old3DS NCSD Header, it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.	Dumping the OTP area. Decrypting New3DS sector 0x96 keyblock.	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
svcSetProcessIdealProcessor reference count overflow and therefore use-after-free.	The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. It can be abused to overflow the KProcess reference count that will lead to an Use-after-free.	Before 11.2.0-X: reference count overflow and therefore use-after-free.		11.6.0-X	November 2, 2017	st4rk
svcGetThreadList process reference leak	When given a valid process handle (including 0xFFFF8001), svcGetThreadList forgets to decrement the reference count of the underlying KProcess instance, after having finished using it.	Before 11.2.0-X: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable		11.3.0-X	April 3, 2017	TuxSH
kernelhax via gspwn	Originally the kernel didn't initialize CFG11_GPUPROT. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.	Entire FCRAM+AXIWRAM R/W.	3.0.0-X		February 7, 2017	plutoo, Yellows8 partly
fasthax	When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.	See description.	11.3.0-X	11.3.0-X	May 2016	nedwill
ipctakeover	When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process. Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx". This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.	See description.	None	11.3.0-X	November 26, 2016	Yellows8
Using IPC input buffers as output buffers	When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this. Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".	See description.	None	11.3.0-X	November 2016	Yellows8
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	11.3.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) required patching the kernel .text or modifying SVC-access-control.	See description	11.0.0-X (deleted)			Everyone
veryslowpidhax	This is completely different from the kernelmode-code-execution vuln described in the below separate entry. When updating the kernel global PID counter under svcCreateProcess the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because SM-module allows processes with PID value less than <total ARM11 FIRM modules> to access all services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the SVCs access table at all. Inlined ldrex+strex code is used for updating the above counter. 11.2.0-X had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected. With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).	Access to all services, ControlMemory on any given mem-region.	None	11.3.0-X	2012 maybe?
slowhax/waithax	svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.	ARM11 kernel-mode code execution	11.2.0-X	11.2.0-X	2016	nedwill, derrek
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 for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.		None	11.3.0-X
memchunkhax2.1	Nintendo's fix for memchunkhax2 in 10.4.0-X did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation. derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.	ARM11 kernel code execution	11.0.0-X, via the new memchunkhdr MAC which prevents modifying memchunkhdr data with DMA.	11.0.0-X		derrek, aliaspider
memchunkhax2	When allocating a block of memory, the "next" pointer of the memchunkhdr is accessed without being checked after being mapped to userland. This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects.	ARM11 kernel code execution	10.4.0-X (partially, see memchunkhax2.1)	10.4.0-X		derrek
heaphax	Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.	Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.	11.0.0-X, via the new memchunkhdr MAC which prevents modifying memchunkhdr data with DMA.	11.0.0-X	April 2015 ?	smea
snshax	Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.	Code execution with access to all of NS's privileges. (including downgrading)	10.1.0-X	10.1.0-X	April 2015 ?	smea
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). The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).	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
SM out-of-bounds BSS write (table 1 entry too small)	After accepting a new session, SM writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard. Unfortunately, as of 11.4.0-37, the overwritten fields are totally unused after their initialization by __libc_init_array.	Not currently exploitable	None	11.4.0-37

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
CFG:CreateConfigInfoBlk integer underflow	When creating a new block it checks the size of the block is <= 0x8000, but it doesn't check that the block size is less than the remaining space. This induces an integer underflow (remaining_space-block_size), the result is then used for another check (buf_start+current_offset+constant <= remaining_space-block_size) and then in a mempcy call (dest = buf_start+(u16)(remaining_space-block_size), size =block_size). This allow for writing past the buffer, however because of the u16 cast in the memcpy call memory has to be mapped from buf_start to buf_start+0x10000 (cannot write backward).	Theoritically ROP under CFG services, but BSS section is to small (size <= 0x10000) so it only results in a crash.	None	11.8.0-41	November, 2018	November 24, 2018	MrNbaYoh
MP:SendDataFrame missing input array index validation	MP:SendDataFrame doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset. After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset. With a large input index someptr could be setup to be at a <target address>, for overwriting memory. This is probably difficult to exploit.		None	8.0.0-18(MP-sysmodule v2048)	January 22, 2017	January 22, 2017	Yellows8
MP cmd1 out-of-bounds handle read	MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex]. Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).	Reading any handle in MP-sysmodule memory.	None	8.0.0-18(MP-sysmodule v2048)	January 21, 2017	January 22, 2017	Yellows8
AM stack/.bss infoleak via AM:ReadTwlBackupInfo(Ex)	After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss. This was not tested on hardware.	Stack/.bss reading	None	10.0.0-27(AM v9217)	Roughly October 17, 2016	October 25, 2016	Yellows8
MVD: Stack buffer overflow with MVDSTD:SetupOutputBuffers.	The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry). If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.	MVD-sysmodule crash.	None	9.0.0-20	April 22, 2016 (Tested on the 25th)	April 25, 2016	Yellows8
NWM: Using CTRSDK heap with UDS sharedmem from the user-process.	See the HTTP-sysmodule section below. CTRSDK heap is used with the sharedmem from NWMUDS:InitializeWithVersion. Buffers are allocated/freed under this heap using NWMUDS:Bind and NWMUDS:Unbind. Hence, overwriting sharedmem with gspwn then using NWMUDS:Unbind results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule. This could be done by creating an UDS network, without any other nodes on the network. Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.	ROP under NWM-module.	None (need to check, but CTRSDK heap code is vulnerable)	9.0.0-X	April 10, 2016	April 16, 2016	Yellows8
DLP: Out-of-bounds memory access during spectator data-frame checksum calculation	DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf. Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).	DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.	None	10.0.0-X	April 8, 2016 (Tested on the 10th)	April 10, 2016	Yellows8
DLP: Out-of-bounds output data writing during spectator sysupdate titlelist data-frame handling	The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory. There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command. There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).		None	10.0.0-X	April 8-9, 2016	April 10, 2016	Yellows8
IR: Stack buffer overflow with custom hardware	Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See here for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack. This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.	ROP under IR sysmodule.	10.6.0-31		February 23, 2016 (Unknown if it was noticed before then)	February 23, 2016	Yellows8
HTTP: Using CTRSDK heap with sharedmem from the user-process.	The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command. Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe". This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule. This is exploited by ctr-httpwn.	ROP under HTTP sysmdule.	None	11.13.0-X	Late 2015	March 22, 2016	Yellows8
NIM: Downloading old title-versions from eShop	Multiple NIM service commands(such as NIMS:StartDownload) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) title-downgrading via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop if it's still available from CDN. The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version). Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.	Downloading old title-versions from eShop	None	10.0.0-X	October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)	January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)	Yellows8
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 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With 11.3.0-X the cutoff now varies due to the new SVC 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new SVC 0x59.	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	Last tested with 10.1.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
CECD Streetpass message exheader stack-smashing	When parsing streetpass messages, "nn::cec::CTR::Message::InputMessage" calls "nn::cec::CTR::Message::SetExHeaderWithoutCalc" for each exheader entry in the input message. The number of entries should not exceed 16 but remains unchecked, leading to a stack-buffer-overflow.	ROP under any application parsing Streetpass messages Remote code execution under CECD	11.12.0-44		2019	MrNbaYoh
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
CTPK buffer overflow	At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow. While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.	ROP under the target application.	None?	"[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"	November 14, 2016	Yellows8