3dbrew - User contributions [en]

3DS System Flaws

2023-08-07T23:25:41Z

EvilFlight: Process9 primary

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 [[3DS_Userland_Flaws|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_Services|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 [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! 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.

The vulnerable timing range is about 100 CPU cycles after they start (which happens after the PLLs have stabilized after power-up). A glitch needs to be injected during one of these 100 cycles for the attack to succeed.

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
| [[User:Derrek|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
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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?
| [[User:Yellows8|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|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 [[wikipedia:Pohlig-Hellman algorithm|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
| [[User:Myria|Myria]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|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
| [[User:Yellows8|Yellows8]]
|}

== Boot ROM ==
{| class="wikitable" border="1"
! 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 [[Flash_Filesystem|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
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[User:Yellows8|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 [[Flash_Filesystem|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
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|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(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|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 <nowiki>||</nowiki> 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
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]
|}

== ARM9 software ==

=== arm9loader ===
{| class="wikitable" border="1"
|-
! 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
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|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
| [[User:Yellows8|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-36|11.3.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|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 [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|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-6|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-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|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 [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| arm9loaderhax: Missing verification block for the 9.6 keys
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 [[Savegames#6.0.0-11_Savegame_keyY|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 [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| [[11.3.0-36|11.3.0-X]]
| March 2015
|
| [[User:Plutooo|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-36|11.3.0-X]]
| Sometime in 2015
|
| [[User:Plutooo|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-22|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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! 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-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|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-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|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 [[AES|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-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|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-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
|-
| safecerthax
| O3DS & O2DS SAFE_FIRM is still vulnerable to the PXIAM:ImportCertificates flaw fixed in [[5.0.0-11]] and to SSLoth fixed in [[11.14.0-46]]. It makes it possible to spoof the official NUS update server and remotely trigger the vulnerability in SAFE_FIRM.
| Remote Arm9 code execution in O3DS/O2DS SAFE_FIRM
| None
| [[11.14.0-46|11.14.0-X]]
| 2020
| December 18, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| 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 [http://dsibrew.org/wiki/NDS_Format 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-41|11.8.0-X]]
| [[11.8.0-41|11.8.0-X]]
|
| August 11, 2018
| smea
|-
| agbhax
| This is the same issue as twlhax above. Legacy FIRMs share the same OS code (Arm9-side OS, Arm11 kernel), and therefore, the outdated AGB_FIRM can be tricked into executing the still vulnerable PrepareArm9ForTwl function.
| ARM9 code execution (whilst still in 3DS mode)
| None
| [[11.14.0-46|11.14.0-X]]
|
| December 17, 2020
| Everyone
|-
| 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-22|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-36|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-37|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-29|10.4.0-X]]
|
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|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-33|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-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|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-41|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-33|11.8.0]]
| [[11.8.0-33|11.8.0]]
| ?
| Wiki: August 5, 2018
| Everyone
|-
| TWL_FIRM cmd-9 unchecked offset
| In [[1.0.0-0|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-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.
| ARM9 code execution
| [[2.0.0-2|2.0.0-X]]
| [[2.0.0-2|2.0.0-X]]
| January 2018
| Wiki: August 5, 2018
| [[User:Riley|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-33|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-24|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-24|9.6.0-X]]
| March 2015
| August 12, 2018
| [[User:Yellows8|Yellows8]], [[User:Myria|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:

<pre>...
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.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[FS:EnumerateExtSaveData]] crashes process9 when trying to parse a file as an extdata directory in Data Management (MSET9)
| When FS_EnumerateExtData is called by [[System_Settings|MSET]] to parse 3DS extdata IDs for Data Management, a file that starts with 8 hex digits can crash process9 if placed directly inside the extdata directory. It can crash in various ways based on subtle differences in the way the user triggers the crash event.

While mostly leading to null derefs, in one specific context, process9 jumps directly to an ID1 string being held in ARM9 memory. Surprisingly, the 3DS doesn't discern what characters are used for the ID1 directory name on the SD, only requiring exactly 32 chars. This allows the attacker to insert arm instructions into the unicode ID1 dirname and take control of the ARM9, and thus, full control of the 3DS.
| ARM9 code execution (primary)
| None
| [[11.17.0-50|11.17.0-X]]
| April 2022
| August 7, 2023
| zoogie
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|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-36|11.3.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| This requires access to the [[Process_Services|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-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|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 [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|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-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|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
|
| [[User:Yellows8|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
|
| [[User:Yellows8|Yellows8]]
|-
| seedminer: movable.sed keyY vulnerable to brute-force
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|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-11|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-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|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|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]]:ImportCertificates (See also [[Application_Manager_Services|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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|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|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]]. This leaves the [[OTP Registers|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-5|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 [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|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 Registers|OTP]] area.
Decrypting New3DS sector 0x96 keyblock.
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! 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|svcUnbindInterrupt]] double free when irqId = 15
| svcBindInterrupt and svcUnbindInterrupt give special treatment to irqId 15 (FIQ helper): the access control list is bypassed and the provided KInterruptEvent (event or semaphore, via handle) is stored inside a singleton static object after having its refcount increased by 1.

svcUnbindInterrupt assumes that the user-provided handle is what is stored in the singleton and will decref the user-provided KInterruptEvent twice, causing a use-after-free if the attacker didn't actually provide an handle to the same event or semaphore.

This was "fixed" on [[11.14.0-46|11.14.0-X]] by preventing irqId 15 to be bound on retail units altogether (in both functions).
| Arm11 kernel code execution
| [[11.14.0-46|11.14.0-X]] (only on retail units)
| [[11.14.0-46|11.14.0-X]]
| 2019
| [[User:TuxSH|TuxSH]], maybe others
|-
| [[SVC|svcKernelSetState]] op=3 could map the NULL page
| svcKernelSetState op=3 param1=1 maps the firmlaunch parameters page to the user-specified VA.

It had previously no check, allowing the attacker to map data at VA 0.

Starting from [[11.14.0-46|11.14.0-X]], the VA must be in the standard 0x10000000-0x14000000 address range.
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
| [[11.14.0-46|11.14.0-X]]
| [[11.14.0-46|11.14.0-X]]
| 2019
| [[User:TuxSH|TuxSH]]
|-
| [[SVC|svcMapProcessMemory]] can map the NULL page
| svcMapProcessMemory's destination VA is unchecked.

By passing a big enough "size" parameter, an attacker can map chunks of data at VA 0 in the destination (caller) process.
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
| None
| [[11.14.0-46|11.14.0-X]]
| 2020
| [[User:TuxSH|TuxSH]]
|-
| Resource limit use-after-free
| When assigning a KResourceLimit to a KProcess, the reslimit's refcounter doesn't get incremented. This essentially means all KResourceLimit get freed if pm gets somehow terminated.

It turns out it is possible to ask pm (via ns:s or pm:app) to terminate itself along all other KIPs simply by passing TID 0004000100001000.

Calling [[SVC|svcGetResourceLimit]] afterwards triggers a use-after-free. This is rather difficult to exploit, however: there is one slot left in the reslimit slabheap. An attacker either has to map the NULL page as R(W)X (svcControlProcessMemory vuln fixed on [[11.8.0-41|11.8.0-X]]), or use one of the map-null exploits above while having access to svcCreateResourceLimit (with the only one that is easy enough to use in that context having been fixed on [[11.14.0-46|11.14.0-X]], anyway).
| Arm11 kernel code execution
| None (although near impossible to exploit on [[11.14.0-46|11.14.0-X]])
| [[11.14.0-46|11.14.0-X]]
| 2020
| [[User:TuxSH|TuxSH]]
|-
| [[SVC|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-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|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-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|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-36|11.3.0-X]]
| [[11.3.0-36|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-36|11.3.0-X]]
| November 26, 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| November 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| 2012
| Everyone
|-
| [[SVC|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-33|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 [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|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 [[SVC|SVCs]] access table at all.

Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|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_API|services]], ControlMemory on any given mem-region.
| None
| [[11.3.0-36|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-35|11.2.0-X]]
| [[11.2.0-35|11.2.0-X]]
| 2016
| nedwill, [[User:Derrek|derrek]]
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|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-36|11.3.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
|
| [[User:Derrek|derrek]], aliaspider
|-
| memchunkhax2
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|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-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
|
| [[User:Derrek|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|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-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| AffinityMask/processorid validation
| With [[10.0.0-27|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-27|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-27|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-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|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-21|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|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|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-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|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]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|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 <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|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
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|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
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[Services|"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
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|-
| Useless [[SM]] off-by-one write
| 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 <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|-
| smpwn
| When registering a new service (or "port"), no bound checks are done on the service table. One can simply call RegisterPort repeatedly to overflow that table: it will overflow into the command replay structure.

Combined with a other minor bugs in the sysmodule, it is possible to take over [[SM]] with this nevertheless difficult-to-exploit vulnerability.
| Code execution under [[SM]], etc.
| [[11.16.0-48]]
| [[11.14.0-46]]
| July 2017
| [[User:TuxSH|TuxSH]] (independently), presumably ichfly before
|-
| PXI cmdbuf buffer overrun
| Like its Arm9 counterpart, before version [[5.0.0-11|5.0.0-X]], the PXI system module did not check the command sizes. This makes it possible to get ROP under the PXI sysmodule from a pwned Process9.
safecerthax uses it to takeover the Arm11 processor after directly getting remote code execution on the Arm9 side. Though, is useless in classic Arm11 -> Arm9 chains.
| ROP under [[PXI_Services|PXI]]
| probably [[5.0.0-11|5.0.0-X]]
| [[11.14.0-46]]
|
| Everyone
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CSND_Services|CSND]] sysmodule crash due to out of bounds parameters.
| The CSND command [[CSND:PlaySoundDirectly|PlaySoundDirectly (0x00040080)]] takes a channel ID as the first parameter. Any value outside the range [0-3] makes the system module become unstable or crash due to an out of bounds memory read.
| Out of bounds memory read, probably not exploitable. More research needed.
| None
| [[11.14.0-46]]
| January 2021
| January 22, 2021
| [[User:PabloMK7|PabloMK7]]

|-
| SSLoth: [[SSL_Services|SSL]] sysmodule improper certificate verification
| Initially, the SSL sysmodule missed the R_VERIFY_RES_SIGNATURE entry in the "resource list" provided to the RSA BSAFE library. Consequently, it did not check signatures when validating certificate chains.
| Forge fake certificates, spoof official servers and perform MitM attacks on SSL/TLS connections.
| [[11.14.0-46]]
| [[11.14.0-46]]
| 2020
| December 18, 2020
| [[User:Nba_Yoh|MrNbaYoh]], shutterbug2000 (independently)

|-
| [[CECD_Services|CECD:ndm]] SetNZoneMacFilter (cmd8) stack smashing
| The length of the mac filter is not checked before being copied to a fixed-size buffer on stack.
| ROP under [[CECD_Services|CECD]] sysmodule
| None
| [[11.13.0-45]]
| 2020
| July 20, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[CECD_Services|CECD]] message box access
| CECD allows any process to write to any message box, thus allowing to write Streetpass data to the message box of any title.
| Install exploit for any title having a vulnerability in Streetpass data parsers (see CTRSDK Streetpass parser vulnerability).
| None
| None
| ?
| June 1, 2020
| Everyone?
|-
| [[CECD_Services|CECD]] packet type 0x32/0x34 stack-smashing
| When parsing Streetpass packets of type 0x32 and 0x34, CECD copies a list without checking the number of entries. The packet length is limited to 0x400 bytes, which is not enough to reach the end of the stack frame and overwrite the return address. However, the buffer located just next to the packet buffer is actually filled with data sent just before, hence actually allowing to overwrite the whole stack frame with conrolled data.
| RCE under [[CECD_Services|CECD]]
| [[11.12.0-44]]
| [[11.12.0-44]]
| Summer 2019
| June 1, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[CECD_Services|CECD]] TMP files parser multiple vulnerabilities
| When parsing "TMP_XXX" files, CECD does not check the number of messages contained in the file. This allows to overflow the array of message pointers and message sizes on the stack. Pointers aren't controlled and sizes are limited (one cannot send gigabytes of data...), yet the last message size can be an arbitrary value (the current message pointer goes outside the file buffer and the parsing loop is broken). This allows to overwrite a pointer to a lock object on the stack and decrement an arbitrary value in memory. One can change the TMP file parsing mode to have CECD trying to free all the message buffers after parsing the next TMP file. The parsing mode is usually restored when parsing a new TMP file, but an invalid TMP file allows to make a function returns an error before the mode is restored , the return value is not checked and the parser consider the file valid. The message pointers and sizes arrays are not updated though, this is not a problem since the previous TMP file buffer is reused for the new TMP file in memory. Thus the message pointers actually points to controlled data. This allows to get a bunch of fake heap chunk freed, thus a bunch of unsafe unlink arbitrary writes.
| RCE under [[CECD_Services|CECD]]
| [[11.12.0-44]]
| [[11.12.0-44]]
| Summer 2019
| June 1, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[Config_Services|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
| [[User:Nba_Yoh|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
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|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
| [[User:Yellows8|Yellows8]]
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|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
| [[User:Yellows8|Yellows8]]
|-
| AM module APcert infoleak via 00000000.ctx files
| Just after a download title is purchased from the eShop, the .ctx is in an initialized state of all FFs past the header. During download, the FF area is filled with the console APcert. Thus, it is possible to create a xorpad from the initial state and use it to decrypt the APcert filled state.
| APcert contains the deviceID, which can beneficial in decrypting the movable.sed (since deviceID is mathmatically related to the LFCS).
| None
| [[11.16.0-49]]
| August, 2022
| March 17, 2023
| zoogie
|-
| [[MVD_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|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-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|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-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|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 [[10.6.0-31|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|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|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 [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| None
| [[11.13.0-45|11.13.0-X]]
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|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) [[#Process9|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-27|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)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
| Code execution under spi sysmodule; access to [[CONFIG11_Registers|CFG11_GPUPROT]] and ultimately kernel code execution.
| None
| [[11.14.0-46]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|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?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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?
|
| [[User:Yellows8|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 [[RO_Services|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-36|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-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|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 [[SVC|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, [[User:Plutooo|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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CECD_Services|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_Services|CECD]]
| [[11.12.0-44]]
|
| 2019
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[NWM_Services|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 [[NWM_Services|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]]
|-
| Pia vulns
| [https://switchbrew.org/wiki/Switch_System_Flaws#Pia Originally discovered in Pia v5.x for Switch], these vulns are also present in earlier versions (v3.x/4.x/5.x, possibly earlier?) for 3DS (and Wii U too).
Pia encryption generally wasn't used pre-Switch (sent packets are plaintext). 3DS is affected by all Pia vulns listed above except for LAN. The functionality for ParseLeaveMeshInvitation doesn't exist in 3DS Pia v3.9.2. Wii U is affected by all listed Pia vulns except for the LAN vulns.
| See [https://switchbrew.org/wiki/Switch_System_Flaws#Pia here].
| Unfixed on 3DS/Wii U
| "[SDK+Nintendo:PIA_5_4_3]"
| See [https://switchbrew.org/wiki/Switch_System_Flaws#Pia here]; separately checked later (UpdateConnectionReport) by [[User:Riley|Riley]] on: June 14, 2023
| [[User:Yellows8|Yellows8]]; added to 3dbrew (UpdateConnectionReport) by [[User:Riley|Riley]] later
|}

Homebrew Exploits

2023-05-23T08:05:42Z

EvilFlight:

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits. '''No longer needed as of [https://github.com/AuroraWright/Luma3DS/releases/tag/v8.0 Luma 8.0]'''
| From '''9.0.0-7''' up to '''11.9.0-42'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (USA/EUR/JPN, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/zoogie/smilehax-IIe smilehax IIe]
| From '''9.0.0-7''' up to and including '''11.13.0-45'''
| SmileBASIC (JPN version 3.3.2 via app downgrade, USA/EUR 3.6.0, aka latest app version)
| zoogie
| [https://github.com/zoogie/smilehax-IIe/releases/latest Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.9.0-37'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|-
| style="background: salmon" | No
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X''' up to and including '''11.2.0-X'''.
| A gamecard or eShop-install of Monster Hunter X (JPN only), and the DLC encryption key (see installer instructions). '''Note: the secondary exploit still works, see bellow'''
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: salmon" | No
| [https://github.com/nedwill/soundhax soundhax]
| From '''9.0.0-13''' up to and including '''11.3.0-36'''.
| A USA, EUR, JPN or KOR system.
| nedwill
| [http://soundhax.com Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.6.0-X'''.
| An eShop-install of Swapdoodle (version 1.1.1 or lower). As of 2017-4-26, version 1.1.2 was released, blocking outdated app version from sending or receiving messages.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/rpwng2 RPwnG 2]
| From '''1.1.7-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA. A 3DS on firmware 11.7.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng2/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://twitter.com/MrNbaYoh/status/899394739543437313 RPwnG]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| An digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA/JPN is required. As of August 28, 2017 the code is instantly removed after publishing.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng/ Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/notehax notehax]
| From '''9.9.0-X''' up to and including '''11.5.0-X'''.
| A digital copy of Flipnote Studio 3D on ver 1.3.1 (JPN) and ver 1.0.0 for EUR/USA (not the latest)
| MrNbaYoh
| [https://mrnbayoh.github.io/notehax/ Install]
|-
| style="background: darkorange" | Only if you already purchased Blockfactory before it was removed from the eShop
| [https://github.com/Stary2001/haxfactory haxfactory]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of "Blockfactory" (USA/EUR)
| Stary2001
| [https://github.com/Stary2001/haxfactory Install]
|}

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X'''
| A copy of Steel Diver: Sub Wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X''', for '''X''' up to and including 39.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't co-exist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.2.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.2.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to '''11.9.0-X'''.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.9.0-X'''.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.1.0-X'''.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire v1 or v1.4 with the ability to have a secret base.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|-
| style="background: lightgreen" | Yes
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X'''(JPN) or '''10.3.0-X'''(EUR/USA) up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of Monster Hunter Generations or Monster Hunter X (without the game updates installed), and an internet connection during installation.
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/painthax painthax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| An eShop-install of Pixel Paint.
| MrNbaYoh
| [https://github.com/MrNbaYoh/painthax/releases/latest install]
|-
| style="background: salmon" | No
| [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh]
| From '''9.9.0-X''' up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of "The Legend of Zelda: Tri Force Heroes", and an Internet connection during installation. Unless you have "CFW", ctr-httpwn >=v1.2 with the included bosshaxx on a compatible system-version is also required. If installing via ctr-httpwn, you can't do so on >=v11.4. Note that the exploit itself was not fixed.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/ctpkpwn/releases Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.4.0-X'''.
| An eShop-install of Swapdoodle.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://github.com/ChampionLeake/RPwnG3 RPwnG3]
| From '''9.0.0-X'''(?) up to and including '''11.12.0-X'''.
| A Digital/Physical copy of "RPGMaker Fes Player/RPGMaker Fes" (USA/JPN 1.1.2 or lower ; EUR 1.1.4 or lower).
| [[User:ChampionLeake|ChampionLeake]]
| [https://github.com/ChampionLeake/RPwnG3/releases Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/luigoalma/nitpic3d nitpic3d]
| From '''9.6.0-X'''(?) up to and including '''11.13.0-X'''.
| A digital or physical of Picross 3D: Round 2
| Luigoalma and Kartik
| [https://github.com/luigoalma/nitpic3d Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/PabloMK7/kartdlphax kartdlphax]
| All system versions work.
| A digital or physical of Mario Kart 7 for the same region as both consoles
| PabloMK7
| [https://3ds.hacks.guide/installing-boot9strap-(kartdlphax) Install]
|}

==Exploits without Homebrew Launcher==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format, but could still prove useful by chaining to exploits with higher privileges.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: lime" | Yes
| [https://safecerthax.rocks safecerthax] (Safe Mode System Updater)
| (Old3DS (2DS) (XL)) ''' ALL '''

(New3DS (New2DS) (XL)) '''NOT SUPPORTED'''
|An O3DS or O2DS that can be booted into [[Recovery_Mode|Recovery Mode]] (hold L+R+Up+A at startup) & an internet connection.
|[[User:Nba_Yoh|MrNbaYoh]]
|[https://safecerthax.rocks/user-guide/ Install]
|-
| style="background: lime" | Yes (partially)
| [[bannerbomb3]] (System Settings)
| (USA / EUR / JPN) '''11.5.0''' to '''11.16.0'''

(KOR / TWN) '''(11.4.0)''' '''11.5.0''' to '''latest'''

An exploit that uses a buffer overflow in a TWL export banner's title strings to gain rop execution.
|A USA, EUR, JPN, KOR, or TWN system with its movable.sed keyY extracted.
|[[User:zoogie|zoogie]]
|[[bannerbomb3|Install]]
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

[https://github.com/AuroraWright/Luma3DS Luma3DS], apart from providing signature patches for the installation and use of custom titles, includes the "Rosalina" system module, which among its features allows cleanly loading 3dsx applications as a native process with full ARM11 system permissions, by replacing an installed title's ExeFS and ExHeader during load time. It is currently the only option for running 3dsx applications on 11.4+ O3DSes; additionally, the *hax 2.x payload is incompatible with Rosalina and therefore so are homebrew applications requiring its target title system.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: salmon" | No, still usable pre-v11.4.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.3.0-X'''. This includes bosshaxx.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

Homebrew Exploits

2023-05-23T08:01:00Z

EvilFlight:

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits. '''No longer needed as of [https://github.com/AuroraWright/Luma3DS/releases/tag/v8.0 Luma 8.0]'''
| From '''9.0.0-7''' up to '''11.9.0-42'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (USA/EUR/JPN, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/zoogie/smilehax-IIe smilehax IIe]
| From '''9.0.0-7''' up to and including '''11.13.0-45'''
| SmileBASIC (JPN version 3.3.2 via app downgrade, USA/EUR 3.6.0, aka latest app version)
| zoogie
| [https://github.com/zoogie/smilehax-IIe/releases/latest Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.9.0-37'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|-
| style="background: salmon" | No
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X''' up to and including '''11.2.0-X'''.
| A gamecard or eShop-install of Monster Hunter X (JPN only), and the DLC encryption key (see installer instructions). '''Note: the secondary exploit still works, see bellow'''
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: salmon" | No
| [https://github.com/nedwill/soundhax soundhax]
| From '''9.0.0-13''' up to and including '''11.3.0-36'''.
| A USA, EUR, JPN or KOR system.
| nedwill
| [http://soundhax.com Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.6.0-X'''.
| An eShop-install of Swapdoodle (version 1.1.1 or lower). As of 2017-4-26, version 1.1.2 was released, blocking outdated app version from sending or receiving messages.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/rpwng2 RPwnG 2]
| From '''1.1.7-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA. A 3DS on firmware 11.7.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng2/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://twitter.com/MrNbaYoh/status/899394739543437313 RPwnG]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| An digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA/JPN is required. As of August 28, 2017 the code is instantly removed after publishing.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng/ Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/notehax notehax]
| From '''9.9.0-X''' up to and including '''11.5.0-X'''.
| A digital copy of Flipnote Studio 3D on ver 1.3.1 (JPN) and ver 1.0.0 for EUR/USA (not the latest)
| MrNbaYoh
| [https://mrnbayoh.github.io/notehax/ Install]
|-
| style="background: darkorange" | Only if you already purchased Blockfactory before it was removed from the eShop
| [https://github.com/Stary2001/haxfactory haxfactory]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of "Blockfactory" (USA/EUR)
| Stary2001
| [https://github.com/Stary2001/haxfactory Install]
|}

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X'''
| A copy of Steel Diver: Sub Wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X''', for '''X''' up to and including 39.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't co-exist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.2.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.2.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to '''11.9.0-X'''.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.9.0-X'''.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.1.0-X'''.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire v1 or v1.4 with the ability to have a secret base.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|-
| style="background: lightgreen" | Yes
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X'''(JPN) or '''10.3.0-X'''(EUR/USA) up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of Monster Hunter Generations or Monster Hunter X (without the game updates installed), and an internet connection during installation.
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/painthax painthax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| An eShop-install of Pixel Paint.
| MrNbaYoh
| [https://github.com/MrNbaYoh/painthax/releases/latest install]
|-
| style="background: salmon" | No
| [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh]
| From '''9.9.0-X''' up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of "The Legend of Zelda: Tri Force Heroes", and an Internet connection during installation. Unless you have "CFW", ctr-httpwn >=v1.2 with the included bosshaxx on a compatible system-version is also required. If installing via ctr-httpwn, you can't do so on >=v11.4. Note that the exploit itself was not fixed.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/ctpkpwn/releases Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.4.0-X'''.
| An eShop-install of Swapdoodle.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://github.com/ChampionLeake/RPwnG3 RPwnG3]
| From '''9.0.0-X'''(?) up to and including '''11.12.0-X'''.
| A Digital/Physical copy of "RPGMaker Fes Player/RPGMaker Fes" (USA/JPN 1.1.2 or lower ; EUR 1.1.4 or lower).
| [[User:ChampionLeake|ChampionLeake]]
| [https://github.com/ChampionLeake/RPwnG3/releases Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/luigoalma/nitpic3d nitpic3d]
| From '''9.6.0-X'''(?) up to and including '''11.13.0-X'''.
| A digital or physical of Picross 3D: Round 2
| Luigoalma and Kartik
| [https://github.com/luigoalma/nitpic3d Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/PabloMK7/kartdlphax kartdlphax]
| All system versions work.
| A digital or physical of Mario Kart 7 for the same region as both consoles
| PabloMK7
| [https://3ds.hacks.guide/installing-boot9strap-(kartdlphax) Install]
|}

==Exploits without Homebrew Launcher==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format, but could still prove useful by chaining to exploits with higher privileges.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: lime" | Yes
| [https://safecerthax.rocks safecerthax] (Safe Mode System Updater)
| (Old3DS (2DS) (XL)) ''' ALL '''

(New3DS (New2DS) (XL)) '''NOT SUPPORTED'''
|An O3DS or O2DS that can be booted into [[Recovery_Mode|Recovery Mode]] (hold L+R+Up+A at startup) & an internet connection.
|[[User:Nba_Yoh|MrNbaYoh]]
|[https://safecerthax.rocks/user-guide/ Install]
|-
| style="background: lime" | Yes (partially)
| [[bannerbomb3]] (System Settings)
| (USA / EUR / JPN) '''11.5.0''' to '''11.16.0'''

(KOR / TWN) '''(11.4.0)''' '''11.5.0''' to '''11.17.0'''

An exploit that uses a buffer overflow in a TWL export banner's title strings to gain rop execution.
|A USA, EUR, JPN, KOR, or TWN system with its movable.sed keyY extracted.
|[[User:zoogie|zoogie]]
|[[bannerbomb3|Install]]
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

[https://github.com/AuroraWright/Luma3DS Luma3DS], apart from providing signature patches for the installation and use of custom titles, includes the "Rosalina" system module, which among its features allows cleanly loading 3dsx applications as a native process with full ARM11 system permissions, by replacing an installed title's ExeFS and ExHeader during load time. It is currently the only option for running 3dsx applications on 11.4+ O3DSes; additionally, the *hax 2.x payload is incompatible with Rosalina and therefore so are homebrew applications requiring its target title system.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: salmon" | No, still usable pre-v11.4.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.3.0-X'''. This includes bosshaxx.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

11.17.0-50

2023-05-23T05:42:20Z

EvilFlight:

The Old3DS+New3DS 11.17.0-50 system update was released on May 23, 2023 (UTC). This Old3DS update was released for the following regions: USA, EUR, and JPN. This New3DS update was released for the following regions: USA, EUR, and JPN.

Security flaws fixed: yes.

==Change-log==
[https://en-americas-support.nintendo.com/app/answers/detail/a_id/667/kw/system%20update Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience.
*

==System Titles==
The following titles were updated: [[CVer]]/[[NVer]], [[System Settings]], [[eShop]], [[Home Menu]], 0004001B00018002 (Web browser Data).

==System Settings==
Mset can now display the full DSiWare export banner string length without crashing the stack. This fixes a nearly 4 year-old exploit, [https://github.com/zoogie/Bannerbomb3 Bannerbomb3].

==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2023-05-23_00-00-33&sys=ctr]
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2023-05-23_00-00-41&sys=ktr]

3DS System Flaws

2023-03-17T10:29:24Z

EvilFlight: APcert infoleak

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 [[3DS_Userland_Flaws|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_Services|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 [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! 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
| [[User:Derrek|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
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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?
| [[User:Yellows8|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|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 [[wikipedia:Pohlig-Hellman algorithm|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
| [[User:Myria|Myria]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|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
| [[User:Yellows8|Yellows8]]
|}

== Boot ROM ==
{| class="wikitable" border="1"
! 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 [[Flash_Filesystem|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
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[User:Yellows8|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 [[Flash_Filesystem|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
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|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(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|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 <nowiki>||</nowiki> 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
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]
|}

== ARM9 software ==

=== arm9loader ===
{| class="wikitable" border="1"
|-
! 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
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|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
| [[User:Yellows8|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-36|11.3.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|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 [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|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-6|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-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|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 [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| arm9loaderhax: Missing verification block for the 9.6 keys
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 [[Savegames#6.0.0-11_Savegame_keyY|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 [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| [[11.3.0-36|11.3.0-X]]
| March 2015
|
| [[User:Plutooo|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-36|11.3.0-X]]
| Sometime in 2015
|
| [[User:Plutooo|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-22|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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! 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-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|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-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|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 [[AES|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-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|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-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
|-
| safecerthax
| O3DS & O2DS SAFE_FIRM is still vulnerable to the PXIAM:ImportCertificates flaw fixed in [[5.0.0-11]] and to SSLoth fixed in [[11.14.0-46]]. It makes it possible to spoof the official NUS update server and remotely trigger the vulnerability in SAFE_FIRM.
| Remote Arm9 code execution in O3DS/O2DS SAFE_FIRM
| None
| [[11.14.0-46|11.14.0-X]]
| 2020
| December 18, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| 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 [http://dsibrew.org/wiki/NDS_Format 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-41|11.8.0-X]]
| [[11.8.0-41|11.8.0-X]]
|
| August 11, 2018
| smea
|-
| agbhax
| This is the same issue as twlhax above. Legacy FIRMs share the same OS code (Arm9-side OS, Arm11 kernel), and therefore, the outdated AGB_FIRM can be tricked into executing the still vulnerable PrepareArm9ForTwl function.
| ARM9 code execution (whilst still in 3DS mode)
| None
| [[11.14.0-46|11.14.0-X]]
|
| December 17, 2020
| Everyone
|-
| 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-22|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-36|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-37|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-29|10.4.0-X]]
|
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|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-33|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-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|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-41|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-33|11.8.0]]
| [[11.8.0-33|11.8.0]]
| ?
| Wiki: August 5, 2018
| Everyone
|-
| TWL_FIRM cmd-9 unchecked offset
| In [[1.0.0-0|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-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.
| ARM9 code execution
| [[2.0.0-2|2.0.0-X]]
| [[2.0.0-2|2.0.0-X]]
| January 2018
| Wiki: August 5, 2018
| [[User:Riley|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-33|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-24|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-24|9.6.0-X]]
| March 2015
| August 12, 2018
| [[User:Yellows8|Yellows8]], [[User:Myria|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:

<pre>...
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.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|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-36|11.3.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| This requires access to the [[Process_Services|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-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|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 [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|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-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|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
|
| [[User:Yellows8|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
|
| [[User:Yellows8|Yellows8]]
|-
| seedminer: movable.sed keyY vulnerable to brute-force
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|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-11|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-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|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|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]]:ImportCertificates (See also [[Application_Manager_Services|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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|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|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]]. This leaves the [[OTP Registers|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-5|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 [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|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 Registers|OTP]] area.
Decrypting New3DS sector 0x96 keyblock.
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! 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|svcUnbindInterrupt]] double free when irqId = 15
| svcBindInterrupt and svcUnbindInterrupt give special treatment to irqId 15 (FIQ helper): the access control list is bypassed and the provided KInterruptEvent (event or semaphore, via handle) is stored inside a singleton static object after having its refcount increased by 1.

svcUnbindInterrupt assumes that the user-provided handle is what is stored in the singleton and will decref the user-provided KInterruptEvent twice, causing a use-after-free if the attacker didn't actually provide an handle to the same event or semaphore.

This was "fixed" on [[11.14.0-46|11.14.0-X]] by preventing irqId 15 to be bound on retail units altogether (in both functions).
| Arm11 kernel code execution
| [[11.14.0-46|11.14.0-X]] (only on retail units)
| [[11.14.0-46|11.14.0-X]]
| 2019
| [[User:TuxSH|TuxSH]], maybe others
|-
| [[SVC|svcKernelSetState]] op=3 could map the NULL page
| svcKernelSetState op=3 param1=1 maps the firmlaunch parameters page to the user-specified VA.

It had previously no check, allowing the attacker to map data at VA 0.

Starting from [[11.14.0-46|11.14.0-X]], the VA must be in the standard 0x10000000-0x14000000 address range.
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
| [[11.14.0-46|11.14.0-X]]
| [[11.14.0-46|11.14.0-X]]
| 2019
| [[User:TuxSH|TuxSH]]
|-
| [[SVC|svcMapProcessMemory]] can map the NULL page
| svcMapProcessMemory's destination VA is unchecked.

By passing a big enough "size" parameter, an attacker can map chunks of data at VA 0 in the destination (caller) process.
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
| None
| [[11.14.0-46|11.14.0-X]]
| 2020
| [[User:TuxSH|TuxSH]]
|-
| Resource limit use-after-free
| When assigning a KResourceLimit to a KProcess, the reslimit's refcounter doesn't get incremented. This essentially means all KResourceLimit get freed if pm gets somehow terminated.

It turns out it is possible to ask pm (via ns:s or pm:app) to terminate itself along all other KIPs simply by passing TID 0004000100001000.

Calling [[SVC|svcGetResourceLimit]] afterwards triggers a use-after-free. This is rather difficult to exploit, however: there is one slot left in the reslimit slabheap. An attacker either has to map the NULL page as R(W)X (svcControlProcessMemory vuln fixed on [[11.8.0-41|11.8.0-X]]), or use one of the map-null exploits above while having access to svcCreateResourceLimit (with the only one that is easy enough to use in that context having been fixed on [[11.14.0-46|11.14.0-X]], anyway).
| Arm11 kernel code execution
| None (although near impossible to exploit on [[11.14.0-46|11.14.0-X]])
| [[11.14.0-46|11.14.0-X]]
| 2020
| [[User:TuxSH|TuxSH]]
|-
| [[SVC|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-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|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-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|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-36|11.3.0-X]]
| [[11.3.0-36|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-36|11.3.0-X]]
| November 26, 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| November 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| 2012
| Everyone
|-
| [[SVC|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-33|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 [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|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 [[SVC|SVCs]] access table at all.

Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|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_API|services]], ControlMemory on any given mem-region.
| None
| [[11.3.0-36|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-35|11.2.0-X]]
| [[11.2.0-35|11.2.0-X]]
| 2016
| nedwill, [[User:Derrek|derrek]]
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|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-36|11.3.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
|
| [[User:Derrek|derrek]], aliaspider
|-
| memchunkhax2
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|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-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
|
| [[User:Derrek|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|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-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| AffinityMask/processorid validation
| With [[10.0.0-27|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-27|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-27|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-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|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-21|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|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|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-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|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]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|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 <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|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
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|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
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[Services|"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
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|-
| Useless [[SM]] off-by-one write
| 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 <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|-
| smpwn
| When registering a new service (or "port"), no bound checks are done on the service table. One can simply call RegisterPort repeatedly to overflow that table: it will overflow into the command replay structure.

Combined with a other minor bugs in the sysmodule, it is possible to take over [[SM]] with this nevertheless difficult-to-exploit vulnerability.
| Code execution under [[SM]], etc.
| [[11.16.0-48]]
| [[11.14.0-46]]
| July 2017
| [[User:TuxSH|TuxSH]] (independently), presumably ichfly before
|-
| PXI cmdbuf buffer overrun
| Like its Arm9 counterpart, before version [[5.0.0-11|5.0.0-X]], the PXI system module did not check the command sizes. This makes it possible to get ROP under the PXI sysmodule from a pwned Process9.
safecerthax uses it to takeover the Arm11 processor after directly getting remote code execution on the Arm9 side. Though, is useless in classic Arm11 -> Arm9 chains.
| ROP under [[PXI_Services|PXI]]
| probably [[5.0.0-11|5.0.0-X]]
| [[11.14.0-46]]
|
| Everyone
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CSND_Services|CSND]] sysmodule crash due to out of bounds parameters.
| The CSND command [[CSND:PlaySoundDirectly|PlaySoundDirectly (0x00040080)]] takes a channel ID as the first parameter. Any value outside the range [0-3] makes the system module become unstable or crash due to an out of bounds memory read.
| Out of bounds memory read, probably not exploitable. More research needed.
| None
| [[11.14.0-46]]
| January 2021
| January 22, 2021
| [[User:PabloMK7|PabloMK7]]

|-
| SSLoth: [[SSL_Services|SSL]] sysmodule improper certificate verification
| Initially, the SSL sysmodule missed the R_VERIFY_RES_SIGNATURE entry in the "resource list" provided to the RSA BSAFE library. Consequently, it did not check signatures when validating certificate chains.
| Forge fake certificates, spoof official servers and perform MitM attacks on SSL/TLS connections.
| [[11.14.0-46]]
| [[11.14.0-46]]
| 2020
| December 18, 2020
| [[User:Nba_Yoh|MrNbaYoh]], shutterbug2000 (independently)

|-
| [[CECD_Services|CECD:ndm]] SetNZoneMacFilter (cmd8) stack smashing
| The length of the mac filter is not checked before being copied to a fixed-size buffer on stack.
| ROP under [[CECD_Services|CECD]] sysmodule
| None
| [[11.13.0-45]]
| 2020
| July 20, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[CECD_Services|CECD]] message box access
| CECD allows any process to write to any message box, thus allowing to write Streetpass data to the message box of any title.
| Install exploit for any title having a vulnerability in Streetpass data parsers (see CTRSDK Streetpass parser vulnerability).
| None
| None
| ?
| June 1, 2020
| Everyone?
|-
| [[CECD_Services|CECD]] packet type 0x32/0x34 stack-smashing
| When parsing Streetpass packets of type 0x32 and 0x34, CECD copies a list without checking the number of entries. The packet length is limited to 0x400 bytes, which is not enough to reach the end of the stack frame and overwrite the return address. However, the buffer located just next to the packet buffer is actually filled with data sent just before, hence actually allowing to overwrite the whole stack frame with conrolled data.
| RCE under [[CECD_Services|CECD]]
| [[11.12.0-44]]
| [[11.12.0-44]]
| Summer 2019
| June 1, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[CECD_Services|CECD]] TMP files parser multiple vulnerabilities
| When parsing "TMP_XXX" files, CECD does not check the number of messages contained in the file. This allows to overflow the array of message pointers and message sizes on the stack. Pointers aren't controlled and sizes are limited (one cannot send gigabytes of data...), yet the last message size can be an arbitrary value (the current message pointer goes outside the file buffer and the parsing loop is broken). This allows to overwrite a pointer to a lock object on the stack and decrement an arbitrary value in memory. One can change the TMP file parsing mode to have CECD trying to free all the message buffers after parsing the next TMP file. The parsing mode is usually restored when parsing a new TMP file, but an invalid TMP file allows to make a function returns an error before the mode is restored , the return value is not checked and the parser consider the file valid. The message pointers and sizes arrays are not updated though, this is not a problem since the previous TMP file buffer is reused for the new TMP file in memory. Thus the message pointers actually points to controlled data. This allows to get a bunch of fake heap chunk freed, thus a bunch of unsafe unlink arbitrary writes.
| RCE under [[CECD_Services|CECD]]
| [[11.12.0-44]]
| [[11.12.0-44]]
| Summer 2019
| June 1, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[Config_Services|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
| [[User:Nba_Yoh|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
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|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
| [[User:Yellows8|Yellows8]]
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|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
| [[User:Yellows8|Yellows8]]
|-
| AM module APcert infoleak via 00000000.ctx files
| Just after a download title is purchased from the eShop, the .ctx is in an initialized state of all FFs past the header. During download, the FF area is filled with the console APcert. Thus, it is possible to create a xorpad from the initial state and use it to decrypt the APcert filled state.
| APcert contains the deviceID, which can beneficial in decrypting the movable.sed (since deviceID is mathmatically related to the LFCS).
| None
| [[11.16.0-49]]
| August, 2022
| March 17, 2023
| zoogie
|-
| [[MVD_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|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-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|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-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|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 [[10.6.0-31|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|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|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 [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| None
| [[11.13.0-45|11.13.0-X]]
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|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) [[#Process9|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-27|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)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
| Code execution under spi sysmodule; access to [[CONFIG11_Registers|CFG11_GPUPROT]] and ultimately kernel code execution.
| None
| [[11.14.0-46]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|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?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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?
|
| [[User:Yellows8|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 [[RO_Services|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-36|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-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|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 [[SVC|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, [[User:Plutooo|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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CECD_Services|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_Services|CECD]]
| [[11.12.0-44]]
|
| 2019
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[NWM_Services|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 [[NWM_Services|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]]
|}

PTM:GetBatteryLevel

2023-01-26T05:34:37Z

EvilFlight: Clarify battery state output and behavior

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00070000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| u8 output
|}

=Output Values=

These values are only reliable when [[PTM:GetAdapterState|no external power is connected]].

{| class="wikitable" border="1"
|-
! Value
! State of charge
|-
| 5
| 100~61% (4 blue bars)
|-
| 4
| 60~31% (3 blue bars)
|-
| 3
| 30~11% (2 blue bars)
|-
| 2
| 10~6% (1 red bar)
|-
| 1
| 5~1% (1 red bar & [[PTMSYSM:SetBatteryEmptyLEDPattern|notification LED]] both blink)
|-
| 0
| 0% (system shutdown)
|}

System Settings

2023-01-18T03:00:02Z

EvilFlight: System Settings svcBreak

'''System Settings''' allows you to manage various settings, use [[System Transfer]], and use Data Management.

All applications(CTR/TWL) launched by System Settings are launched via [[NS|APT:PrepareToDoApplicationJump/APT:DoApplicationJump]], such as DS INTERNET and [[System Transfer]].

== Accessible services ==

{| class="wikitable" border="1"
|-
! Service
! Last seen on version
|-
| [[Filesystem_services#Filesystem_service_.22fs:USER.22|fs:USER]]
| [[9.0.0-20|v8202]]
|-
| [[GSP_Services|gsp:Gpu]]
| [[9.0.0-20|v8202]]
|-
| [[NDM_Services|ndm:u]]
| [[9.0.0-20|v8202]]
|-
| [[NS#.22APT:A.22_Service|APT:A]]
| [[9.0.0-20|v8202]]
|-
| [[AC_Services|ac:i]]
| [[9.0.0-20|v8202]]
|-
| [[ACT_Services|act:a]]
| [[9.0.0-20|v8202]]
|-
| [[Application_Manager_Services#Application_Manager_services|am:sys]]
| [[9.0.0-20|v8202]]
|-
| [[BOSS_Services|boss:P]]
| [[9.0.0-20|v8202]]
|-
| [[Camera_Services#cam:s_.28PORT_CAL.29|cam:s]]
| [[9.0.0-20|v8202]]
|-
| [[CECD_Services|cecd:s]]
| [[9.0.0-20|v8202]]
|-
| [[Config_Services#Config_NVRAM_service_.22cfg:nor.22|cfg:nor]]
| [[9.0.0-20|v8202]]
|-
| [[DSP_Services|dsp::DSP]]
| [[9.0.0-20|v8202]]
|-
| [[Friend_Services|frd:a]]
| [[9.0.0-20|v8202]]
|-
| [[GSP_Services|gsp::Lcd]]
| [[9.0.0-20|v8202]]
|-
| [[HTTP_Services|http:C]]
| [[9.0.0-20|v8202]]
|-
| [[MIC_Services|mic:u]]
| [[9.0.0-20|v8202]]
|-
| [[News_Services#News_service_.22news:s.22|news:s]]
| [[9.0.0-20|v8202]]
|-
| [[NIM_Services#NIM_user_service_.22nim:u.22|nim:u]]
| [[9.0.0-20|v8202]]
|-
| [[NS#NS_Service_.22ns:s.22|ns:s]]
| [[9.0.0-20|v8202]]
|-
| [[NWM_Services#NWM_service_.22nwm::EXT.22|nwm::EXT]]
| [[9.0.0-20|v8202]]
|-
| [[NWM_Services#NWM_infrastructure_service_.22nwm::INF.22|nwm::INF]]
| [[9.0.0-20|v8202]]
|-
| [[NWM_Services#NWM_socket_service_.22nwm::SOC.22|nwm::SOC]]
| [[9.0.0-20|v8202]]
|-
| [[PTM_Services#GetSystemTime_PTM_Service_.22ptm:gets.22|ptm:gets]]
| [[9.0.0-20|v8202]]
|-
| [[PTM_Services#SysMenu_PTM_Service_.22ptm:sysm.22|ptm:sysm]]
| [[9.0.0-20|v8202]]
|-
| [[Socket_Services#Socket_privileged_service_.22soc:P.22|soc:P]]
| [[9.0.0-20|v8202]]
|-
| [[Socket_Services#Socket_user_service_.22soc:U.22|soc:U]]
| [[9.0.0-20|v8202]]
|-
| [[SSL_Services|ssl:C]]
| [[9.0.0-20|v8202]]
|-
| [[Camera_Services#y2r:u|y2r:u]]
| [[9.0.0-20|v8202]]
|-
| [[QTM_Services#QTM_system_service_.22qtm:s.22|qtm:s]]
| [[9.0.0-20|v8202]]
|-
| [[Config_Services#Config_service_.22cfg:i.22|cfg:i]]
| [[9.0.0-20|v8202]]
|-
| [[HID_Services#HID_service_.22hid:SPVR.22|hid:SPVR]]
| [[9.0.0-20|v8202]]
|}

== Data Management ==

=== 3DS ===

Here you can manage 3DS extra data, and 3DSWare/"Software".

When managing 3DS Software installed to the SD Card, the [[Title Database|title.db]] is read by the core receiving [[Application Manager Services PXI|AM]] commands. From the title.db file, AM gets a list of installed titles, title sizes and the name of the ".cmd" file for each title, which is used to check the authenticity of the title data(product code, title version, and if an electronic manaual is used, is also kept for each title, in the title.db, but won't be used by the Data Management Utility). For each title listed, it checks if the title is authentic(via the .cmd file). If the title passes authentication, Data Management decrypts/reads the ICN data from the executable NCCH([[CXI]]) and displays it along with the archived title size. If a title doesn't pass authentication, a placeholder icon(light grey with a '?' in the center), name ('????????') and a size of zero are used. Deleting titles removes the title data from the title.db and import.db, and deletes the directory of the content.

Additionally, if a CTR-NAND or TWL-NAND installed title passes authentication, but has a fake-signed ticket, System Settings will call "[[SVC|svcBreak]]" upon entering Data Management -> 3DS | DSiWare. Barring patched RSA sig checks, this will prevent a user from viewing the 3DS and/or DSiWare Data Management menu depending on which NAND(s) the offending title(s) is installed. This phenomenon has been known to lock users out of executing widely used exploits like [https://github.com/zoogie/Bannerbomb3 Bannerbomb3], which need access to Data Management to trigger.

=== DSiWare ===

See [[DSiWare Exports]].

== System Format ==
Most of the System Format is done with [[FS:InitializeCtrFileSystem]]. This command updates the high u64 of the keyY stored in [[Nand/private/movable.sed|movable.sed]]. Since this keyY was updated, the data stored on [[SD_Filesystem|SD]] card(sdmc/Nintendo 3DS/<ID0>/<ID1>) and the data under [[Flash_Filesystem|nand/data/<ID0>]] is rendered useless, since that data used the old keyY. Since that data is no longer usable, the system then deletes the two above SD/NAND directories.

When you first enter the System Format menu, it will check if a NNID is linked. If there's a linked-NNID, it will then display: "Are you ready to connect to the Internet to check whether data can be formatted"? Continuing will only result in connecting to wifi for checking in with Nintendo's servers, which may fail if the console is banned. Once that's done it will continue with the usual system-format messages; proceeding will result in the NNID cookie, potentially still present on NAND backups or multiboot scenarios, being invalidated until the next sign-in (at which point even old sessions will be valid again).

== System Updater ==
The system updater title is identical to the regular system settings, except only system update is accessible with this. On dev units, this title can only be launched under certain conditions.

On retail units, this title is accessible in scenarios where you have to update via the Internet to use certain 3DS software other than the home menu. i.e. using the eShop, on a system version less than the current one. When one selects "Cancel" from here on retail, the system will shutdown. [[NS]] launches SAFE_MODE_FIRM for running this title, when the [[Configuration_Memory|UPDATEFLAG]] is set during system boot.

==Exiting System Settings==
Upon exit, the system reboots instead of simply returning to home menu.

== Parental Controls Reset ==
The following refers to the functionality which generates the Parental Controls "Master Key".

{| class="wikitable" border="1"
|-
! System version, for the mset title
! Parental controls reset functionality version
! Inquiry number length
! Notes
|-
| [[1.0.0-0|1.0.0-X]] - [[6.3.0-12|6.3.0-X]]
| v0
| 8
| Mostly inherited from the Wii/DSi algorithm which used CRC-32 (0xEDB88320) with custom XOR-out (0xAAAA). 0x14C1 was added to produce the final result.

For the 3DS algorithm, only constants were changed: the polynomial was changed to 0xEDBA6320 and the addition constant became 0x1657.

The input to either function is an ASCII string of the format "%02u%02u%04u" where the parameters are month, day, and low 4 digits of the inquiry number. The low 5 decimal digits from the output u32 are then used for the master key.

Because of the date being used in the algorithm, this results in the master key only being valid on a particular day, though this is trivially defeated by setting the system time to the correct date that the key was generated on.

This had a minor refactor in [[6.0.0-11|6.0.0-X]] but is functionally identical.
|-
| [[7.0.0-13|7.0.0-X]] - [[7.1.0-16|7.1.0-X]]
| v1
| 10
| Introduced a new scheme using HMAC-SHA-256. The HMAC key is loaded from mset .rodata, and differs between regions.

The inquiry number was bumped from 8 digits to 10 digits, but the same function is used to generate the digits as in v0 (derived from MAC address).

All digits of the inquiry number are now actually used in the master key derivation function, as the string format is now "%02u%02u%010u" (month, day, inquiry number). This buffer is hashed (as above), and a little-endian word is read from the start of the output hash. The low 5 decimal digits of this word are used as the master key.
|-
| [[7.2.0-17|7.2.0-X]] - current
| v2
| 10
| Extension of v1 featuring a number of changes which serve to obscure the HMAC key used.

The HMAC key is now stored in a separate file stored in the CVer RomFS, called [[CVer#masterkey.bin|masterkey.bin]]. This is used to update the key independently of the mset title. In order to make this possible, a scheme was devised to encode the required key within the inquiry number - the first digit denotes region, and the next two digits represent the key version. These values match up with values stored in the masterkey.bin header. For compatibility with v1 (as inquiry number length did not change), the version values begin at 10 - when parsing an inquiry number, a "version" of less than 10 should be handled as algorithm v1.

The HMAC key is now also encrypted in masterkey.bin. This uses AES-128-CTR using a (normal) key in mset .rodata (which differs between regions), with the initial counter value also stored in masterkey.bin.

At some point, Nintendo chose to "abandon" the original JPN region ID (0), and moved to region ID 9 instead (which usually doesn't exist). It is unknown why they made this change, as the AES key used for both of these IDs is the same.
|}

== ExtData ==
The ExtData [[Extdata#Filesystem|File System]] for System Settings is as follows:

root
├── icon
├── boss
└── user
├── Backup.dat
└── MsetExt.dat

{| class="wikitable" border="1"
|-
! File
! Details
! Size
! FW Introduced
! Plaintext
|-
| icon
| Stubbed. Always image 00000002.
| 0x4 Bytes
| n/a
|
|-
| MsetExt.dat
| [[DSiWare Exports]] Management
| 0x960 Bytes
| [[2.0.0-2]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/SystemSettingsExtdata/MsetExt.dat Download]
|-
| Backup.dat
| [[SD Savedata Backups]] Management
| 0xf5a0 Bytes
| [[6.0.0-11]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/SystemSettingsExtdata/Backup.dat Download]
|}

=== MsetExt.dat ===
This keeps a record for the DSiWare Exports for a maximum of 300 exports. Each record is in the format:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0
| 4
| Game Code in Little Endian
|-
| 0x4
| 4
| Reserved
|}

All unused entries are filled with "0xff".

=== Backup.dat ===
This keeps a record for the 30 save data backup slots for [[SD Savedata Backups]]. Each entry corresponds to an individual backup slot.

Entry:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 8
| Reserved
|-
| 0x8
| 0x800 (0x80*16)
| 16 UTF-16 Title Strings
|-
| 0x808
| 8
| Title ID
|-
| 0x810
| 8
| Unknown
|-
| 0x818
| 8
| Total Save Data Size
|-
| 0x820
| 0x10
| Reserved
|}

== Launch parameters ==
System Settings can start at specific menus when certain parameters are given.

<nowiki>*</nowiki> - returns to settings menu instead of rebooting

{| class="wikitable" border="1"
|-
! Value
! Action
|-
| 0x01
| Initial setup (system not actually formatted, music plays earlier)
|-
| 0x10
| Internet Settings -> Connection Settings
|-
| 0x11
| Internet Settings -> Other Information
|-
| 0x6e
| Internet Settings -> Connection Settings
|-
| 0x6f
| Parental Controls
|-
| 0x70
| Parental Controls birthday entry
|-
| 0x71
| Data Management
|-
| 0x72
| 3DS Software Management
|-
| 0x73
| 3DS Extra Data Management
|-
| 0x74
| DSiWare Management
|-
| 0x75
| StreetPass Management
|-
| 0x76
| Internet Settings*
|-
| 0x77
| Other Settings, second-to-last page*
|-
| 0x78
| Touch Screen calibration
|-
| 0x79
| Circle Pad calibration
|-
| 0x7a
| System Update
|-
| 0x7b
| System Update
|-
| 0x7c
| Format System Memory*
|}

User:Toirrsam

2022-12-15T09:47:58Z

EvilFlight: spam

User:Rakackper

2022-12-15T09:47:34Z

EvilFlight: spam

User:Serperbel

2022-12-15T09:47:02Z

EvilFlight: spam

Nintendo 3DS Camera

2022-11-19T22:50:39Z

EvilFlight: Clarify Unique ID

== Overview ==
[[File:Nintendo 3DS Camera scnshot.png|thumb|right|Nintendo 3DS Camera Screenshot (pre 4.0-7)]]
This application allows the user to take/view photos and, since the 4.0.0-7 update, videos up to 10 minutes.

The resolution of the top-screen on the 3DS is 400x240.

== How to convert and split video.ext into 10 minute pieces ==
<code>
ffmpeg -i video.ext -ss 0 -t 600 -y -r 24 -vsync 1 -vcodec mjpeg -qscale 1 -acodec adpcm_ima_wav -async 1 -ac 2 /DCIM/xxxNINxxx/HNI_%04d.AVI
</code>

== How to convert 2D Video for 3DS ==
<code>
ffmpeg -i video.ext -r 24 -vsync 1 -vcodec mjpeg -qscale 1 -acodec adpcm_ima_wav -async 1 -ac 2 -vf scale=min(400\\,240*a):-1,pad=400:240:abs(ow-iw)/2:abs(oh-ih)/2 /DCIM/xxxNINxxx/HNI_nnnn.AVI
</code>

== How to convert 3D Video for 3DS ==

<code>
ffmpeg -y -i "video.mp4" -s 960x240 -aspect 2:1 -r 20 -vcodec mjpeg -qscale 1 -vf crop=480:240:0:0 -acodec libmp3lame -ar 41000 -ab 96k -ac 2 "left.avi"
ffmpeg -y -i "video.mp4" -s 960x240 -aspect 2:1 -r 20 -vcodec mjpeg -qscale 1 -vf crop=480:240:480:0 -an "right.avi"

ffmpeg -y -i "left.avi" -i "right.avi" -vcodec copy -acodec adpcm_ima_wav -ac 2 -vcodec copy -map 0:0 -map 0:1 -map 1:0 "VID_0001.AVI"
</code>

First two lines generate left and right files video, the last line generate the 3D video for the 3DS

Put the file in DCIM\xxxNINxx
== Image Requirements ==

The photo gallery implements various restrictions on its images:

* A 4:3 image must have an image resolution of at least 160x120 to appear in the photo gallery. (Minimum image resolutions for other aspect ratios are currently unknown, as are maximum image resolutions for any aspect ratio.)
* Additionally, certain features are only available for valid Nintendo 3DS photographs:
** The left-eye image's Exif metadata must specify a camera make of <code>Nintendo</code>, a camera model of <code>Nintendo 3DS</code>, and a software name of <code>00204</code>.
** The zoom feature is only available when viewing any image with an aspect ratio which is no more horizontally dominant than 4:3. For example, a 480x480 image will be zoomable due to its aspect ratio, but a 480x288 image will not be zoomable because its 5:3 aspect ratio makes the image too wide relative to its height. All zoomable images are initially zoomed in when viewed in the photo gallery.
** Each 3D image features a faded black border and can be manipulated with the 3D Focus slider, but only if the image is at least 480 pixels wide and contains a valid 3DS Camera maker note in the left-eye image's Exif metadata.

== Maker Note ==

Every Nintendo 3DS Camera photo contains a maker note in its Exif metadata. 3D images contain two maker notes - one for the left-eye image, and one for the right - but only the left-eye image's maker note is used. Two maker notes within the same 3D image may be identical to one another, but they are not guaranteed to be. The maker note of a 2D JPEG image seems to always contain an identical maker note to one of its respective 3D image's individual images, but which one it is identical to is not consistent.

The maker note consists of two custom TIFF fields that both have a type of <code>UNDEFINED</code>. Regardless of the Exif metadata's endianness, which the TIFF fields must match, the fields' contents are encoded in little endian.

The first field, which is identified by tag <code>0x1100</code>, is 80 bytes long. The meanings of its contents are not known, but the first byte Seems to always have a value of 1. The remaining bytes always seem to have values of zero, unless the photo used a sepia filter, in which case bytes <code>0x8</code>-<code>0x1a</code> (inclusive) are set. This field can be excluded from the maker note without invalidating the 3DS Camera maker note.

The second field uses tag <code>0x1101</code>. It is 64 bytes long, although its length can be reduced to as few as 21 bytes without issue.
{| class="wikitable" border="1"
|-
! Address
! Size
! Type
! Description
|-
| 0x0
| 0x4
| char[4]
| Spells "3DS1" in ASCII. Required.
|-
| 0x4
| 0x4
| unknown
| Possibly a version number. Seems to always be 1 or 2.
|-
| 0x8
| 0x4
| u32
| Photo timestamp
|-
| 0xc
| 0x4
| unknown
| Unknown. Seems to always be 0.
|-
| 0x10
| 0x4
| unknown
| Unknown. Seems to always be 516.
|-
| 0x14
| 0x1
| u8
| Unknown. Seems to always be 20, but any non-zero value seems acceptable. Required.
|-
| 0x15
| 0x3
| unknown
| Unknown. Seems to always be 0.
|-
| 0x18
| 0x4
| u32
| This is the lower word of [[Cfg:GenHashConsoleUnique]].
|-
| 0x1c
| 0xc
| unknown
| Unknown. Seems to always be 0.
|-
| 0x28
| 0x4
| f32
| Left translation
|-
| 0x2c
| 0x4
| unknown
| Unknown. Seems to always be 0.
|-
| 0x30
| 0x4
| u32
| Photo filter(s)
|-
| 0x34
| 0xc
| unknown
| Unknown. Seems to always be 0.
|}

The photo timestamp is represented by the number of seconds that had passed since the beginning of the year 2000 in the photographer's 3DS's time zone.

The left translation number indicates how many pixels to move the left-eye image to the left before scaling it to fit the entire image on-screen without stretching it. It inversely affects the positions of the right-eye image and the 3D Focus slider. The 3DS Camera clamps this value to prevent the image from moving off-screen. This value is zero in 2D photos, though 3D photos can use a value of zero as well.

Take, for example, a 640x480 3DS photograph. The 3DS Camera will scale the photo down to 50% of its original size to fit the top 3DS screen, which is 240 pixels tall. This leaves a gap of 40 pixels on both the left and right sides of the image. If these gaps were resized to match the photo's original scale, which is twice as large as its on-screen scale, the gaps would be 80 pixels wide. As such, the left translation value can effectively range from +80.0, which will move the image to the left edge of the screen, to -80.0, which will move it to the right edge. Despite this range working as expected for an image of this size, the 3DS Camera's image gallery does not allow the user to move any photo to the very edge of the screen. For the example above, the maximum absolute value seems to be somewhere within the mid-to-low 50s.

The left translation value can be changed by moving the 3D Focus slider while zoomed in, or by readjusting the photo's position while zoomed out. This will update the left translation value held in the left-eye image's maker note as well.

The photo filter(s) value seems to specify information about photo filters that were applied to the image. Some filters seem to use the same values. When filters are not present, this value is 0.

Serials

2022-04-02T06:04:10Z

EvilFlight: 2020s cartridge serial year format

This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).

== Console Serial Numbers ==

A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.

The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)

After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.

Example: CW404567772

The non-check digits are 40456777. Separating into odd and even groups, we get the following:

Odds: 4 + 4 + 6 + 7 = 21
Evens: 0 + 5 + 7 + 7 = 19

Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.

The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.

The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.

{| class="wikitable"
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)
|-
| ''DSi'' || T || V
|-
| ''DSi XL/LL'' || W || D
|-
| ''Nintendo Zone Box'' || Z || ''N/A''
|-
| ''Wii U'' || F || ''unknown''
|-
| ''Wii U gamepad'' || J || J
|-
| 3DS || C || E
|-
| 3DS XL/LL || S || R
|-
| 2DS || A || P
|-
| New 3DS || Y || Y
|-
| New 3DS XL/LL || Q || Q
|-
| New 2DS XL/LL || N || N
|}

Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.

Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).

{| class="wikitable"
! Sales Region !! Region Lock !! Region Suffix
|-
| Japan || Japan || JF, JH, JM
|-
| North America || North America || W
|-
| Middle East / Southeast Asia || North America || S
|-
| Europe || Europe || EE, EF, EH, EM
|-
| Australia || Europe || AH, AG
|-
| South Korea || Korea || KF, KH, KM
|-
| China (iQue) || China || CF, CH, CM
|}

== Console Models ==

{| class="wikitable"
! Device !! Product Code
|-
| ''DS'' || NTR
|-
| ''DS lite'' || USG
|-
| ''DSi'' || TWL
|-
| ''DSi XL/LL'' || UTL
|-
| ''Wii U'' || WUP
|-
| 3DS || CTR
|-
| 3DS XL/LL || SPR
|-
| 2DS || FTR
|-
| [[New 3DS]] || KTR
|-
| [[New 3DS]] XL/LL || RED
|-
| New 2DS XL/LL || JAN
|}

The DS had the product code NTR (short for Nitro), so we see the TR is recurring.

== Title ID and Unique ID ==
''see [[Titles]]''

== NCCH Product Code ==

This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.

The product code is located in a [[NCCH]]'s header (not its ExHeader).

The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".

So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".

A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:

[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]

{| class="wikitable"
! Category letter !! Description
|-
| P || Cartridge software, or downloadable versions of them.
|-
| N || Digital-only releases, including [[Title list|system applications and applets]].
|-
| M || [[DLC]]
|-
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.
|-
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.
|}

The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].

See the next chapter for explanation of the other components of the Product Code.

== Physical Serial ==
[Product][Retail/Demo]-[Platform]-[Type][Game ID][Region]-[Label Region]

{| class="wikitable"
! Field !! Length !! Description !! colspan=2 | Values
|-
|-align=center
| rowspan="6" | Product
| rowspan="6" | 2
| rowspan="6" | Product type
|-
| LN || Cartridge
|-
| MA || Instruction manual
|-
| TS || Game box
|-
| FA || Leaflet
|-
| MK || Quick-start Guide
|-align=center
| rowspan="3" | Retail/Demo
| rowspan="3" | 1
| rowspan="3" |
|-
| A || Retail
|-
| Z || Demo
|-align=center
| rowspan="3" | CTR/KTR
| rowspan="3" | 3
| rowspan="3" | Platform
|-
| CTR || 3DS
|-
| KTR || New 3DS
|-align=center
| rowspan="11" | Type
| rowspan="11" | 1
| rowspan="11" |
|-
| A || retail
|-
| B || retail
|-
| C || used for N3DS exclusive retail and default 'CTAP'
|-
| E || used for card 2 type retail cartridges
|-
| H || used for built in applications like [[Mii Maker]]
|-
| J || normal eShop Title
|-
| K || normal eShop Title?
|-
| S || 3D Classics
|-
| P || used with GBA eShop titles
|-
| T || used with NES eShop titles
|-align=center
| Identifier
| 2
| colspan=3 |Game ID (two alphanumeric characters)
|-align=center
| rowspan="10" | Region
| rowspan="10" | 1
| rowspan="10" |
|-
| E || English (US)
|-
| P || PAL (Europe/Australia)
|-
| J || Japanese (Japan)
|-
| K || Korean (Korea)
|-
| C || Chinese (China/Taiwan)
|-
| Y || Multiple regions
|-
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)
|-
| Z || Multiple regions
|-
| A || All (region-free)
|-
|-align=center
| rowspan="12" | Label Region
| rowspan="12" | 3
| rowspan="12" |
|-
| USA || United States
|-
| EUR || Europe
|-
| CAN || Canada (US version with additional French text added to box)
|-
| AUS || Australia
|-
| JPN || Japan
|-
| KOR || Korea
|-
| TWN || Taiwan/Hong Kong
|-
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")
|-
| CHN || China
|-
| UKV || United Kingdom ("United Kingdom version")
|-
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")
|}

=== Electronic Manuals ===

Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:

CTR-[P/N/T/U]-[Type][Game ID][Region]-[Region]-[Digit]

CTR-[Type][Game ID][Region]-[Region]-[Digit]

* P/N/T/U - Same as in product code structure
* [Type][Game ID][Region] - Same as in serial structure
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.

'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.

==Back of Card Serial==
AREPY10111 (example)

AAAABCDEEE 
'''A''' - Identifier (last 4 digits of product code) 
'''B''' - Production Month (numbers, then after Sep its X,Y,Z for Oct,Nov,Dec) 
'''C''' - Production Year (2010 + C)* 
'''D''' - Revision/Remaster Version (should match the main NCCH's Exheader Remaster Version) 
'''E''' - Production Run? (000-999)**

<nowiki>* </nowiki>Or (2020 + C), if produced in that decade. Example [https://www.youtube.com/watch?v=DcH8mK6yXj4 here] at the 2:10 mark. 
<nowiki>** </nowiki>European demo/kiosk carts have "08B" or "08H"

Friend code

2022-02-04T05:34:33Z

EvilFlight: Reverted Omgsteven3ds‎'s edits that completely broken the Friend Code table

This is a list of friend codes of different users.

Remember to [http://3dbrew.org/w/index.php?title=Friend_code&action=watch watch this article] if you wish to get notified when someone modifies the list.

{| class="wikitable" border="1"
|-
! width="20%" | User !! width="15%" | IrcNick !! width="20%" | Friend code !! width="10%" |Region !! width="30%" |Comment here !! Mii image
|-
|[[User:V10lator|V10lator]] || || 1049-5141-1277 || EUR (Germany) || Add me and write on 3DS Letterbox ||[[File:V10lator.png|120px]]
|-
|[[explosions]] || haxmaster123 || 4141-5323-9570 || USA || I play ironfall: invasion and smash ||
|-
|[[User:Brayton1234567]] || I don't know what this is || 0662-4312-7555 || USA || Add me, I added everyone else! ||
|-
|[[User:Thejsa|thejsa]] || thejsa / jsa_ || 5043-5145-7887 || EUR (UK, N3DS) || My body is ready - ready to Sm4sh, race on MK7 and write homebrew! ||
|-
|[[User:SynRxn|SynRxn]] || ||0962-9776-8195 ||USA ||Let's pwn the 3DS! ||[[File:SynRxn.JPG|120px]]
|-
| z2442 || || <nowiki>4554-0595-5890</nowiki> || USA || hack the 3ds yes! ||
|-
|[[User:ClassicToxin|ClassicToxin]] || || 1864-8732-8338 ||AUS ||Add me can/will probably play any game with you if you like ||
|-
|[[User:Allnewryan1|Allnewryan1]] || || 0001-4540-5587 || USA || Looking to help the devs, add me and send me a message when you find crashes ||
|-
| Crediar || || 2535-3625-3742 || Europe || None ||
|-
| [[User:Skyneo|Skyneo]] || Skyneo || 1950-8547-6804 || Europe (France) || Young beginner dev dreaming of making a Nintendo game. My hair is anarchy. || [[File:SkyneoMii.JPG|120px]]
|-
| Kazuma || || 2277-6646-9164 || Europe || None ||
|-
| SaltyPancakes || || 0044-2836-4738 || Europe || None ||
|-
| Inspectah || || 3909-7495-9525 || Europe || None ||
|-
| XanLoves || || 3995-6523-2805 || Europe || None ||
|-
| dillan || || 0173-1686-8946 || Europe || Currently devving garfieldcarthax, add me!||
|-
| dillan (2) || || 5086-4891-370|| Europe || dillan's| other 3ds, also for haxxing, add me!||
|-
| muhkuh2005 || || 2449-4689-9707 || Europe || Germanfag ||
|-
| RHOPKINS13 || || 4854-6450-1577 || USA || None || [[File:RHOPKINS13_Mii.JPG]]
|-
| fishuyo || || 2535-3630-0678 || USA || None ||
|-
| marcosxd || || 0216-0901-5448 || Mexico || Crediar add me please, I already added you :) ||
|-
| Mafril || || 5112-3460-1421 || USA || None || [[File:Mafril_Mii.JPG]]
|-
| Epicdude || ||0130-1922-3022 ||USA || None ||
|-
| David || ||3553-9962-0973 ||USA ||Add me ||
|-
| Muzer || || 3136-6762-5385 || Europe || I have added everyone on this list who has a valid friend code (David and marcosxd don't) - so please add me if you get the chance. || [[File:Muzer_Mii.jpg|120px]]
|-
|[[User:Schumi|Schumi]] || || 1934-1000-7068 || Germany (Europe) || add and write with me ;) ||
|-
|[[User:Rikku2000|Rikku2000]] || || EUR: 1461-6425-0347 JPN: 1375-8084-1845 || Germany || Write me on 3DS Letterbox ||[[File:Rikku2000_Mii.JPG|100px]]
|-
|[[User:Elisherer|Elisherer]] || elisherer ||0001-3489-0550 ||USA ||None ||[[File:Elisherer_Mii.JPG|120px]]
|-
|Liam87 || ||2664-2361-9358 ||England ||Add me please, i have added everyone on here, thank you ||
|-
|Luishane || ||1289-8459-2533 ||Venezuela ||Add me...thanks ||
|-
|Immortal_no1 || ||0516-7257-0011 ||UK ||Add me and PM me on gbatemp.net with yours or e-mail me on "immortal_no1@hotmail.com" ||
|-
|CrimsonΣ (CrimsonSigma) || ||5284-1673-1864 ||Brazil ||Add me ||
|-
|E-Chan || ||2062-9187-2394 ||Spain ||Add me please~! Im up for online gaming of any sorts and discussing the scene! ||
|-
|Lazymarek9614 || ||1590-4676-4678 ||Europe ||Online gaming SSF IV 3D, I try to add everyone here! ||
|-
|FireFly || ||4554-0352-3499 ||Europe || None ||
|-
|Hikari06 || ||5241-1966-6545 ||Europe || I added everyone, please add me :) ||[[File:HIKARI06MII.jpg|120px]]
|-
|UpSilon_Project || ||1848-1843-3651 ||France (Europe) || UpSilon from the UpSilon Project ||
|-
|CVosler || ||4554-0499-6731 ||USA || I added everyone. You can also email me your code after you add me "cvosler@hotmail.com" ||[[File:Chip.JPG|120px]]
|-
|[[User:CHR15x94|CHR15x94]] || ||0688-5814-3517 ||Canada (USA) || Feel free to add me. I'll add anyone. If you need to contact me, message me on 3DBrew, or through one of my contacts on my 3DBrew profile. ||[[File:CHR15x94_-_Mii.JPG|120px]]
|-
|[[User:DarkWork0|DarkWork0]] || ||1075-0737-9684 ||USA ||Add me and email me your friends code: darkwork0@gmail.com I'll add anyone who adds me! ||[[File:HNI_0006.JPG‎|120px]]
|-
|[[User:Aliak11|Aliak11]] || ||1160-9718-1643 ||USA ||Add me and email me your friends code: atthegulf@gmail.com ||
|-
|[[User:capt.danny|capt.danny]] || ||4339:2914:5427 ||USA||Added everyone. Email fcs to danny9ds@gmail.com ||
|-
||[[user:jordan|jordan]]|| ||0473-8413-4597||USA||added all.||
|-
|[[User:Stopwatch8|Stopwatch8]] || Stopwatch8 ||2449-4811-6942 ||USA || I have added everyone here. I would be happy if I were added as well! I just like to see what titles everyone plays. :) ||[[File:Stopwatch8.JPG|120px]]
|-
| [[User:mr_seeker|mr_seeker]] || ||3909-7860-3744 ||EUR ||Add me, find me, streetpass me! ||
|-
|[[User:missou|missou]] || missou ||1762-3951-0686 ||EUR || I have added everyone...and everyone can add me! ||[[File:MissouMii.JPG|120px]]
|-
|[[User:GuyInDogSuit|GuyInDogSuit]] || ||4957-2209-2798 ||USA || I have added everyone except David and marcosxd (invalid codes), and everyone can add me in return. ||[[File:GuyInDogSuit.jpg|120px]]
|-
|[[User:NintendoFan|NintendoFan]] || ||2492-4592-1206 ||USA ||None ||
|-
|[[User:Rllns05|Kresma]] || ||0190-1796-8987 ||USA ||Add me, I won't Bite. ||[[File:Rllns05.JPG|120px]]
|-
|[[User:Beefsloth|Beefsloth]] || ||3239-7434-0366 ||USA ||Add me, if nintendo hasn't banned us all already. ||
|-
|[[User:Light4wing]] || ||4871-8801-5208 ||KOR || Add and email your friend code(s) => ruckus71472@outlook.com ||
|-
|[[User:MoneyBags|MoneyBasket]] || ||4485-5249-2780 ||USA || i add you, you add me.||
|-
|[[User:NoFace]] || ||2853-1277-2658 ||EUR || add me if you need a friend.||[[File:HNI 0053.JPG|120px]]

User:EmilieNorthmore

2021-08-12T00:37:48Z

EvilFlight: spam link

I'm Mazie and was born on 1 July 1983. My hobbies are Reading and Jewelry making.

Management Efek Dalam Permainan Poker Online

2021-08-12T00:36:10Z

EvilFlight: spam

Sikap Yang Wajib Dicegah Dalam Taruhan Judi Bola Online

2021-08-12T00:35:26Z

EvilFlight: spam

Title list

2020-10-12T02:26:27Z

EvilFlight:

==== CTR Title List Notes ====
Reports/title-lists [https://yls8.mtheall.com/ninupdates/reports.php here] are automatically obtained from the system update SOAP.

== CTR System Titles ==
{| class="wikitable sortable" border="1"
|-
! Category Bit Mask
! Title Type
! Internal Description
! Bit Mask(s)
|-
| 0x0010
| Application
| SYSTEM_APPLICATION
| Normal<nowiki> | </nowiki>System
|-
| 0x001B
| System Data Archives
| SYSTEM_CONTENT
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System
|-
| 0x009B
| Shared Data Archives
| SHARED_CONTENT
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>NotRequireRightForMount
|-
| 0x00DB
| System Data Archives
| AUTO_UPDATE_CONTENT
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>NotRequireUserApproval<nowiki> | </nowiki>NotRequireRightForMount
|-
| 0x0030
| Applet
| APPLET
| Normal<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate
|-
| 0x0130
| Module
| BASE
| Normal<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<nowiki> | </nowiki>CanSkipConvertJumpId
|-
| 0x0138
| Firmware
| FIRMWARE
| Normal<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<nowiki> | </nowiki>CanSkipConvertJumpId
|}

=== 00040010 - System Applications ===
==== System Application Notes ====
System Application titles have a unique title low that varies by region.
Regardless of version, the ExeFS:/.code for mset is the same for USA/EUR/JPN.
The [[4.0.0-7]] version of mset([[4.1.0-8]] for TWN) has the same ExeFS:/.code for all regions(JPN, USA, EUR, CHN, KOR, TWN).
The [[5.0.0-11]] mset ExeFS:/.code is the same for all regions as well, except for CHN. The [[7.0.0-13]] mset ExeFS:/.code is unique for the following regions: CHN, KOR, and TWN.
A limited number of system-applications are included with gamecard-sysupdates. They are: [[System Settings]], [[Download Play]], SAFE_MODE [[System Settings#System Updater|System Updater]], and [[Nintendo 3DS Sound]] (this one was only in firms 3.0.0 - 6.2.0 inclusive).
The only system-applications included with the New3DS gamecard-sysupdate partition are: "menu" stub and "friend" stub.

{| class="wikitable sortable" border="1"
|-
! JPN TIDLow
! USA TIDLow
! EUR TIDLow
! CHN TIDLow
! KOR TIDLow
! TWN TIDLow
! [[Product code]]
! Description
! JPN Versions
! EUR Versions
! USA Versions
! CHN Versions
! KOR Versions
! TWN Versions
! Status
|-
| 00020000
| 00021000
| 00022000
| 00026000
| 00027000
| 00028000
| CTR-N-HAS?
| [[System Settings]] (mset)
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[3.0.0-5|v2060]], [[4.0.0-7|v3074]], [[5.0.0-11|v4097]], [[6.0.0-11|v5127]], [[7.0.0-13|v6157]], [[7.2.0-17|v7173]], [[8.1.0-0_New3DS|v8198]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v9224]], [[9.6.0-24|v10245]], [[10.6.0-31|v10256]], [[11.5.0-38|v11266]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[3.0.0-5|v2061]], [[4.0.0-7|v3075]], [[5.0.0-11|v4097]], [[6.0.0-11|v5127]], [[7.0.0-13|v6157]], [[7.2.0-17|v7174]], [[9.0.0-20|v8202]], [[9.6.0-24|v9220]], [[11.4.0-37|v10241]](New2DSXL), [[11.5.0-38|v10256]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[3.0.0-5|v2062]], [[4.0.0-7|v3078]], [[5.0.0-11|v4098]], [[6.0.0-11|v5128]], [[7.0.0-13|v6157]], [[7.2.0-17|v7174]], [[9.0.0-20|v8203]], [[9.6.0-24|v9221]], [[11.5.0-38|v10241]]
| [[4.0.0-7|v8]], [[4.4.0-10|v1024]](CHN-only sysupdate for just mset), [[5.0.0-11|v2049]], [[7.0.0-13|v3075]]
| [[4.0.0-7|v1026]], [[5.0.0-11|v2049]], [[7.0.0-13|v4098]]
| [[4.1.0-8|v8]], [[4.2.0-9|v1024]], [[5.0.0-11|v2050]], [[7.0.0-13|v3074]]
| Active
|-
| 00020100
| 00021100
| 00022100
| 00026100
| 00027100
| 00028100
| CTR-N-HDL?
| [[Download Play]] (dlplay)
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3072]](Also for [[8.1.0-0_New3DS]])
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]
| [[4.0.0-7|v4]]
| [[4.0.0-7|v1027]]
| [[4.1.0-8|v4]]
| Active
|-
| 00020200
| 00021200
| 00022200
| 00026200
| 00027200
| 00028200
| CTR-N-HMK?
| [[Activity Log]] (PLOG)
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2051]], [[10.6.0-31|v2080]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2054]], [[7.0.0-13|v2064]]
| Same as EUR
| [[4.0.0-7|v3]]
| [[4.0.0-7|v2]], [[7.0.0-13|v16]]
| [[4.1.0-8|v2]]
| Active
|-
| 00020300
| 00021300
| 00022300
| 00026300
| 00027300
| 00028300
| ?
| [[Health and Safety Information]] (safe)
| [[1.0.0-0|v0]], [[4.0.0-7|v1024]], [[6.0.0-11|v2050]]
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[4.0.0-7|v2050]], [[6.0.0-11|v3077]]
| [[1.0.0-0|v0]], [[4.0.0-7|v1026]], [[6.1.0-12U|v2051]]
| [[4.0.0-7|v5]]
| [[4.0.0-7|v2]]
| [[4.1.0-8|v5]]
| Active
|-
| 20020300
| 20021300
| 20022300
| N/A
| 20027300
| N/A
| CTR-N-HAC?
| [[New_3DS]] [[Health and Safety Information]] (ssafe)
| [[8.1.0-0_New3DS|v2]], [[9.3.0-21|v17]]
| [[8.1.0-0_New3DS|v1]], [[11.4.0-37|v16]](New2DSXL)
| Same as EUR.
| N/A
| [[9.6.0-24|v2]]
| N/A
| Active
|-
| 00020400
| 00021400
| 00022400
| 00026400
| 00027400
| 00028400
| CTR-N-HEP?
| [[Nintendo 3DS Camera]] (CtrApp)
| [[1.0.0-0|v0]], [[2.1.0-4|v16]], [[3.0.0-5|v1038]], [[4.0.0-7|v2048]], [[6.0.0-11|v3073]], [[9.0.0-20|v4097]](Also for [[8.1.0-0_New3DS]]), [[10.6.0-31|v4112]], [[11.5.0-38|v5120]]
| [[1.0.0-0|v0]], [[2.1.0-4|v16]], [[3.0.0-5|v1039]], [[4.0.0-7|v2048]], [[6.0.0-11|v3073]], [[7.0.0-13|v3088]], [[9.0.0-20|v4097]], [[11.4.0-37|v5120]](New2DSXL), [[11.5.0-38|v5120]]
| [[1.0.0-0|v0]], [[2.1.0-4|v16]], [[3.0.0-5|v1039]], [[4.0.0-7|v2048]], [[6.1.0-12U|v3074]], [[7.0.0-13|v3088]], [[9.0.0-20|v4097]], [[11.5.0-38|v5120]]
| [[4.0.0-7|v3]]
| [[4.0.0-7|v2]], [[7.0.0-13|v1040]]
| [[4.1.0-8|v3]]
| Active
|-
| 00020500
| 00021500
| 00022500
| 00026500
| 00027500
| 00028500
| CTR-N-HES?
| [[Nintendo 3DS Sound]] (CtrApp)
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[7.0.0-13|v3089]], [[11.4.0-37|v4096]]
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[7.0.0-13|v3088]], [[11.4.0-37|v4096]]
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[7.0.0-13|v3088]], [[11.4.0-37|v4096]]
| [[4.0.0-7|v2]], [[11.4.0-37|v1024]]
| [[4.0.0-7|v2]], [[7.0.0-13|v16]],[[11.4.0-37|v4096]]
| [[4.1.0-8|v3]], [[11.4.0-37|v1024]]
| Active
|-
| 00020700
| 00021700
| 00022700
| 00026700
| 00027700
| 00028700
| CTR-N-HED?
| [[Mii Maker]] (EDIT)
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[7.0.0-13|v2055]], [[10.6.0-31|v2064]]
| Same as JPN
| Same as JPN
| [[4.0.0-7|v1]]
| [[4.0.0-7|v1]], [[7.0.0-13|v16]]
| [[4.1.0-8|v2]]
| Active
|-
| 00020800
| 00021800
| 00022800
| 00026800
| 00027800
| 00028800
| CTR-N-HME?
| [[StreetPass Mii Plaza]] (MEET)
| [[1.0.0-0|v0]], v1027, [[2.1.0-4|v2048]], [[3.0.0-5|v3087]], [[3.0.0-6|v4096]], [[6.0.0-11|v5121]]
| [[1.0.0-0|v0]], v1027, [[2.1.0-4|v2048]], [[3.0.0-5|v3087]], [[3.0.0-6|v4096]], [[6.0.0-11|v5122]]
| [[1.0.0-0|v0]], v1027, [[2.1.0-4|v2048]], [[3.0.0-5|v3087]], [[3.0.0-6|v4096]], [[6.1.0-12U|v5124]], [[7.0.0-13|v5136]]
| [[4.0.0-7|v0]], [[4.4.0-10|v4096]]
| [[4.0.0-7|v1]], [[4.4.0-10|v4096]], [[7.0.0-13|v5120]]
| [[4.1.0-8|v1]], [[4.4.0-10|v4096]]
| Active
|-
| 00020900
| 00021900
| 00022900
| N/A
| 00027900
| 00028900
| CTR-N-HGR?
| [[eShop]] (tiger)
| [[2.0.0-2|v4]], [[2.1.0-3|v1026]], [[3.0.0-5|v2057]], [[4.0.0-7|v3081]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7169]], [[7.0.0-13|v8206]], [[7.1.0-14|v9231]], [[7.2.0-17|v10245]], [[8.0.0-18|v11265]], [[8.1.0-19|v12288]], [[9.0.0-20|v13320]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17421]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20483]], [[10.7.0-32|v21504]], [[11.3.0-36|v23552]], [[11.5.0-38|v25600]]
| [[2.0.0-2|v4]], [[2.1.0-3|v1026]], [[3.0.0-5|v2058]], [[4.0.0-7|v3081]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7171]], [[7.0.0-13|v8206]], [[7.1.0-14|v9231]], [[7.2.0-17|v10245]], [[8.0.0-18|v11265]], [[8.1.0-19|v12288]], [[9.0.0-20|v13320]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17421]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20482]], [[10.7.0-32|v21505]], [[11.2.0-35|v22528]], [[11.3.0-36|v23552]], [[11.4.0-37|v24576]](New2DSXL), [[11.5.0-38|v25600]]
| [[2.0.0-2|v4]], [[2.1.0-3|v1026]], [[3.0.0-5|v2058]], [[4.0.0-7|v3081]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7170]], [[7.0.0-13|v8206]], [[7.1.0-14|v9231]], [[7.2.0-17|v10246]], [[8.0.0-18|v11265]], [[8.1.0-19|v12288]], [[9.0.0-20|v13321]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17422]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20482]], [[10.7.0-32|v21506]], [[11.3.0-36|v23552]], [[11.5.0-38|v25600]]
| N/A
| [[4.0.0-7|v3082]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7169]], [[7.0.0-13|v8205]], [[7.1.0-14|v9231]], [[8.1.0-19|v12288]], [[9.0.0-20|v13320]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17420]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20482]]
| [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7170]], [[7.0.0-13|v8205]], [[7.1.0-14|v9231]], [[8.1.0-19|v12288]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17421]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]]
| Active
|-
| 00020A00
| 00021A00
| 00022A00
| N/A
| 00027A00
| 00028A00
| CTR-N-HCB?
| [[System Transfer]] (CARDBOARD)
| [[2.0.0-2|v4]], [[3.0.0-5|v1035]], [[4.0.0-7|v2050]], [[5.0.0-11|v3074]], [[7.0.0-13|v4109]], [[9.0.0-20|v5130]], [[9.6.0-24|v6154]]
| [[2.0.0-2|v4]], [[3.0.0-5|v1035]], [[4.0.0-7|v2050]], [[5.0.0-11|v3073]], [[7.0.0-13|v4109]], [[9.0.0-20|v5131]], [[9.6.0-24|v6155]]
| [[2.0.0-2|v4]], [[3.0.0-5|v1035]], [[4.0.0-7|v2051]], [[5.0.0-11|v3073]], [[7.0.0-13|v4109]], [[9.0.0-20|v5131]], [[9.6.0-24|v6156]]
| N/A
| [[4.0.0-7|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]], [[9.0.0-20|v3082]]
| [[4.1.0-8|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]]
| Active
|-
| 00020B00
| 00021B00
| 00022B00
| N/A
| N/A
| N/A
| CTR-N-HMA?
| [[Nintendo Zone]] ("Nintendo") (MARS)
| [[1.0.0-0|v0]], [[3.0.0-5|v1034]]
| Same as JPN
| Same as JPN
| N/A
| N/A
| N/A
| Active
|-
| 00020D00
| 00021D00
| 00022D00
| 00026D00
| 00027D00
| 00028D00
| CTR-N-HCH?
| [[Face Raiders]]
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]]
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]], [[7.0.0-13|v1040]]
| Same as EUR
| [[4.0.0-7|v0]]
| [[4.0.0-7|v0]]
| [[4.1.0-8|v2]]
| Active
|-
| 20020D00
| 20021D00
| 20022D00
| N/A
| 20027D00
| N/A
| ?
| [[New_3DS]] [[Face Raiders]] (FACE)
| [[8.1.0-0_New3DS|v2050]]
| [[8.1.0-0_New3DS|v2049]]
| Same as EUR.
| N/A
| [[9.6.0-24|v2049]]
| N/A
| Active
|-
| 00020E00
| 00021E00
| 00022E00
| 00026E00
| 00027E00
| 00028E00
| CTR-N-HAR?
| [[AR Games]] (AR_ACT)
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]]
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[7.0.0-13|v1040]]
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[7.0.0-13|v1040]]
| [[4.0.0-7|v0]]
| [[4.0.0-7|v0]], [[7.0.0-13|v16]]
| [[4.1.0-8|v1]]
| Active
|-
| 00020F00
| 00021F00
| 00022F00
| 00026F00
| 00027F00
| 00028F00
| CTR-N-HSH?
| SAFE_MODE [[System Settings#System Updater|System Updater]] (mset)
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2049]]
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2050]]
| Same as JPN
| [[4.0.0-7|v1]], [[6.0.0-11|v1026]]
| [[4.0.0-7|v1]]
| [[4.1.0-8|v1]]
| Active
|-
| 00023000
| 00024000
| 00025000
| N/A
| N/A
| N/A
| (Variable?)
| Promotional video
| [[1.1.0-1|v2]], [[2.0.0-2|v2048]]
| [[1.1.0-1|v<unknown>]], [[2.0.0-2|v2048]]
| [[1.1.0-1|v0]], [[2.0.0-2|v2048]]
| N/A
| N/A
| N/A
| Stubbed
|-
| 0002BF00
| 0002C000
| 0002C100
| N/A
| N/A
| N/A
| CTR-N-HAF?
| [[Nintendo Network ID Settings]] (act)
| [[7.0.0-13|v14]], [[7.2.0-17|v1029]], [[9.0.0-20|v2051]], [[9.3.0-21|v3072]]
| Same as JPN
| Same as JPN
| N/A
| N/A
| N/A
| Active
|-
| 20023100
| 20024100
| 20025100
| N/A
| N/A
| N/A
| CTR-N-HAJ?
| [[microSD Management]] ('mcopy') ([[New_3DS]]-only)
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]]
| [[8.1.0-0_New3DS|v4]]
| [[8.1.0-0_New3DS|v5]]
| N/A
| N/A
| N/A
| Available
|-
| 2002C800
| 2002CF00
| 2002D000
| N/A
| 2002D700
| N/A
| CTR-P-CTAP
| [[New_3DS]] HOME menu digital manual
| [[8.1.0-0_New3DS|v2]], [[9.0.0-20|v18]], [[9.3.0-21|v34]], [[9.6.0-24|v50]]
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v17]], [[9.6.0-24|v34]], [[11.4.0-37|v48]](New2DSXL)
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v18]], [[9.6.0-24|v33]]
| N/A
| [[9.6.0-24|v2]]
| N/A
| Stubbed
|-
| 2002C900
| 2002D100
| 2002D200
| N/A
| 2002D800
| N/A
| CTR-P-CTAP
| [[New_3DS]] Friends list digital manual
| [[8.1.0-0_New3DS|v1]]
| Same as JPN.
| [[8.1.0-0_New3DS|v0]], [[9.3.0-21|v16]]
| N/A
| [[9.6.0-24|v2]]
| N/A
| Stubbed
|-
| 2002CA00
| 2002D300
| 2002D400
| N/A
| 2002D900
| N/A
| CTR-P-CTAP
| [[New_3DS]] Notifications digital manual
| [[8.1.0-0_New3DS|v0]], v1([[Home_Menu|JPN-only]] Oct 2, 2014 "sysupdate", actually uploaded on 09-29-14. Identical to v0, same TMDs besides title-versions)
| [[8.1.0-0_New3DS|v2]]
| [[8.1.0-0_New3DS|v0]]
| N/A
| [[9.6.0-24|v2]]
| N/A
| Stubbed
|-
| 2002CB00
| 2002D500
| 2002D600
| N/A
| 2002DA00
| N/A
| CTR-P-CTAP
| [[New_3DS]] Game Notes digital manual
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1]]
| [[8.1.0-0_New3DS|v2]]
| Same as EUR.
| N/A
| [[9.6.0-24|v1]]
| N/A
| Stubbed
|}

=== 0004001B - [[NCCH#CFA|System Data Archives]] ===
{| class="wikitable sortable" border="1"
|-
! TitleID Low
! Description
! Versions
|-
| 00010002
| [[ClCertA]]
| [[1.0.0-0|v0]]
|-
| 00010702
| [[NS CFA]]
| [[3.0.0-5|v0]], [[6.0.0-11|v1028]], [[6.3.0-12|v2048]], [[7.0.0-13|v3073]], [[9.0.0-20|v4096]](also for [[8.1.0-0_New3DS]])
|-
| 00010802
| This CFA only contains a 1-byte "dummy.txt" in the RomFS, which contains '0'.
| [[6.3.0-12|v0]], [[9.5.0-23|v1024]], [[10.5.0-30|v2048]], [[11.0.0-33|v3072]]
|-
| 00018002
| Same contents as 00010802. Starting with [[7.1.0-15]], the "dummy.txt" file was removed from RomFS: this CFA RomFS now contains web-browser data(similar to 00018102) for NNID / networking, etc.
| [[7.0.0-13|v14]], [[7.1.0-15|v1025]], [[7.2.0-17|v2055]], [[9.0.0-20|v3078]], [[9.3.0-21|v4096]], [[9.6.0-24|v5120]]
|-
| 00018102
| This contains local web-browser data(html/js, gfx, etc) for the Miiverse Offline-mode.
| [[7.0.0-13|v11]], [[9.0.0-20|v1025]](also for [[8.1.0-0_New3DS]])
|-
| 00018202
| This contains the webkit/OSS [[CRO0|CROs]] used with the Miiverse applet and the "act" application.
| [[7.0.0-13|v7]], [[8.1.0-0_New3DS|v1026]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v2050]]
|-
| 00019002
| [[Fangate_updater]]
| [[9.3.0-21|v2]], [[9.6.0-24|v1026]]
|}

=== 00040030 - System Applets===
==== System Applet Notes ====
Most of these processes are applets, see [[NS_and_APT_Services|here]] for details.
All of the below processes use the "SYSTEM" [[SVC|memory-region]].
The ExeFS for Home Menu is exactly the same for USA/EUR/JPN.
The Miiverse applet seems to use a web browser with webkit.

{| class="wikitable sortable" border="1"
|-
! JPN TitleIDLow
! USA TitleIDLow
! EUR TitleIDLow
! CHN TitleIDLow
! KOR TitleIDLow
! TWN TitleIDLow
! [[Product code]]
! Description
! JPN Versions
! USA Versions
! EUR Versions
|-
|colspan=6 align=center| 00008102
| CTR-P-CTAP
| [[NS#Alternate menu|Test Menu]] (Demo1)
|colspan=3 align=center| ..., v64, ..., v27648
|-
| 00008202
| 00008F02
| 00009802
| 0000A102
| 0000A902
| 0000B102
| CTR-P-HMM?
| [[Home Menu]] (menu)
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[2.1.0-3|v2049]], [[2.2.0-X|v3075]], [[3.0.0-5|v4111]], [[4.0.0-7|v5131]], [[4.2.0-9|v6146]], [[5.0.0-11|v7172]], [[6.0.0-11|v8198]], [[7.0.0-13|v9230]], [[8.1.0-0_New3DS|v10250]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v13313]], [[9.1.0-20J|v14336]], [[9.2.0-20|v15360]], [[9.3.0-21|v16402]], [[9.4.0-21|v17408]], [[9.5.0-22|v18432]], [[9.6.0-24|v19476]], [[9.7.0-25|v20487]], [[9.8.0-25|v22528]], [[10.1.0-27|v23552]], [[10.2.0-28|v24576]], [[10.3.0-28|v25600]], [[10.4.0-29|v26626]], [[10.6.0-31|v27648]], [[11.1.0-34|v28672]], [[11.3.0-36|v29696]], [[11.5.0-38|v30721]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[2.1.0-3|v2049]], [[2.2.0-X|v3075]], [[3.0.0-5|v4111]], [[4.0.0-7|v5131]], [[4.2.0-9|v6146]], [[5.0.0-11|v7172]], [[6.0.0-11|v8198]], [[7.0.0-13|v9230]], [[9.0.0-20|v11272]], [[9.2.0-20|v12288]], [[9.3.0-21|v13330]], [[9.4.0-21|v14336]], [[9.5.0-22|v15360]], [[9.6.0-24|v16404]], [[9.7.0-25|v17415]], [[9.8.0-25|v19456]], [[9.9.0-26|v20480]], [[10.1.0-27|v21504]], [[10.2.0-28|v22528]], [[10.3.0-28|v23552]], [[10.4.0-29|v24578]], [[10.6.0-31|v25600]], [[11.1.0-34|v26624]], [[11.3.0-36|v27648]], [[11.5.0-38|v28673]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[2.1.0-3|v2049]], [[2.2.0-X|v3075]], [[3.0.0-5|v4111]], [[4.0.0-7|v5131]], [[4.2.0-9|v6146]], [[5.0.0-11|v7172]], [[6.0.0-11|v8198]], [[7.0.0-13|v9230]], [[9.0.0-20|v11272]], [[9.2.0-20|v12288]], [[9.3.0-21|v13330]], [[9.4.0-21|v14336]], [[9.5.0-22|v15360]], [[9.6.0-24|v16404]], [[9.7.0-25|v17415]], [[9.8.0-25|v19456]], [[10.1.0-27|v20480]], [[10.2.0-28|v21504]], [[10.3.0-28|v22528]], [[10.4.0-29|v23554]], [[10.6.0-31|v24576]], [[11.1.0-34|v25600]], [[11.3.0-36|v26624]], [[11.4.0-37|v27649]](New2DSXL), [[11.5.0-38|v27649]]
|-
| 00008402
| 00009002
| 00009902
| 0000A202
| 0000AA02
| 0000B202
| CTR-N-HCS?
| Camera applet used by Home-menu (CtrApp)
|colspan=3| v0, v1036, [[9.0.0-20|v2049]](Also for [[8.1.0-0_New3DS]])
|-
| 00008502
| 00009102
| 00009A02
| ?
| ?
| ?
| ?
| Not available on CDN
| ?
| ?
| ?
|-
| 00008602
| 00009202
| 00009B02
| 0000A402
| 0000AC02
| 0000B402
| CTR-N-HMV?
| Instruction Manual, applet for displaying instruction manuals
|colspan=3| v0, v1026, v2048, v3072, [[5.0.0-11|v4097]], [[9.0.0-20|v5120]](Also for [[8.1.0-0_New3DS]])
|-
| 00008702
| 00009302
| 00009C02
| 0000A502
| 0000AD02
| 0000B502
| CTR-N-HGM?
| Game Notes (Cherry)
|colspan=3| v0, v1026, v2049, [[5.0.0-11|v3073]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])
|-
| 00008802
| 00009402
| 00009D02
| 0000A602
| 0000AE02
| 0000B602
|
| [[Internet Browser]] (spider)
|colspan=3| [[2.0.0-2|v6]], [[2.1.0-4|v1024]], [[4.0.0-7|v2050]], [[5.0.0-11|v3074 (EUR)/v3075(USA,JAP)]], [[7.0.0-13|v3088]], [[7.1.0-16|v4096]], [[9.5.0-23|v5121]], [[9.9.0-26|v6149]], [[10.2.0-28|v7168]], [[10.6.0-31|v8192]], [[10.7.0-32|v9232]], [[11.1.0-34|v10240]], [[11.9.0-42|v11297]]
|-
| 20008802
| 20009402
| 20009D02
| ?
| 2000AE02
| N/A
| CTR-N-HBR?
| [[New 3DS]] [[Internet Browser]] (SKATER)
|colspan=3| [[8.1.0-0_New3DS|v10]], [[9.3.0-21|v1027]], [[9.6.0-24|v2051]], [[9.9.0-26|v3077]], [[10.2.0-28|v4096]], [[10.4.0-29|v5121]], [[10.6.0-31|v6144]], [[10.7.0-32|v7184]], [[11.1.0-34|v8192]], [[11.9.0-42|v10272]]
|-
|colspan=6| 00008A02
|
| Fatal error viewer ([[ErrDisp]])
|colspan=3| v0, v1025, [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]](Also for [[8.1.0-0_New3DS]])
|-
|colspan=6| 00008A03
|
| SAFE_MODE [[ErrDisp]]
|colspan=3| v0
|-
| 20008A03
| 20008A03
| 20008A03
| ?
| 20008A03
| N/A
|
| [[New_3DS]] SAFE_MODE [[ErrDisp]]
|colspan=3| [[8.1.0-0_New3DS|v7169]]
|-
| 00008D02
| 00009602
| 00009F02
| 0000A702
| 0000AF02
| 0000B702
| CTR-N-HFR?
| Friend List (friend)
|colspan=3| v0, v1026, [[2.2.0-X|v2051]], v3082, v4099, [[7.0.0-13|v5120]], [[9.0.0-20|v6144]](Also for [[8.1.0-0_New3DS]]) (EUR v6, v1024, v3082, v4099, [[7.0.0-13|v5120]], [[9.0.0-20|v6144]])
|-
| 00008E02
| 00009702
| 0000A002
| 0000A802
| 0000B002
| 0000B802
| CTR-N-HCR?
| Notifications (newslist)
|colspan=3| v0, v1029, v2054, v3075, [[9.0.0-20|v4097]] (EUR v6, v1024, v2054, v3075, [[9.0.0-20|v4097]]) (JPN: ..., [[8.1.0-0_New3DS|v4096]], [[9.0.0-20|v5121]])
|-
| 0000C002
| 0000C802
| 0000D002
| 0000D802
| 0000DE02
| 0000E402
| CTR-N-HKY?
| Software Keyboard (swkbd)
|colspan=3| v0, v1026, v2053, [[7.0.0-13|v3072]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])
|-
| 0000C003
| 0000C803
| 0000D003
| 0000D803
| 0000DE03
| 0000E403
|
| SAFE_MODE Software Keyboard (swkbd)
|colspan=3| v0
|-
| 2000C003
| 2000C803
| 2000D003
| ?
| 2000DE03
| N/A
|
| [[New 3DS]] SAFE_MODE Software Keyboard (swkbd)
| [[8.1.0-0_New3DS|v1024]]
|colspan=2|[[9.0.0-20|v0]]
|-
| 0000C102
| 0000C902
| 0000D102
| 0000D902
| 0000DF02
| 0000E502
| CTR-N-HMS?
| Mii picker (appletEd)
|colspan=3| v0, v1026, [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v3077]]
|-
| 0000C302
| 0000CB02
| 0000D302
| 0000DB02
| 0000E102
| 0000E702
| CTR-N-HCC?
| Picture picker (PNOTE_AP)
|colspan=3| v0, v1024, [[8.1.0-0_New3DS|v2049]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v3075]], [[9.3.0-21|v4096]]
|-
| 0000C402
| 0000CC02
| 0000D402
| 0000DC02
| 0000E202
| 0000E802
| CTR-N-HMC?
| [[Nintendo 3DS Sound|Voice memo]] picker (SNOTE_AP)
|colspan=3| v0, v3, [[8.0.0-18|v1026]], [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]])
|-
|colspan=3| 0000C502
|colspan=3| 0000CF02
| CTR-N-HEEA
CTR-N-HEEK
| Non-critical (online, etc) error display (error)
|colspan=3| v0, v1026, v2053, v3074, [[8.1.0-0_New3DS|v4096]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v5128]], [[9.6.0-24|v6145]]
|-
|colspan=3| 0000C503
|colspan=3| 0000CF03
|
| SAFE_MODE error applet
|colspan=3| v0
|-
| 2000C503
| 2000C503
| 2000C503
| ?
| 2000CF03
| N/A
|
| [[New 3DS]] SAFE_MODE error applet
|colspan=3| [[8.1.0-0_New3DS|v1024]]
|-
|colspan=3| 0000CD02
|colspan=3| 0000D502
| CTR-N-HADA
CTR-N-HADK
| [[Circle Pad Pro]] test/calibration applet (extrapad)
|colspan=3| v1, v1026, [[8.1.0-0_New3DS|v2048]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v3073]], [[11.4.0-37|v4097]](New2DSXL), [[11.5.0-38|v4097]]
|-
| 0000C602
| 0000CE02
| 0000D602
| N/A
| 0000E302
| 0000E902
| CTR-N-HAA?
| eShop applet, used by applications for accessing the eShop, for DLC/etc. Also used by the eShop application itself. (mint)
|colspan=3| v5, v1028, [[4.2.0-9|v2050]], [[5.0.0-11|v3072]], [[7.0.0-13|v4109]], [[7.2.0-17|v5125]](v5123 for JPN), [[8.0.0-18|v6145]], [[8.1.0-0_New3DS|v7168]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v8200]], [[9.3.0-21|v9224]], [[9.6.0-24|v10247]], [[9.8.0-25|v11264]], [[10.0.0-27|v12293]], [[10.1.0-27|v13312]], [[10.3.0-28|v14337]], [[10.4.0-29|v15360]], [[10.7.0-32|v16384]], [[11.2.0-35|v17408]](EUR), [[11.3.0-36|v18432]], [[11.5.0-38|v19457]]
|-
| 0000BC02
| 0000BD02
| 0000BE02
| ?
| N/A
| ?
| CTR-N-HAE?
| Miiverse (olv)
|colspan=3| [[7.0.0-13|v14]], [[7.2.0-17|v1024]], [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v3072]], [[9.6.0-24|v4096]]
|-
|colspan=3| 0000F602
| ?
| N/A
| ?
| CTR-N-HAGA
| Likely the "system library" for Miiverse (memolib)
|colspan=3| [[7.0.0-13|v5]], [[8.1.0-0_New3DS|v1024]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v2050]], [[9.3.0-21|v3072]]
|-
| 00008302
| 00008B02
| 0000BA02
| ?
| N/A
| ?
| CTR-N-HAH?
| In-app Miiverse-posting applet (solv3)
|colspan=3| [[9.0.0-20|v6]]
|-
| 00009502
| 00009E02
| 0000B902
| ?
| 00008C02
| 0000BF02
| CTR-N-HA3?
| Cabinet ([[amiibo Settings]])
|colspan=3| [[9.3.0-21|v7]], (v1024 for TWN), [[9.6.0-24|v1031]]
|}

=== 0004009B - [[NCCH#CFA|Shared Data Archives]] ===
{| class="wikitable sortable" border="1"
|-
! JPN TitleIDLow
! USA TitleIDLow
! EUR TitleIDLow
! CHN TitleIDLow
! KOR TitleIDLow
! TWN TitleIDLow
! Description
! Versions
|-
| 00010202
| 00010202
| 00010202
| 00010202
| 00010202
| 00010202
| Probably Mii-related, contains "CFL_Res.dat" in the RomFS.
| v0
|-
| 00010402
| 00010402
| 00010402
| 00010402
| 00010402
| 00010402
| Region Manifest. Mounted as "area:"
| v0, v1024, v2050, v3072, [[7.0.0-13|v4098]], [[9.6.0-24|v5122]]
|-
| 00010602
| 00010602
| 00010602
| 00010602
| 00010602
| 00010602
| Non-Nintendo TLS Root-CA Certificates (RomFS contains files with filename "CACERT_PUBLIC_CA_<val>.der", where <val> is 5..8)
| v2, [[10.5.0-30|v1024]]
|-
|
|
|
| 00011002
|
|
| "CHN/CN" Dictionary.
| v1
|-
|
|
|
|
|
| 00011102
| "TWN/TN" dictionary.
| v1
|-
|
|
| 00011202
|
|
|
| "NL/NL" dictionary.
| v0
|-
|
|
| 00011302
|
|
|
| "EN/GB" dictionary.
| v0
|-
|
| 00011402
|
|
|
|
| "EN/US" dictionary.
| v0
|-
|
|
| 00011502
|
|
|
| "FR/FR/regular" dictionary.
| v0
|-
|
| 00011602
|
|
|
|
| "FR/CA/regular" dictionary.
| v0
|-
|
|
| 00011702
|
|
|
| "DE/regular" dictionary.
| v0
|-
|
|
| 00011802
|
|
|
| "IT/IT" dictionary.
| v0
|-
| 00011902
|
|
|
|
|
| "JA_small/32" dictionary.
| v0
|-
|
|
|
|
| 00011A02
|
| "KO/KO" dictionary.
| v1
|-
|
|
| 00011B02
|
|
|
| "PT/PT/regular" dictionary.
| v0
|-
|
|
| 00011C02
|
|
|
| "RU/regular" dictionary.
| v0
|-
|
| 00011D02
| 00011D02
|
|
|
| "ES/ES" dictionary.
| v0
|-
|
| 00011E02
|
|
|
|
| "PT/BR/regular" dictionary.
| v0
|-
| 00012202
| 00012302
| 00012102
| 00012402
| 00012502
| 00012602
| ?contains a lists with error strings
| v1026, v2053, v3073, [[4.2.0-9|v4096]], [[5.0.0-11|v5120]], [[7.0.0-13|v6149]], [[7.2.0-17|v7168]], [[8.0.0-18|v8192]], [[9.0.0-20|v9218]], [[9.3.0-21|v10242]], [[9.6.0-24|v11269]], [[10.0.0-27|v12289]], [[10.4.0-29|v13312]], [[10.7.0-32|v13313]] (JPN: [[11.1.0-34|v14336]]) (KOR: [[9.6.0-24|v6148]], [[10.0.0-27|v7169]], [[10.3.0-28|v8193]], [[10.4.0-29|v9216]], [[11.1.0-34|v10240]])
|-
| 00013202
| 00013302
| 00013102
| 00013502
|
|
| Mounted as "eula:"
| v0, v1024, v2049 USA: v1024, v2051, [[7.0.0-13|v3074]], [[7.2.0-17|v4100]](EUR-only), [[9.0.0-20|v4099]], [[9.9.0-26|v6144]], [[10.4.0-29|v7168]] (KOR: [[9.7.0-25|v1025]])
|-
| 00014002
| 00014002
| 00014002
| 00014002
| 00014002
| 00014002
| JPN/EUR/USA [[System Font]] ("font:")
| v0
|-
| 00014102
| 00014102
| 00014102
| 00014102
| 00014102
| 00014102
| CHN [[System Font]] ("font:")
| v0, v1024
|-
| 00014202
| 00014202
| 00014202
| 00014202
| 00014202
| 00014202
| KOR [[System Font]] ("font:")
| v0, v1024
|-
| 00014302
| 00014302
| 00014302
| 00014302
| 00014302
| 00014302
| TWN [[System Font]] ("font:")
| v0, v1024
|-
| 00015202
| 00015302
| 00015102
| N/A
| 00015502
| 0015602
| Mounted as "rate:"
| v0 (EUR: v0, v1024) (KOR: v1024)
|}

=== 000400DB - [[NCCH#CFA|System Data Archives]] ===
==== System Data Archive Notes ====
These [[NVer]] titleIDs can be found @ offset 0x320 in every [[CCI]].

{| class="wikitable sortable" border="1"
|-
! EUR TitleIDLow
! JPN TitleIDLow
! USA TitleIDLow
! CHN TitleIDLow
! KOR TitleIDLow
! TWN TitleIDLow
! Description
! USA/EUR/JPN Versions
! CHN Versions
! TWN Versions
! KOR Versions
|-
| 00010302
| 00010302
| 00010302
| 00010302
| 00010302
| 00010302
| NGWord bad word list
|colspan=4| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[3.0.0-5|v2052]], [[4.0.0-7|v3072]], [[4.3.0-10|v4096]], [[5.0.0-11|v5120]], [[9.0.0-20|v6144]], [[9.3.0-21|v7168]], [[9.6.0-24|v8192]], [[11.1.0-34|v9217]]
|-
| 00010502
| 00010502
| 00010502
| 00010502
| 00010502
| 00010502
| [[Nintendo Zone]] hotspot list
|colspan=4| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[3.0.0-5|v2048]], [[4.0.0-7|v3073]], [[4.3.0-10|v4096]], [[4.4.0-10|v5120]], [[4.5.0-10|v6144]], [[5.0.0-11|v7169]], [[6.0.0-11|v8192]], [[6.2.0-12|v9216]], [[7.0.0-13|v10242]], [[7.2.0-17|v11267]], [[8.0.0-18|v12288]], [[9.0.0-20|v14336]], [[9.3.0-21|v15360]], [[9.6.0-24|v16386]], [[10.0.0-27|v17409]], [[10.4.0-29|v18432]], [[11.1.0-34|v19457]], [[11.5.0-38|v20480]], [[11.9.0-42|v22528]]
|-
| 00016102
| 00016202
| 00016302
| 00016402
| 00016502
| 00016602
| [[NVer]]
| [[1.0.0-0|v0]], [[1.1.0-1|v16]], [[2.0.0-2|v32]], [[2.1.0-3|v48]], [[2.1.0-4|v64]], [[3.0.0-5|v80]], [[3.0.0-6|v96]], [[4.0.0-7|v112]], [[4.1.0-8|v128]], [[4.2.0-9|v144]], [[4.3.0-10|v160]], [[5.0.0-11|v176]], non-USA=[[6.0.0-11|v192]]/USA=[[6.1.0-12U|v192]], [[7.0.0-13|v208]], [[7.1.0-14|v224]], [[7.1.0-15|v240]], [[7.1.0-16|v256]], [[7.2.0-17|v272]], [[8.0.0-18|v288]], [[8.1.0-19|v304]], [[9.0.0-20|v320]], [[9.3.0-21|v336]], [[9.5.0-22|v352]], [[9.5.0-23|v368]], [[9.6.0-24|v384]], [[9.7.0-25|v400]], [[9.9.0-26|v416]], [[10.0.0-27|v432]], [[10.2.0-28|v448]], [[10.4.0-29|v464]], [[10.5.0-30|v480]], [[10.6.0-31|v496]], [[10.7.0-32|v512]], [[11.0.0-33|v528]], [[11.1.0-34|v544]], [[11.2.0-35|v560]], [[11.3.0-36|v576]], [[11.5.0-38|v608]], ..., [[11.9.0-42|v672]]
| [[4.0.0-7|v113]], [[4.2.0-9|v128]], [[5.0.0-11|v129]], [[7.1.0-16|v130]], [[7.2.0-17|v272]], [[9.5.0-23|v131]], [[9.9.0-26|v132]]
| [[4.1.0-8|v114]], [[4.2.0-9|v133]], [[4.3.0-10|v134]], [[5.0.0-11|v136]], [[7.0.0-13|v144]], [[7.1.0-14|v160]] [[7.1.0-16|v192]], [[7.2.0-17|v272]], [[8.0.0-18|v208]], [[8.1.0-19|v224]], [[9.0.0-20|v240]], [[9.5.0-22|v272]], [[9.5.0-23|v288]], [[9.6.0-24|v304]], [[9.7.0-25|v320]], [[9.9.0-26|v336]], [[10.0.0-27|v352]], [[10.2.0-28|v368]], [[10.4.0-29|v384]], [[10.5.0-30|v400]], [[10.6.0-31|v416]], [[10.7.0-32|v432]], [[11.0.0-33|v448]], [[11.1.0-34|v464]], [[11.2.0-35|v480]], [[11.3.0-36|v496]], ..., [[11.9.0-42|v544]]
| [[4.0.0-7|v113]], [[4.1.0-8|v114]], [[4.2.0-9|v133]], [[4.3.0-10|v134]], [[5.0.0-11|v136]], [[7.0.0-13|v160]], [[7.1.0-14|v176]], [[7.1.0-16|v176]], [[7.2.0-17|v272]], [[8.0.0-18|v224]], [[8.1.0-19|v240]], [[9.0.0-20|v256]], [[9.3.0-21|v272]], [[9.5.0-22|v288]], [[9.5.0-23|v304]], [[9.6.0-24|v320]], [[9.7.0-25|v336]], [[9.9.0-26|v352]], [[10.0.0-27|v368]], [[10.2.0-28|v384]], [[10.4.0-29|v400]], [[10.5.0-30|v416]], [[10.6.0-31|v432]], [[10.7.0-32|v448]], [[11.0.0-33|v464]], [[11.1.0-34|v480]], [[11.2.0-35|v496]], [[11.3.0-36|v512]], ..., [[11.9.0-42|v576]]
|-
| 20016102
| 20016202
| 20016302
| N/A
| 20016502
| N/A
| [[New_3DS]] [[NVer]]
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v320]], [[9.3.0-21|v336]], [[9.5.0-22|v352]], [[9.5.0-22|v352]], [[9.5.0-23|v368]], [[9.6.0-24|v384]], [[9.7.0-25|v400]], [[9.9.0-26|v416]], [[10.0.0-27|v432]], [[10.2.0-28|v448]], [[10.4.0-29|v464]], [[10.5.0-30|v480]], [[10.6.0-31|v496]], [[10.7.0-32|v512]], [[11.0.0-33|v528]], [[11.1.0-34|v544]], [[11.2.0-35|v560]], [[11.3.0-36|v576]], ..., [[11.9.0-42|v672]]
| N/A
| N/A
| [[9.6.0-24|v320]], [[9.7.0-25|v336]], [[9.9.0-26|v352]], [[10.0.0-27|v368]], [[10.2.0-28|v384]], [[10.4.0-29|v400]], [[10.5.0-30|v416]], [[10.6.0-31|v432]], [[10.7.0-32|v448]], [[11.0.0-33|v464]], [[11.2.0-35|v496]], [[11.3.0-36|v512]], ..., [[11.9.0-42|v576]]
|-
| 00017102
| 00017202
| 00017302
| 00017402
| 00017502
| 00017602
| [[CVer]]
| [[1.0.0-0|v1024]], [[1.1.0-1|v1045]], [[2.0.0-2|v2049]], [[2.1.0-3|v2069]], [[2.2.0-X|v2088]] [[3.0.0-5|v3088]], [[4.0.0-7|v4098]], [[4.1.0-8|v4113]], [[4.2.0-9|v4130]], [[4.3.0-10|v4145]], [[4.4.0-10|v4163]], [[4.5.0-10|v4176]], [[5.0.0-11|v5120]], [[5.1.0-11|v5136]], [[6.0.0-11|v6146]], [[6.1.0-11|v6160]], [[6.2.0-12|v6178]], [[6.3.0-12|v6192]], [[7.0.0-13|v7175]], [[7.1.0-14|v7187]], [[7.2.0-17|v7203]], [[8.0.0-18|v8196]], [[8.1.0-18|v8208]], [[8.1.0-0_New3DS|v8215]](8.1.0-0_New3DS), [[9.0.0-20|v9218]], [[9.1.0-20J|v9232]](JPN-only), [[9.2.0-20|v9248]], [[9.3.0-21|v9264]], [[9.4.0-21|v9280]], [[9.5.0-22|v9296]], [[9.6.0-24|v9319]], [[9.7.0-25|v9328]], [[9.8.0-25|v9344]], [[9.9.0-26|v9360]], [[10.0.0-27|v10240]], [[10.1.0-27|v10256]], [[10.2.0-28|v10272]], [[10.3.0-28|v10288]], [[10.4.0-29|v10304]], [[10.5.0-30|v10320]], [[10.6.0-31|v10336]], [[10.7.0-32|v10352]], [[11.0.0-33|v11264]], [[11.1.0-34|v11280]], [[11.2.0-35|v11296]], [[11.3.0-36|v11312]], [[11.4.0-37|...]], [[11.5.0-38|v11344]], ..., [[11.9.0-42|v11408]]
| [[1.0.0-0|v1024]], [[1.1.0-1|v1045]], [[2.0.0-2|v2049]], [[2.1.0-3|v2069]], [[2.2.0-X|v2088]] [[3.0.0-5|v3088]], [[4.0.0-7|v4098]], [[4.1.0-8|v4113]], [[4.2.0-9|v4130]], [[4.3.0-10|v4145]], [[4.4.0-10|v4163]], [[4.5.0-10|v4176]], [[5.0.0-11|v5120]], [[5.1.0-11|v5136]], [[6.0.0-11|v6146]], [[6.1.0-11|v6160]], [[6.2.0-12|v6178]], [[6.3.0-12|v6192]], [[7.0.0-13|v7175]], [[7.1.0-14|v7187]], [[7.2.0-17|v7203]], [[8.0.0-18|v8196]], [[8.1.0-18|v8208]], [[9.0.0-20|v9217]], [[9.3.0-21|v9264]], [[9.5.0-22|v9296]], [[9.6.0-24|v9319]], [[9.7.0-25|v9328]], [[9.8.0-25|v9344]], [[9.9.0-26|v9360]], [[10.0.0-27|v10240]], [[10.2.0-28|v10272]], [[10.4.0-29|v10304]], [[10.5.0-30|v10320]], [[10.6.0-31|v10336]], [[10.7.0-32|v10352]], [[11.2.0-35|v11296]], [[11.3.0-36|v11312]], ..., [[11.9.0-42|v11408]]
| Same as CHN
| Same as CHN + [[11.1.0-34|v11280]]
|}

=== 00040130 - System [[Services API|Modules]] ===
==== System Module Notes ====
Once Home Menu finishes loading, all of the below system modules are running, except for MP, RO, and act which are automatically [[Process_Manager_Services|loaded]] when a process requires them.
When [[Process_Manager_Services|PM]]-module terminates processes, it will check whether the processes listed as dependencies for this process are listed as dependencies for other processes.
Any processes which are no longer listed in any processes dependencies lists are then terminated. On [[New_3DS]], the only New3DS-specific system-module which automatically gets loaded during system boot is qtm.
All of the below system modules use the "BASE" [[SVC|memory-region]](specified in the exheader), except when listed otherwise for certain modules.
When handling the exheader dependency list starting with [[8.0.0-18]], Old3DS FIRM [[Process_Manager_Services|PM]]-module now skips handling titles in this list which have any bits in programID-low bitmask 0xF0000000 set(with [[8.0.0-18]] this is hard-coded).
The exheader dependency list handling change is for the [[New 3DS]] system-module(s), which do not exist on Old3DS.
When the New3DS pm-module is launching any title except [[NS]], it first attempts to launch the title with programID-low bitmask 0x20000000 set, then with that bitmask clear if launching fails.

{| class="wikitable sortable" border="1"
|-
! TitleID Low
! Description
! Versions
|-
| 00001002
| [[Services|sm]] (Stored in [[FIRM|NATIVE_FIRM]])
| N/A
|-
| 00001003
| SAFE_MODE [[Services|sm]] (Stored in SAFE_MODE NATIVE_FIRM)
| N/A
|-
| 00001102
| [[Filesystem services‎|fs]] (Stored in [[FIRM|NATIVE_FIRM]])
| N/A
|-
| 00001103
| SAFE_MODE [[Filesystem services‎|fs]] (Stored in SAFE_MODE NATIVE_FIRM)
| N/A
|-
| 00001202
| [[Process Manager Services|pm]] (Stored in [[FIRM|NATIVE_FIRM]])
| N/A
|-
| 00001203
| SAFE_MODE [[Process Manager Services|pm]] (Stored in SAFE_MODE NATIVE_FIRM)
| N/A
|-
| 00001302
| [[Loader Services‎|loader]] (Stored in [[FIRM|NATIVE_FIRM]])
| N/A
|-
| 00001303
| SAFE_MODE [[Loader Services‎|loader]] (Stored in SAFE_MODE NATIVE_FIRM)
| N/A
|-
| 00001402
| [[PXI Services‎|pxi]] (Stored in [[FIRM|NATIVE_FIRM]])
| N/A
|-
| 00001403
| SAFE_MODE [[PXI Services‎|pxi]] (Stored in SAFE_MODE NATIVE_FIRM)
| N/A
|-
| 00001502
| [[Application Manager Services|AM]] ( Application Manager )
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2053]], [[4.0.0-7|v3072]], [[5.0.0-11|v4098]], [[6.0.0-11|v5120]], [[8.0.0-18|v6148]], [[8.1.0-0_New3DS|v7168]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v8192]], [[10.0.0-27|v9217]]
|-
| 00001503
| SAFE_MODE [[Application Manager Services|AM]]
| [[1.0.0-0|v0]]
|-
| 20001503
| [[New_3DS]] SAFE_MODE [[Application Manager Services|AM]]
| [[8.1.0-0_New3DS|v7169]]
|-
| 00001602
| [[Camera Services|Camera]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2048]], [[4.0.0-7|v3074]], [[5.0.0-11|v4098]], [[6.0.0-11|v5120]], [[7.1.0-14|v6146]], [[8.0.0-18|v7172]], [[9.0.0-20|v9216]], [[9.3.0-21|v10242]], [[10.0.0-27|v11265]]
|-
| 20001602
| [[New_3DS]] [[Camera Services|Camera]]
| [[8.1.0-0_New3DS|v8200]], [[9.0.0-20|v9218]], [[9.3.0-21|v10242]], [[10.0.0-27|v11265]], [[11.4.0-37|v12288]](New2DSXL)
|-
| 00001702
| [[Config Services|Config]] (cfg)
| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[3.0.0-5|v2049]], v3072, [[4.0.0-7|v4096]], [[5.0.0-11|v5122]], [[6.0.0-11|v6145]], [[6.1.0-11|v7168]], [[7.0.0-13|v8196]], [[7.2.0-17|v9220]], [[8.0.0-18|v10243]], [[8.1.0-0_New3DS|v11265]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v12290]], [[9.3.0-21|v13315]], [[9.6.0-24|v14342]], [[11.4.0-37|v15360]](New2DSXL)[[11.5.0-38|v15360]]
|-
| 00001703
| SAFE_MODE [[Config Services|Config]] (cfg)
| [[1.0.0-0|v0]]
|-
| 20001703
| [[New_3DS]] SAFE_MODE [[Config Services|Config]] (cfg)
| [[8.1.0-0_New3DS|v11265]]
|-
| 00001802
| [[Codec Services|Codec]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[5.0.0-11|v4098]], [[7.0.0-13|v5120]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]](Also for [[8.1.0-0_New3DS]])
|-
| 00001803
| SAFE_MODE [[Codec Services|Codec]]
| [[1.0.0-0|v0]]
|-
| 20001803
| [[New_3DS]] SAFE_MODE [[Codec Services|Codec]]
| [[8.1.0-0_New3DS|v7169]]
|-
| 00001A02
| [[DSP Services|DSP]]
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[4.0.0-7|v2048]], [[5.0.0-11|v3074]], [[6.0.0-11|v4096]], [[8.0.0-18|v5120]], [[9.7.0-25|v6145]], [[11.1.0-34|v7169]]
|-
| 00001A03
| SAFE_MODE [[DSP Services|DSP]]
| [[1.0.0-0|v0]]
|-
| 20001A03
| [[New_3DS]] SAFE_MODE [[DSP Services|DSP]]
| [[8.1.0-0_New3DS|v6145]]
|-
| 00001B02
| [[GPIO Services|GPIO]]
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]], [[9.5.0-22|v3073]]
|-
| 00001B03
| SAFE_MODE [[GPIO Services|GPIO]]
| [[1.0.0-0|v0]]
|-
| 20001B03
| [[New_3DS]] SAFE_MODE [[GPIO Services|GPIO]]
| [[8.1.0-0_New3DS|v3073]]
|-
| 00001C02
| [[GSP Services|GSP]]
| [[1.0.0-0|v0]], [[1.1.0-1|v1040]], [[2.0.0-2|v2049]], [[3.0.0-5|v3075]], v4098, [[4.0.0-7|v5120]], [[5.0.0-11|v6145]], [[6.0.0-11|v7168]], [[8.0.0-18|v8196]], [[9.0.0-20|v10240]], [[9.3.0-21|v11264]], [[9.6.0-24|v12294]], [[11.3.0-36|v13312]], [[11.5.0-38|v14336]]
|-
| 20001C02
| [[New_3DS]] [[GSP Services|GSP]]
| [[8.1.0-0_New3DS|v10243]], [[9.3.0-21|v11267]], [[9.6.0-24|v12294]], [[11.3.0-36|v13312]], [[11.4.0-37|v14336]](New2DSXL)
|-
| 00001C03
| SAFE_MODE [[GSP Services|GSP]]
| [[1.0.0-0|v0]]
|-
| 20001C03
| [[New_3DS]] SAFE_MODE [[GSP Services|GSP]]
| [[8.1.0-0_New3DS|v9217]]
|-
| 00001D02
| [[HID Services|HID]] (Human Interface Devices)
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[7.2.0-17|v6148]], [[8.0.0-18|v7168]], [[8.1.0-0_New3DS|v8192]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v9216]], [[9.3.0-21|v10240]]
|-
| 00001D03
| SAFE_MODE [[HID Services|HID]]
| [[1.0.0-0|v0]]
|-
| 20001D03
| [[New_3DS]] SAFE_MODE [[HID Services|HID]]
| [[8.1.0-0_New3DS|v8193]]
|-
| 00001E02
| [[I2C Services|i2c]]
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[5.0.0-11|v2049]], [[8.0.0-18|v3076]], [[9.3.0-21|v5120]]
|-
| 20001E02
| [[New_3DS]] [[I2C Services|i2c]]
| [[8.1.0-0_New3DS|v4096]], [[9.3.0-21|v5121]]
|-
| 00001E03
| SAFE_MODE [[I2C Services|i2c]]
| [[1.0.0-0|v0]]
|-
| 20001E03
| [[New_3DS]] SAFE_MODE [[I2C Services|i2c]]
| [[8.1.0-0_New3DS|v4097]]
|-
| 00001F02
| [[MCU Services|MCU]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.1.0-3|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4102]], [[5.0.0-11|v5122]], [[6.0.0-11|v6145]], [[7.0.0-13|v7168]], [[8.0.0-18|v8192]]
|-
| 20001F02
| [[New_3DS]] [[MCU Services|MCU]]
| [[8.1.0-0_New3DS|v8192]], [[11.4.0-37|v9216]](New2DSXL)
|-
| 00001F03
| SAFE_MODE [[MCU Services|MCU]]
| [[1.0.0-0|v0]]
|-
| 20001F03
| [[New_3DS]] SAFE_MODE [[MCU Services|MCU]]
| [[8.1.0-0_New3DS|v9217]]
|-
| 00002002
| [[MIC Services|MIC]] (Microphone)
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]
|-
| 00002102
| [[PDN Services|PDN]]
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]
|-
| 00002103
| SAFE_MODE [[PDN Services|PDN]]
| [[1.0.0-0|v0]]
|-
| 20002103
| [[New_3DS]] SAFE_MODE [[PDN Services|PDN]]
| [[8.1.0-0_New3DS|v3073]]
|-
| 00002202
| [[PTM Services|PTM]] (Play time, pedometer, and battery manager)
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3075]], v4096, [[4.0.0-7|v5120]], [[5.0.0-11|v6146]], [[6.0.0-11|v7168]], [[7.0.0-13|v8192]], [[8.0.0-18|v9219]], [[9.6.0-24|v11264]]
|-
| 20002202
| [[New_3DS]] [[PTM Services|PTM]] (Play time, pedometer, and battery manager)
| [[8.1.0-0_New3DS|v10240]], [[9.6.0-24|v11264]]
|-
| 00002203
| SAFE_MODE [[PTM Services|PTM]]
| [[1.0.0-0|v0]]
|-
| 20002203
| [[New_3DS]] SAFE_MODE [[PTM Services|PTM]]
| [[8.1.0-0_New3DS|v10241]]
|-
| 00002302
| [[SPI Services|spi]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[5.0.0-11|v2049]], [[8.0.0-18|v3072]]
|-
| 20002302
| [[New_3DS]] [[SPI Services|spi]]
| [[8.1.0-0_New3DS|v4096]]
|-
| 00002303
| SAFE_MODE [[SPI Services|spi]]
| [[1.0.0-0|v0]]
|-
| 20002303
| [[New_3DS]] SAFE_MODE [[SPI Services|spi]]
| [[8.1.0-0_New3DS|v4097]]
|-
| 00002402
| [[AC Services|AC]] (Network manager)
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2052]], [[2.1.0-3|v3072]], [[3.0.0-5|v4101]], [[5.0.0-11|v5122]], [[7.0.0-13|v6145]], [[8.0.0-18|v7172]], [[9.0.0-20|v8192]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v9216]]
|-
| 00002403
| SAFE_MODE [[AC Services|AC]]
| [[1.0.0-0|v0]]
|-
| 20002403
| [[New_3DS]] SAFE_MODE [[AC Services|AC]]
| [[8.1.0-0_New3DS|v8193]]
|-
| 00002602
| [[CECD Services|Cecd]] (StreetPass)
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3073]], [[4.0.0-7|v4097]], [[5.0.0-11|v5122]], [[6.0.0-11|v6144]], [[6.2.0-12|v7170]], [[7.0.0-13|v8193]], [[8.0.0-18|v9216]], [[9.0.0-20|v10240]]
|-
| 00002702
| [[CSND Services|CSND]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[4.0.0-7|v2048]], [[5.0.0-11|v3073]], [[8.0.0-18|v4096]], [[9.0.0-20|v5120]]
|-
| 00002703
| SAFE_MODE [[CSND Services|CSND]]
| [[1.0.0-0|v0]]
|-
| 20002703
| [[New_3DS]] SAFE_MODE [[CSND Services|CSND]]
| [[8.1.0-0_New3DS|v5121]]
|-
| 00002802
| [[DLP Services|DLP]] ([[Download Play]])
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3078]], [[5.0.0-11|v4099]], [[8.0.0-18|v5123]], [[9.0.0-20|v6145]](Also for [[8.1.0-0_New3DS]]), [[9.6.0-24|v7174]], [[10.0.0-27|v8192]]
|-
| 00002902
| [[HTTP Services|HTTP]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.1.0-3|v2049]], [[2.2.0-X|v3072]], [[3.0.0-5|v4099]], [[4.0.0-7|v5122]], [[5.0.0-11|v6145]], [[7.0.0-13|v7171]], [[7.1.0-14|v8192]], [[8.0.0-18|v9220]], [[8.1.0-18|v10245]], [[8.1.0-0_New3DS|v11264]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v12288]], [[9.6.0-24|v13318]], [[11.4.0-37|v14336]]
|-
| 00002903
| SAFE_MODE [[HTTP Services|HTTP]]
| [[1.0.0-0|v0]]
|-
| 20002903
| [[New_3DS]] SAFE_MODE [[HTTP Services|HTTP]]
| [[8.1.0-0_New3DS|v10241]]
|-
| 00002A02
| [[MP Services|MP]]
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]
|-
| 00002A03
| SAFE_MODE [[MP Services|MP]]
| [[1.0.0-0|v0]]
|-
| 00002B02
| [[NDM Services|NDM]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[5.0.0-11|v4098]], [[8.0.0-18|v5124]], [[8.1.0-0_New3DS|v6144]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v7169]]
|-
| 00002C02
| [[NIM Services|NIM]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[3.0.0-5|v2055]], [[4.0.0-7|v3074]], [[5.0.0-11|v4100]], [[6.0.0-11|v5120]], [[7.0.0-13|v6148]], [[7.2.0-17|v7174]], [[8.0.0-18|v8195]], [[8.1.0-0_New3DS|v9217]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v10249]], [[9.3.0-21|v11267]], [[9.6.0-24|v12296]], [[10.0.0-27|v13313]]
|-
| 00002C03
| SAFE_MODE [[NIM Services|NIM]]
| [[1.0.0-0|v0]]
|-
| 20002C03
| [[New_3DS]] SAFE_MODE [[NIM Services|NIM]]
| [[8.1.0-0_New3DS|v9217]]
|-
| 00002D02
| [[NWM Services|NWM]] ( Low-level wifi manager )
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2052]], [[2.2.0-X|v3072]], [[3.0.0-5|v4101]], [[4.0.0-7|v5120]], [[5.0.0-11|v6148]], [[6.0.0-11|v7169]], [[7.2.0-17|v8196]], [[8.0.0-18|v9216]], [[9.0.0-20|v10240]]
|-
| 00002D03
| SAFE_MODE [[NWM Services|NWM]]
| [[1.0.0-0|v0]], [[6.0.0-11|v5120]]
|-
| 20002D03
| [[New_3DS]] SAFE_MODE [[NWM Services|NWM]]
| [[8.1.0-0_New3DS|v10241]]
|-
| 00002E02
| [[Socket Services|Sockets]]
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2053]], [[3.0.0-5|v3075]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]], [[10.6.0-31|v8192]]
|-
| 00002E03
| SAFE_MODE [[Socket Services|Sockets]]
| [[1.0.0-0|v0]]
|-
| 20002E03
| [[New_3DS]] SAFE_MODE [[Socket Services|Sockets]]
| [[8.1.0-0_New3DS|v7169]]
|-
| 00002F02
| [[SSL Services|SSL]]
| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[2.1.0-3|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5122]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]], [[9.6.0-24|v8198]]
|-
| 00002F03
| SAFE_MODE [[SSL Services|SSL]]
| [[1.0.0-0|v0]]
|-
| 20002F03
| [[New_3DS]] SAFE_MODE [[SSL Services|SSL]]
| [[8.1.0-0_New3DS|v7169]]
|-
| 00003000
| [[FIRM|Process9]] (in SAFE_MODE and normal NATIVE_FIRM)
|
|-
| 00003102
| [[Process Services‎|PS]] ( Process Manager )
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[5.0.0-11|v2049]], [[6.0.0-11|v3072]], [[8.0.0-18|v4096]], [[9.0.0-20|v5120]]
|-
| 00003103
| SAFE_MODE [[Process Services‎|PS]]
| [[1.0.0-0|v0]]
|-
| 20003103
| [[New_3DS]] SAFE_MODE [[Process Services‎|PS]]
| [[8.1.0-0_New3DS|v5121]]
|-
| 00003202
| [[Friend Services‎|friends]] (Friends list)
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5122]], [[7.0.0-13|v6145]], [[8.0.0-18|v7172]], [[9.0.0-20|v8192]](Also for [[8.1.0-0_New3DS]]), [[10.5.0-30|v9216]], [[10.7.0-32|v10240]], [[11.0.0-33|v11264]], [[11.1.0-34|v12288]], [[11.2.0-35|v13312]], [[11.3.0-36|v14336]], [[11.4.0-37|v15360]]
|-
| 00003203
| SAFE_MODE [[Friend Services‎|friends]] (Friends list)
| [[1.0.0-0|v0]]
|-
| 20003203
| [[New_3DS]] SAFE_MODE [[Friend Services‎|friends]] (Friends list)
| [[8.1.0-0_New3DS|v8193]]
|-
| 00003302
| [[IR Services‎|IR]] (Infrared)
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[8.0.0-18|v6148]], [[8.1.0-0_New3DS|v7170]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v8192]], [[9.3.0-21|v9216]], [[9.6.0-24|v10246]], [[10.0.0-27|v11265]], [[10.6.0-31|v12289]]
|-
| 00003303
| SAFE_MODE [[IR Services‎|IR]]
| [[1.0.0-0|v0]]
|-
| 20003303
| [[New_3DS]] SAFE_MODE [[IR Services‎|IR]]
| [[8.1.0-0_New3DS|v7169]]
|-
| 00003402
| [[BOSS Services‎|BOSS]] (SpotPass)
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2053]], [[2.2.0-X|v3073]], [[3.0.0-5|v4101]], [[4.0.0-7|v5122]], [[5.0.0-11|v6146]], [[6.0.0-11|v7169]], [[6.2.0-12|v8193]], [[7.0.0-13|v9222]], [[8.0.0-18|v10240]], [[9.0.0-20|v11266]], [[10.0.0-27|v12289]], [[10.4.0-29|v13314]]
|-
| 00003502
| [[News Services‎|News]] (Notifications)
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[5.0.0-11|v4097]], [[8.0.0-18|v5120]], [[9.0.0-20|v6147]], [[9.7.0-25|v7168]]
|-
| 00003702
| [[RO_Services|RO]]
| [[2.0.0-2|v0]], [[4.0.0-7|v1024]], [[5.0.0-11|v2049]], [[7.2.0-17|v3074]], [[8.0.0-18|v4096]], [[9.0.0-20|v5120]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v6148]]
|-
| 00003802
| [[ACT Services‎|act]] (handles Nintendo Network '''a'''c'''c'''oun'''t'''s)
| [[7.0.0-13|v1029]], [[7.1.0-14|v2050]], [[7.2.0-17|v3077]], [[8.0.0-18|v4099]], [[8.1.0-0_New3DS|v5120]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v6144]], [[9.3.0-21|v7168]], [[9.6.0-24|v8198]], [[11.4.0-37|v9216]](New2DSXL), [[11.5.0-38|v9216]]
|-
| 00004002
| Old3DS [[NFC_Services|nfc]]
| [[9.3.0-21|v2053]], [[9.6.0-24|v4106]], [[9.7.0-25|v5121]], [[10.0.0-27|v6145]], [[10.6.0-31|v7168]], [[10.7.0-32|v8192]]
|-
| 20004002
| [[New_3DS]] [[NFC_Services|nfc]]
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1024]], [[9.3.0-21|v2053]], [[9.5.0-22|v3073]], [[9.6.0-24|v4102]], [[10.0.0-27|v6145]], [[10.6.0-31|v7168]]
|-
| 20004102
| [[New_3DS]] [[MVD Services|mvd]]
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1024]]
|-
| 20004202
| [[New_3DS]] [[QTM Services|qtm]]
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]], [[9.3.0-21|v2052]], [[11.4.0-37|v3072]](New2DSXL)
|-
| 00008002
| [[NS]] (Memory-region: "SYSTEM")
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[2.2.0-X|v2048]], [[3.0.0-5|v3077]], v4096, [[4.0.0-7|v5121]], [[5.0.0-11|v6148]], [[5.1.0-11|v7168]], [[6.0.0-11|v8193]], [[6.1.0-11|v9216]], [[7.0.0-13|v10248]], [[7.2.0-17|v11268]], [[8.0.0-18|v12291]], [[8.1.0-0_New3DS|v13312]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v14336]], [[9.3.0-21|v15360]], [[9.6.0-24|v16390]], [[9.8.0-25|v17408]], [[10.0.0-27|v18433]], [[10.4.0-29|v19458]], [[11.1.0-34|v20482]], [[11.3.0-36|v21504]]
|-
| 00008003
| SAFE_MODE [[NS]] (Memory-region: "SYSTEM")
| [[1.0.0-0|v0]]
|-
| 20008003
| [[New_3DS]] SAFE_MODE [[NS]] (Memory-region: "SYSTEM")
| [[8.1.0-0_New3DS|v13313]]
|}

=== 00040138 - [[FIRM|System Firmware]] ===
==== System Firmare Notes ====
NATIVE_FIRM and SAFE_MODE_FIRM for the initial versions are exactly the same, besides [[Configuration_Memory|core-version]] fields. SAFE_MODE_FIRM is used for running SAFE_MODE titles, on retail SAFE_MODE_FIRM seems to be only used for running the [[System_Settings#System_Updater|System Updater]] application. When a GBA VC title is launched, AGB_FIRM is launched to handle running this title. GBA VC savegames stored under SD card /title/<TID>/data use a custom format, this is handled by AGB_FIRM.

{| class="wikitable sortable" border="1"
|-
! TitleID Low
! Description
! USA/EUR/JPN Versions
! CHN Versions
! KOR Versions
! TWN Versions
|-
| 00000001
| Unknown, very similar to SAFE_MODE_FIRM. Exists only on dev units and seems to only be used by SystemUpdaters.
| v0
|
|
|
|-
| 00000002
| NATIVE_FIRM (Native Firmware)
| [[1.0.0-0|v432]], [[1.1.0-1|v1472]], [[2.0.0-2|v2516]], [[2.1.0-3|v3553]], [[2.2.0-X|v4595]], [[3.0.0-5|v5647]], [[4.0.0-7|v6677]], [[4.1.0-8|v7712]], [[5.0.0-11|v8758]], [[5.1.0-11|v9792]], [[6.0.0-11|v10833]], [[6.1.0-11|v11872]], [[7.0.0-13|v12916]], [[7.2.0-17|v13956]], v15043, [[8.0.0-18|v15047]], [[9.0.0-20|v17120]], [[9.3.0-21|v18182]], [[9.5.0-22|v19216]], [[9.6.0-24|v20262]], [[10.0.0-27|v21288]], [[10.2.0-28|v22313]], [[10.4.0-29|v23341]], [[11.0.0-33|v24368]], [[11.1.0-34|v25396]], [[11.2.0-35|v26432]], [[11.3.0-36|v27476]]
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version
| Same as CHN.
| Same as CHN.
|-
| 20000002
| [[New_3DS]] NATIVE_FIRM (Native Firmware)
| [[8.1.0-0_New3DS|v16085]], [[9.0.0-20|v17120]], [[9.3.0-21|v18182]], [[9.5.0-22|v19218]], [[9.6.0-24|v20262]], [[10.0.0-27|v21288]], [[10.2.0-28|v22313]], [[10.4.0-29|v23341]], [[11.0.0-33|v24368]], [[11.1.0-34|v25396]], [[11.2.0-35|v26432]], [[11.3.0-36|v27476]]
| N/A
| Same as CHN.
| Same as CHN.
|-
| 00000003
| SAFE_MODE_FIRM
| [[1.0.0-0|v432]], [[3.0.0-5|v5632]]
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[3.0.0-5]] title-version
| Same as CHN.
| Same as CHN.
|-
| 20000003
| [[New_3DS]] SAFE_MODE_FIRM
| [[8.1.0-0_New3DS|v16081]]
| N/A
| Same as CHN.
| Same as CHN.
|-
| 00000102
| TWL_FIRM ( DSi Firmware )
| [[1.0.0-0|v432]], [[2.0.0-2|v1489]], [[3.0.0-5|v2565]], v3601, [[4.0.0-7|v4625]], [[4.4.0-10|v5681]], [[4.5.0-10|v6704]], [[6.0.0-11|v7762]], [[6.2.0-12|v8817]]
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version
| Same as CHN.
| Same as CHN.
|-
| 20000102
| [[New_3DS]] TWL_FIRM ( DSi Firmware )
| [[8.1.0-0_New3DS|v9936]]
| N/A
| Same as CHN.
| Same as CHN.
|-
| 00000202
| AGB_FIRM ( GBA Firmware )
| [[3.0.0-5|v519]], v1553, [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]
| [[4.0.0-7|v2576]]
| [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]
| Same as CHN.
|-
| 20000202
| [[New_3DS]] AGB_FIRM ( GBA Firmware )
| [[8.1.0-0_New3DS|v4816]]
| N/A
| N/A
| N/A
|}

== Application Titles ==
{| class="wikitable sortable" border="1"
|-
! Category Bit Mask
! Content Category
! Bit Mask(s)
|-
| 0x0000
| [[Title list/eShop Titles|Application / eShop]]
| Normal
|-
| 0x0001
| Download Play Child
| DlpChild
|-
| 0x0002
| [[EShop Demos|Demo]]
| Demo
|-
| 0x000E
| [[Title list/Patches|Patch]]
| CannotExecution<nowiki> | </nowiki>Patch
|-
| 0x008C
| [[Title list/DLC|Downloadable Content]]
| NotRequireRightForMount<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>AddOnContents
|}

=== 00040001 - [[Download Play]] Titles ===
==== Download Play Notes ====
This titleID-high/programID-high is used for the titles sent over [[Download Play]]. Only one 00040001 Download Play title is installed to NAND /title at a time. There can be a maximum of 255 Download Play child titles per Unique ID, indexed by Title ID Variation. The legal index range: 0x0 - 0xff.

== Factory Titles ==
==== Factory Titles Notes ====
This section is for hard-coded titleIDs referenced in codebins on retail. This can include [[Factory_Setup|factory]]/[[Nintendo_Service_Center_Tools|repair]] titles as well.

{| class="wikitable sortable" border="1"
|-
! TitleID
! Description
! Versions
|-
| 000400000F802A00
| Unknown. Appears to be a [[9.8.0-25|gamecard]] title. See also [[11.3.0-36|here]].
Used during [[Nintendo_Service_Center_Tools|repair]], first non-system title listed in [[PTM_Services|playlog]] from repair.
| ?
|-
| 000400000F802100
| Used during [[Nintendo_Service_Center_Tools|repair]], second non-system title listed in [[PTM_Services|playlog]] from repair.
| ?
|-
| 000400000F802200
| Used during [[Nintendo_Service_Center_Tools|repair]], third non-system title listed in [[PTM_Services|playlog]] from repair.
| ?
|-
| 000400000FFFFD00
| Used by retail NS for appID 0xF11, but this isn't available on retail CDN.
| ?
|-
| 000400000FFFFC00
| Used by retail NS for appID 0xF12, but this isn't available on retail CDN.
| ?
|-
| 000400000FFFFB00
| Used by retail NS for appID 0xF13, but this isn't available on retail CDN.
| ?
|-
| 000400000FFFF900
| Used by retail NS for appID 0xF14, but this isn't available on retail CDN.
| ?
|-
| 000400000FFFF800
| Used by retail NS for appID 0xF15, but this isn't available on retail CDN.
| ?
|-
| 000400000FFFF700
| Used by retail NS for appID 0xF16, but this isn't available on retail CDN.
| ?
|-
| 000400000FFFF600
| Used by retail NS for appID 0xF17, but this isn't available on retail CDN.
| ?
|-
| 000400000FFFF500
| Used by retail NS for appID 0xF18, but this isn't available on retail CDN.
| ?
|-
| 0004003000008900
| Used by retail NS for appID 0xF10, but this isn't available on retail CDN.
| ?
|-
| 0004013000001902
| dmnt, debugger sysmodule. This use devunit-only HIO for devunit<>pc comms. This only exists for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields' values).
This is installed at the [[Factory_Setup|factory]], then later deleted at the factory on retail units.
| ?
|-
| 0004013000003602
| "debugger". This only exist for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields' values).
| ?
|-
| 000401300FEF0000
| Referenced in eShop Metadata (NS_UID 50010000000584), but does not exist on retail CDN
|}

== TWL (DSi) Titles ==
==== TWL Title Notes ====
Bitmask 0x1 for TWL titles denotes a system title (determining whether the title will be updated during a System Update).

It appears to be sufficient, but not necessary, to make the title invisible on the [[Home Menu]].

Bitmask 0x2 for TWL titles may indicate no-execute.

Bitmask 0x4 for TWL titles indicates internal storage.

Bitmask 0x10 for TWL titles is found on developer tools.

{| class="wikitable sortable" border="1"
|-
! Content Category
! Bit Mask(s)
! Category Bit Mask
|-
| Application (DSiWare)
| TWL<nowiki> | </nowiki>0x4
| 0x8004
|-
| System Application
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x4
| 0x8005
|-
| System Archive
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x2<nowiki> | </nowiki>0x4<nowiki> | </nowiki>0x8
| 0x800F
|-
| Developer Tool
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x4<nowiki> | </nowiki>0x10
| 0x8015
|}

=== 00048005 - System Applications===
{| class="wikitable sortable" border="1"
|-
! TitleID Low
! Region
! Description
! Versions
! Information
|-
| 42383841(B88A)
| ALL
| [[DS Internet]]
| v0, [[2.1.0-4|v1025]], [[3.0.0-5|v2048]]
| [[DS Internet]] is the DS-mode application, (also integrated in every online-enabled DS game) and now accessible through [[System Settings]] for configuring network settings for DS software.
|-
| 484E4441(HNDA)
| ALL
| [[Download Play]]
| v1024
| This [[Download Play]] application is the DS-mode Download Play client, launched by the 3DS-mode Download Play application.
|-
| 484E4443(HNDC)
| CHN
| [[Download Play]]
| v1024
| See Above Description.
|-
| 484E444B(HNDK)
| KOR
| [[Download Play]]
| v1024
| See Above Description.
|}

=== 0004800F - System Data Archives===
==== System Data Archive Notes ====
New system updates only block DS flash-cards when whitelist is updated, or when TWL_FIRM is updated.
The whitelist contains the data used for detecting flash-cards, this is used by TWL_FIRM.

{| class="wikitable sortable" border="1"
|-
! TitleID Low
! Description
! Versions
|-
| 484E4841(HNHA)
| [[Nintendo DS Cart Whitelist]] -
| v0, [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[4.2.0-9|v5120]], [[4.3.0-10|v6145]], [[4.4.0-10|v7168]], [[4.5.0-10|v8192]], [[5.0.0-11|v9216]], [[6.0.0-11|v10240]], [[7.0.0-13|v11264]]
|-
| 484E4C41(HNLA)
| [[Version Data]]
| v0
|}

=== 00048004 - DSiWare Ports ===
==== DSiWare Port Notes ====
Although these have a titleID high separate from DSi and a titleID is stored in the SRLs, the content of these SRLs are identical to DSi.
See [[3DS DSiWare Titles]] for a complete list.

3DS Userland Flaws

2020-10-04T11:09:38Z

EvilFlight:

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| App: v1.1
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| Citizens of Earth
| Save file read stack smash
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.
| None
| [[10.7.0-32]].
| Time of exploit release.
| May 5, 2016
| [[User:Dazzozo|Dazzozo]]
|-
| SmileBASIC 3.x
| Poor parameter validation on "BGSCREEN" command
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| SmileBASIC 3.x
| Subscripted TIME$/DATE$ allow write access to DATA/BSS
| Utf-16 characters can be assigned to subscripted TIME$/DATE$ interpreter sysvars which results in write-only access to all of DATA and some BSS in userland.
TIME$[0]/DATE$[0] actually point to somewhere in rodata, and an overly large subscript can be used to write well past it and into the aforementioned areas. Demo [https://github.com/zoogie/smilehax-IIe here.]
| App: 3.6.2 (3.6.0 latest for US/EU, JP appvers. can be downgraded)
| System: [[11.13.0-45]].
| April 2020
| February 2020
| bug publicly documented [https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fsmilebasic.com%2Fdebug%2Farchive%2F here.]
Exploited by Zoogie
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]], [[User: ChampionLeake|ChampionLeake]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|-
| Mononoke Forest
| String Buffer Overflow via unchecked string length
| The game stores plaintext profile names in the savefile. The profile names are strcpy/memcpy to different areas of the game's functions in the stack. Using a large extensive profile name, a user can overwrite some stack-registers and point to stack buffer addresses to eventually gain control of the stack to lead and form a rop-chain.
| None
| App: v1.0.0
| August 14, 2019
| February 8, 2019
| [[User: ChampionLeake|ChampionLeake]] and [[User: Kartik|Kartik]]
|-
| Picross 3D: Round 2
| Out of bounds array access allowing to point to fabricated objects and vtable
| Game only checks save header. With the last interacted save slot index at +0xb270 in the save data unchecked we can achieve a predictable out of bounds access, as well inserting ROP data without detecting save corruption. Game references an object from an array of 3 elements and passes it to a function that will read object pointers and hit a vtable call. With a copy save data left in memory and a properly calculated index, we can point to a fake object position in the save, vtable jump to a stack pivot and start the ROP chain.
| None
| App: Initial version
| September 10, 2020
| August 24, 2020
| [[User: Luigoalma|Luigoalma]] and [[User: Kartik|Kartik]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

* [[Pyramids (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [[Pyramids 2 (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.

* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.

* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.

* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.

* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.

* "Mutant Mudds": Overwriting the savefile with random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.

* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.

* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.

* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls

==Crashes needing investigation==
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|-
| 3DS [[System Settings]] stack smash via title strings in [[DSiWare_Exports]]
| DSiWare export banners contain 16 consecutive 0x100 byte, utf-16 game title strings for different languages. Nintendo correctly limits the string's max length by placing a NULL at str[127] before it's copied to the stack. However, they didn't allocate enough space for all 128 wchars (char/wchar type confusion?), so an attacker can craft a valid full-length string that will crash the stack at about str+0xEC. ROP execution can then be obtained from this crash in DSiWare Data Management as demonstrated [https://github.com/zoogie/Bannerbomb3 here].

Interesting note: A line feed wchar (00 0A) at any point in the string before the crash offset will prevent the crash from occurring.
| None
| [[11.13.0-45]]
| Dec. 2018
| Zoogie
|-
| 3DS SAFE_MODE [https://www.3dbrew.org/wiki/System_Settings#System_Updater System Updater] stack smash from proxy-url string
| During [[Recovery Mode]] and after all 3 wifi slots fail to find an access point for sysupdate, a user is permitted to access the wifi settings mode to make changes. Here, if the proxy-url field string's NULL terminator had been altered beforehand, a stack smash can occur when the user selects Proxy Settings -> Detailed Setup and the corrupted url string is displayed.

This is a difficult crash to control because the url string is converted from ascii to utf-16 between the slot and stack, effectively reducing the available gadgets to 0.4% of the normal amount. It's possible to improvise an "escape" using an eoreq pc w/shift gadget to combine registers and form a jump that can access 1/2 of all available gadgets.

Because this exploit runs *under* SAFE_MODE, it's possible to run safehax with one's choice of k11 and arm9 hax. Prerequisite: a userland exploit with cfg:s/i access to modify the wifi slot. A demonstration can be viewed [https://github.com/zoogie/unSAFE_MODE here].
| None
| [[11.13.0-45]]
| Jan. 2020
| Zoogie
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.

This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| [[10.7.0-32|10.7.0-32]]
|
| [[9.9.0-26|9.9.0-26]]
| February 25, 2016
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| u8 brightness setting OOB index (menuhax67)
| Config block 0x50001, which contains a u8 brightness setting that indexes a table of u32 addresses, can be set to an out-of-bounds index (it's normally 1-5). Located within cfg block 0x50009, there exists a single controllable u32 that's located within the u8's range. With these set properly, one can eventually redirect a function pointer to an address of their choice. This is triggered after the Home Menu quick launch tab is activated. POC [https://github.com/zoogie/menuhax67 here].
| None
| [[11.13.0-45]]
|
| October 4, 2020
| September, 2020
| Zoogie
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| Theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| <Old3DS/New3DS version which added initial theme support>
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| Shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
| [[9.3.0-21|9.3.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[5.0.0-11|5.0.0-X]]
|
| [[2.0.0-2|2.0.0-X]]
| June 9, 2016
| June 9, 2016
| [[User:Yellows8|Yellows8]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

Filesystem services

2020-07-28T08:32:40Z

EvilFlight: /* IntegrityVerificationSeed */

[[Category:Services]]

= Services =
== Filesystem service "fs:USER" ==
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|Control]]
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|SetOtherSaveDataSecureValue
| 00121004
|-
| 0x086C00C2
|?
|GetOtherSaveDataSecureValue
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|SetThisSaveDataSecureValue
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|GetThisSaveDataSecureValue
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 0x00200000
|-
| 0x087B....
| [[9.6.0-24|9.6.0-X]]
| Wrapper for the code internally used for command <0x087A....>.
| 0x00200000
|-
| 0x087C....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| GetNumSeeds. Writes the number of seeds to cmdreply[2]
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0881....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x08840042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

== Filesystem service "fs:LDR" ==
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

== ProgramRegistry service "fs:REG" ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSFile:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[FSFile:Control|Control]]
|-
| 0x08010100
| [[FSFile:OpenSubFile|OpenSubFile]]
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| [[FSFile:GetAttributes|GetAttributes]]
|-
| 0x08070040
| [[FSFile:SetAttributes|SetAttributes]]
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| [[FSFile:Flush|Flush]]
|-
| 0x080A0040
| [[FSFile:SetPriority|SetPriority]]
|-
| 0x080B0000
| [[FSFile:GetPriority|GetPriority]]
|-
| 0x080C0000
| [[FSFile:OpenLinkFile|OpenLinkFile]]
|-
| 0x0C010100
| [[FSFile:GetAvailable|GetAvailable]]
|}

==Directories==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| [[FSDir:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[1.0.0-0]]
| [[FSDir:Control|Control]]
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| [[FSDir:SetPriority|SetPriority]]
|-
| 0x08040000
| ?
| [[FSDir:GetPriority|GetPriority]]
|}

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>0xFFFFFF00 | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 3
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CBC using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

FSPXI:ImportIntegrityVerificationSeed

2020-07-28T08:31:35Z

EvilFlight:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00450002]
|-
| 1
| Always 0x00013006, for 0x130 size: (size<<8) <nowiki>|</nowiki> 6
|-
| 2
| Input IntegrityVerificationSeed pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=IntegrityVerificationSeed=
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CBC using the above MAC for the counter.
|}

=Description=
This decrypts the input SEED and verifies it with the input AES-CBC MAC, verifies the RSA-signature, then writes the data to [[nand/private/movable.sed]].

AES Registers

2020-07-28T08:30:00Z

EvilFlight:

== Registers ==
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! RW
|-
| style="background: green" | Yes
| [[#AES_CNT|AES_CNT]]
| 0x10009000
| 4
| RW
|-
| style="background: green" | Yes
| [[#AES_MACEXTRABLKCNT|AES_MACBLKCNT]]
| 0x10009004
| 2
| W
|-
| style="background: green" | Yes
| [[#AES_BLKCNT|AES_BLKCNT]]
| 0x10009006
| 2
| W
|-
| style="background: green" | Yes
| [[#AES_WRFIFO/AES_RDFIFO|AES_WRFIFO]]
| 0x10009008
| 4
| W
|-
| style="background: green" | Yes
| [[#AES_WRFIFO/AES_RDFIFO|AES_RDFIFO]]
| 0x1000900C
| 4
| R
|-
| style="background: green" | Yes
| AES_KEYSEL
| 0x10009010
| 1
| RW
|-
| style="background: green" | Yes
| [[#AES_KEYCNT|AES_KEYCNT]]
| 0x10009011
| 1
| RW
|-
| style="background: green" | Yes
| [[#AES_CTR|AES_CTR]]
| 0x10009020
| 16
| W
|-
| style="background: green" | Yes
| [[#AES_MAC|AES_MAC]]
| 0x10009030
| 16
| W
|-
| style="background: green" | Yes
| AES_KEY0
| 0x10009040
| 48
| W
|-
| style="background: green" | Yes
| AES_KEY1
| 0x10009070
| 48
| W
|-
| style="background: green" | Yes
| AES_KEY2
| 0x100090A0
| 48
| W
|-
| style="background: green" | Yes
| AES_KEY3
| 0x100090D0
| 48
| W
|-
| style="background: green" | Yes
| AES_KEYFIFO
| 0x10009100
| 4
| W
|-
| style="background: green" | Yes
| AES_KEYXFIFO
| 0x10009104
| 4
| W
|-
| style="background: green" | Yes
| AES_KEYYFIFO
| 0x10009108
| 4
| W
|}

== AES_CNT ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 4-0
| Write FIFO count (0-16)
|-
| 9-5
| Read FIFO count (0-16)
|-
| 10
| Flush write FIFO (1=Clear write FIFO)
|-
| 11
| Flush read fifo (1=Clear read FIFO)
|-
| 12-13
| Write FIFO DMA size (0=16, 1=12, 2=8, 3=4 words)
|-
| 14-15
| Read FIFO DMA size (0=4, 1=8, 2=12, 3=16 words)
|-
| 18-16
| MAC size (encoding = (maclen-2)/2)
|-
| 19
|? (MAC related)
|-
| 20
| MAC input control (0 = read MAC from FIFO, 1 = read from MAC register)
|-
| 21
| MAC status (0 = invalid, 1 = verified)
|-
| 22
| Output endianness (1=Big endian, 0=Little endian)
|-
| 23
| Input endianness (1=Big endian, 0=Little endian)
|-
| 24
| Output word order (1=Normal order, 0=Reversed order)
|-
| 25
| Input word order (1=Normal order, 0=Reversed order)
|-
| 26
| Update keyslot (selects the keyslot specified by AES_KEYSEL when this bit is set)
|-
| 29-27
| Mode (0=CCM decrypt, 1=CCM encrypt, 2=CTR, 3=CTR, 4=CBC decrypt, 5=CBC encrypt, 6=ECB decrypt, 7=ECB encrypt)
|-
| 30
| Interrupt enable (1=enable, 0=disable)
|-
| 31
| Start (1=enable/busy, 0=idle)
|}

When bit31 is set, this register essentially becomes locked and doesn't change when written to. However if bit26 is "set", keyslot-selection is cued to be handled when bit31 is cleared.

Clearing bit31 while the AES engine is doing crypto will result in the AES engine stopping crypto, once it finishes processing the current block.

Read/Write FIFO counts and the MAC status can never be set by writing to AES_CNT, they are read-only.

Changing the input word order triggers the key/keyX/keyY FIFOs to be flushed.

== AES_MACEXTRABLKCNT ==
(CCM-MAC extra data length)>>4, i.e. the number of block of CCM-MAC extra data.

== AES_BLKCNT ==
(Data length)>>4, i.e. the number of blocks to process

== AES_WRFIFO/AES_RDFIFO ==
The AES engine can accept up to 64 bytes of input data (16 32-bit words) and can hold up to 64 bytes of output data at a time (for a total of 128 bytes of buffered data). Bits 12-13 and 14-15 in AES_CNT configure the DMA request for the relevant FIFO (see above).

The input data for the AES crypto operation is written to AES_WRFIFO, the output data is read from AES_RDFIFO.

Reading from AES_RDFIFO when there's no data available in the RDFIFO will result in reading the last word that was in the RDFIFO.

When triggering either RDFIFO or WRFIFO to be flushed, the AES Engine does not clear either buffer.

Word order and endianness can be changed between each read/write to these FIFOs. However changing the word order when writing to WRFIFO can cause the word to be written outside the current block, leaving uninitialized data in its place. Attempts to change endianness or word order are not honored when reading from RDFIFO when no more data is available.

== AES_KEYCNT ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 5-0
| Keyslot
|-
| 6
| Hardware key-generator type: 0 = 3DS, 1 = DSi.
|-
| 7
| This normally has value 1 written here when updating keys. 0 = disable key FIFO flush, 1 = enable key FIFO flush.
|}

Bit6 is only used when keyslots >=4 are used, value1 has the same affect as doing key-init with the TWL keyslots. Bit6 is only checked when a keyY was completely written, for when the final-normalkey needs updated via the key-generator. Changing bit6 has no affect on the generated normalkey when writing to this bit immediately after writing the last keyY word.

== AES_CTR ==
This register specifies the counter (CTR mode), nonce (CCM mode) or the initialization vector (CBC mode) depending on the mode of operation.
For CBC and CTR mode this register takes up the full 16 bytes, but for CCM mode the nonce is only the first 12 bytes.
The AES engine will automatically increment the counter up to the maximum BLKCNT, after which point it must be manually incremented and set again.

== AES_MAC ==
This register specifies the message authentication code (MAC) for use in CCM mode.

== AES_KEY0/1/2/3 ==
{| class="wikitable" border="1"
! Byte
! Description
|-
| 0-15
| Normalkey
|-
| 16-31
| KeyX
|-
| 32-47
| KeyY
|-}

These registers are the same as they were on TWL, and are likely preserved for compatibility reasons. The keyslot is updated immediately after *any* data(u8/u32/...) is written here, which was used on DSi to [[3DS_System_Flaws|break]] the key-generator.

== Endianness and word order ==

=== AES_CNT.input_endianness ===

Swaps the bytes of 32-bit writes to AES_CTR, AES_WRFIFO, AES_KEY*FIFO according to specified endianness. AES_MAC?

=== AES_CNT.output_endianness ===

Swaps the bytes of 32-bit reads from AES_RDFIFO.

=== AES_CNT.input_word_order ===

If reversed, writes to AES_KEY*FIFO and AES_WRFIFO fill the FIFO backwards. For AES_WRFIFO, this means that every 16-byte block will have its words in the reverse order, but the order of these blocks remains the same. AES_CTR is unaffected by this field. AES_MAC?

=== AES_CNT.output_word_order ===

If reversed, reads from AES_RDFIFO will drain the FIFO backwards. This means that every 16-byte output block will have its words in the reverse order, but the order of these blocks remains the same.

== CCM mode pitfall ==
Non-standard AES-CCM behaviour is observed on [[APT:Wrap|Wrap]]/[[APT:Unwrap|Unwrap]] function. According to [https://tools.ietf.org/html/rfc3610 RFC 3610], the first block B_0 for authentication should be generated from the message length and some other parameters. Using these function, it seems that the message length is aligned up to 16 when generating B_0. This makes the generated MAC not compliant with the standard when (inputsize-noncesize)%16!=0. It is very likely that this non-standard behaviour happens on the hardware level, but not confirmed yet.

== Keyslot ranges ==
This is approximately a table of what is set by bootrom before booting into FIRM. Often it appears that keyslots in groups of 4 have the same keyX, and sometimes also same keyY set.

{| class="wikitable" border="1"
! Keyslot
! Name
! KeyX
! KeyY/Normal-key
! Console unique.
|-
| 0x00-0x03
| TWL keys.
| Probably unset.
| Probably unset.
| -
|-
| 0x04-0x07
| NAND partition keys.
| Same for all.
| Different for all.
| style="background: green" | Yes
|-
| 0x08-0x0B
| See below.
| Same for all.
| Different for all.
| style="background: green" | Yes
|-
| 0x0C-0x0F
| SSL cert key.
| Same for all.
| Same for all, normalkeys-only.
| style="background: orange" | The keyXs are console-unique, however the normalkeys setup by Boot9 later during keyinit are not console-unique.
|-
| 0x10-0x17
| -
| Set for all except 0x11..0x13. Keydata is different for these.
| Normalkey, same for all except the last 4 are all different.
| -
|-
| 0x18-0x1B
| Never used.
| Same for all.
| Same for all, normalkeys-only.
| style="background: orange" | The keyXs are console-unique, however the normalkeys setup by Boot9 later during keyinit are not console-unique.
|-
| 0x1C-0x1F
| Never used.
| Same for all.
| Same for all, normalkeys-only.
| style="background: orange" | The keyXs are console-unique, however the normalkeys setup by Boot9 later during keyinit are not console-unique.
|-
| 0x20-0x23
| Never used.
| Same for all.
| Same for all, normalkeys-only.
| style="background: orange" | The keyXs are console-unique, however the normalkeys setup by Boot9 later during keyinit are not console-unique.
|-
| 0x24
| Never used.
| Individually set.
| Individually set, normalkey-only.
| style="background: orange" | The keyX is console-unique, however the normalkey setup by Boot9 later during keyinit is not console-unique.
|-
| 0x25-0x27
| -
| Not set.
| Same for all, normalkeys-only. Same keydata as keyslot 0x24.
| style="background: red" | No
|-
| 0x28-0x2B
| Never used.
| Individually set.
| Individually set, normalkeys-only. Keyslot 0x28 has same normalkey as keyslot 0x24.
| style="background: orange" | The keyX is console-unique, however the normalkey setup by Boot9 later during keyinit is not console-unique.
|-
| 0x2C-0x2F
| Various uniques.
| Same for all.
| Same for all, normalkeys-only.
| style="background: red" | No
|-
| 0x30-0x33
| Various uniques.
| Same for all.
| Same for all, normalkeys-only.
| style="background: red" | No
|-
| 0x34-0x37
| Various uniques.
| Same for all.
| Same for all, normalkeys-only.
| style="background: red" | No
|-
| 0x38-0x3B
| Various uniques.
| Same for all.
| Same for all, normalkeys-only.
| style="background: red" | No
|-
| 0x3C-0x3F
| Various uniques.
| Individually set.
| Individually set, normalkeys-only. Keyslot 0x3C has same normalkey as 0x38-0x3B.
| style="background: red" | No
|}

Keyslot pairs (0x24, 0x28) and (0x38, 0x3C) shares the same normal-key, while at the same time having different keyX's. This suggests they were set to same normal-key by bootrom.

== Keyslots ==
There are 0x40 keyslots, each of which stores three keys called keyX, keyY and normalkey. All keys can be set explicitly, but the normalkey can optionally be generated using a hardware key generator instead (see [[#Hardware_key_generator|below]]). There is no way to read the contents of a keyslot.

{| class="wikitable" border="1"
! Keyslot
! Description
! KeyX set by
! KeyY set by
! Normal-key
! Old3DS
|-
| 0x00-0x03
| TWL keys.
| NATIVE_FIRM hard-boot.
| NATIVE_FIRM hard-boot.
| -
| Yes
|-
| 0x04..0x07
| [[Flash_Filesystem|NAND]] partition keys.

Keyslot is determined by [[NCSD]] partition FS type and encryption type.
The New3DS Process9 sets the keyY for keyslot 0x05 (New3DS CTRNAND) to a key from .(ro)data. Its keyX is console-unique and set by the bootloader.
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x0A
| DSiWare export key.

Used for encrypting the all-zero 0x10-byte block in the [[DSiWare_Exports|DSiWare_Exports]] header. Console-unique.
| See above keyslot info.
| See above keyslot info.
| -
| Yes
|-
| 0x0B
| This is console-unique. This keyslot is used for the NAND [[Title_Database|dbs]] images AES-CMACs, and the [[Nand/private/movable.sed]] AES-CMAC(when used).
| See above keyslot info.
| See above keyslot info.
| -
| Yes
|-
| 0x0D
| SSL-certificate key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| -
| -
| Bootrom.
| Yes
|-
| 0x11
| Temporary keyslot.

Used by FIRM for general normal-key crypto. Also used by the New3DS [[FIRM]] arm9 binary loader.
| Arm9Loader.
| Arm9Loader.
| NATIVE_FIRM.
| Yes
|-
| 0x14
| Starting with [[5.0.0-11]], NATIVE_FIRM Process9 now sets the keyY for this to the same one it uses for initializing 3 of the keyslots' keyYs from [[PSPXI:EncryptDecryptAes|here]].
| Bootrom.
| NATIVE_FIRM boot.
| -
| Yes
|-
| 0x15
| Used/initialized by the New3DS arm9 binary loader, see [[FIRM|here]].
| Arm9Loader.
| Arm9Loader.
| See previous info for this keyslot.
| No
|-
| 0x16
| Used/initialized by the New3DS arm9 binary loader starting with [[9.5.0-22|9.5.0-X]], see [[FIRM|here]].
| Arm9Loader.
| Arm9Loader.
| See previous info for this keyslot.
| No
|-
| 0x18..0x1F
| These are the New3DS keyslots, where the keyX is generated with keyslot 0x11 by the New3DS arm9 binary [[FIRM|loader]]. As of [[FIRM]] [[9.6.0-24|9.6.0-X]] keyslots 0x1C..0x1F are not yet used by Process9.
| Arm9Loader.
| NATIVE_FIRM / see previous info for these keyslots.
| See previous info for these keyslots.
| No
|-
| 0x18
| New3DS [[9.3.0-21|9.3.0-X]] [[NCCH]] key, when ncchflag[3] is 0x0A.
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x19
| New3DS gamecard [[Savegames|savedata]] AES-CMAC key.

Equivalent of keyslot 0x33, used when a [[NCSD]] flag is set to a certain value (implemented with [[9.3.0-21|9.3.0-X]]).
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x1A
| New3DS gamecard [[Savegames|savedata]] actual key.

Equivalent of keyslot 0x37, used when a [[NCSD]] flag is set to a certain value (implemented with [[9.3.0-21|9.3.0-X]]).
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x1B
| New3DS [[9.6.0-24|9.6.0-X]] [[NCCH]] key, when ncchflag[3] is 0x0B.
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x24
| AGB_FIRM savegame AES-CMAC key.
| Bootrom.
| AGB/NATIVE_FIRM.
| -
| Yes
|-
| 0x25
| [[7.0.0-13|v7.0]] [[NCCH]] key, when ncchflag[3] is 0x01.
| NATIVE_FIRM [[Savegames#6.0.0-11_Savegame_keyY|boot]].
| NATIVE_FIRM.
| -
| Yes
|-
| 0x2C
| Original [[NCCH|NCCH]] key, when ncchflag[3] is 0x00 and always for certain NCCH sections.
| Bootrom.
| Process9.
| -
| Yes
|-
| 0x2D
| UDS local-WLAN CCMP key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x2E
| Streetpass key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x2F
| [[Savegames#6.0.0-11_Savegame_keyY|v6.0]] save key.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x30
| SD/NAND AES-CMAC key.

This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for calculating the AES-CMACs under SD [[SD_Filesystem|/Nintendo 3DS/<ID0>/<ID1>/]] (except [[DSiWare_Exports]]) and [[Flash_Filesystem|NAND]] /data/.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x31
| APT wrap key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x32
| Unknown.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x33
| Gamecard [[Savegames|savedata]] AES-CMAC.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x34
| SD key.

This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for encrypting *all* SD card data under [[SD_Filesystem|/Nintendo 3DS/<ID0>/<ID1>/]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x35
| Movable.sed key.

This is the keyslot used for movable.sed encryption + AES-CBC MAC with the import/export [[FSPXI:ImportIntegrityVerificationSeed|commands]]. The keyYs used for crypto/CMAC are different, but both can be found in process9 rodata.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x36
| Unknown. Used by friends module.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x37
| Gamecard [[Savegames|savedata]] actual key.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x38
| BOSS key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x39
| Download Play key, and the actual NFC key for generating retail [[Amiibo]] keys.

This keyslot is used for two different keys. Both are available via [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x3A
| DSiWare export key.

This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for calculating the AES-CMACs for SD [[DSiWare_Exports]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x3B
| [[CTRCARD_Registers#CTRCARD_SECSEED|CTR-CARD hardware-crypto seed]] decryption key.

AES-CCM is used, the keyY, nonce and MAC are stored in the [[NCSD#Card_Info_Header|Card Info Header]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x3D
| Common key.

Used to decrypt title keys in [[Ticket]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x3F
| Used for various internal Boot9 crypto operations, different keydata for each one. Used to decrypt the [[OTP_Registers|OTP]], the FIRM sections when [[Bootloader#Non-NAND_FIRM_boot|booting from non-NAND]], and when generating the console-unique keys.

The keydata for this keyslot is overwritten with other keydata before booting FIRM. This keyslot is not known to be used post-Boot9.
| Bootrom.
| Bootrom.
| Bootrom.
| Yes
|}

=== Updating keydata ===
The contents of the keyslot specified in AES_KEYCNT can be updated by consecutively writing four words to AES_KEYXFIFO (keyX), AES_KEYYFIFO(keyY), or AES_KEYFIFO (normalkey).

After writing to a keyslot, the keyslot must be selected again(write AES_KEYSEL + set AES_CNT bit26), even when writing to the same keyslot. Writing the last word to a key FIFO immediately after selecting a keyslot will not affect the keyslot keydata that gets used at that time, the new keydata will not get used until the keyslot gets selected again.

Writing to the key FIFOs with byte writes results in the AES engine converting the byte to a word for setting the key word, with this: word = (byteval) | (byteval<<8) | (byteval<<16) | (byteval<<24). The result is the same regardless of which FIFO register byte was written to.

The TWL keyslots 0x00-0x03 can be set directly by writing to the AES_KEY0-AES_KEY3 registers.

The key FIFOs can be written simultaneously. For example, executing the following will result in the keyX and keyY being set to all-zero(unknown for normalkey): memset(0x10009100, 0, 0x100);

Each key FIFO has a 0x10-byte tmp-buffer for storing the words written to that FIFO. Once the last word is written to a key FIFO, the filled tmp-buffer is then written to the key-data for the keyslot selected by AES_KEYCNT at the time the last word was written.

=== Hardware key generator ===
A dedicated hardware key generator can be used to generate a keyslot's normal-key from its keyX and keyY. The hardware key generator is triggered by writing the keyY, which is the only way to trigger it with the 3DS keyslots.

The algorithm for generating the normal-key from keyX and keyY is as follows, in big-endian 128-bit unsigned wraparound arithmetic:

{| class="wikitable" border="1"
! Mode
! Formula
|-
| 3DS
| NormalKey = (((KeyX ROL 2) XOR KeyY) + C1) ROR 41
|-
| DSi
| NormalKey = ((KeyX XOR KeyY) + C2) ROL 42
|}

Unless noted otherwise, all keyslots on retail units use the hardware key generator.

=== FIRM-launch key clearing ===
Starting with [[9.0.0-20]] the Process9 FIRM-launch code now "clears" the following AES keyslots, with certain keydata by writing the normal-key: 0x15 and 0x18-0x20. These are the keyslots used by the New3DS [[FIRM]] arm9bin loader(minus keyslot 0x11), the New3DS Process9 does this too.

=== AES key-init ===
See [[Bootloader|here]] for how Boot9 initializes the AES keyslots.

For an issue with console-unique key-init, see [[OTP_Registers|here]].

Some of the Boot9 key-init appears to have a bug(?) when initializing a chunk of keyslots at once: normally it does <code>for(i=0; i<4; i++){... <setup_keyslot_keydata(keyslotbase+i, keydata)> ...}</code>, however in some cases it does that except with <code>(keyslotbase,</code> instead. This results in the keyslot specified by keyslotbase being initialized 4 times in a row, with the remaining 3 keyslots following keyslotbase being left uninitialized.

initialize_aeskeys() works as follows:
* Validates input, calls panic() on failure. conunique_dataptr and bootrom_dataptr are both input parameters for initialize_aeskeys().
* Calls crypto_initialize().
* Then it ''basically'': copies 0x1C-bytes from conunique_dataptr to tmpbuf+0(sp+12), and copies data from bootrom_dataptr with size 0x40-0x1C to tmpbuf+0x1C(conunique_dataptr and bootrom_dataptr are updated afterwards).
* The 0x40-byte tmpbuf is hashed with SHA256.
* Keyslot 0x3F is then initialized using the above hash: keyX = first 0x10-bytes of the hash, keyY = last 0x10-bytes of the hash.
* Then with each console-unique key-init code-block: IV is loaded from bootrom_dataptr(which is updated afterwards), then the 0x40-bytes from bootrom_dataptr is encrypted with AES-CBC. The output is then used as 4 keyXs for initializing keyslots. How bootrom_dataptr is updated if at all varies per code-block. Hashing similar to the code at the start of this function is also run(when the remaining size for conunique_dataptr is non-zero), but the output hash isn't used(this code is also slightly different for one code-block).
* Once finished with that, the non-console-unique keyslots are initialized. This is done with keydata loaded directly from bootrom_dataptr.
* The last initialized keyslot is 0x3F, via normalkey. The keydata for this is copied to 0xFFF00618. This is for restoring the keydata when non-NAND FIRM boot ''fails'', since those use keyslot 0x3F with other keydata.
* Lastly it clears the 0x40-bytes at tmpbuf with the u32 loaded from bootrom_dataptr(the word following the above keyslot 0x3F keydata), then returns.

The keyslots are initialized with the same order of keyslots+keydata_type listed below:

Console-unique keydata, after the initialization for the key-generation keyslot(0x3F):
0x04..0x07 keyX
0x08..0x0B keyX
0x0C..0x0F keyX
0x10 keyX
0x14..0x17 keyX
0x18..0x1B keyX
0x1C..0x1F keyX
0x20..0x23 keyX
0x24 keyX
0x28..0x2B keyX

Common keydata:

0x2C..0x2F keyX
0x30..0x33 keyX
0x34..0x37 keyX
0x38..0x3B keyX
0x3C..0x3F keyX
0x04..0x0B keyY
0x0C..0x0F normalkey
0x10..0x13 normalkey
0x14..0x17 normalkey
0x18..0x1B normalkey
0x1C..0x1F normalkey
0x20..0x23 normalkey
0x24..0x27 normalkey
0x28..0x2B normalkey
0x2C..0x2F normalkey
0x30..0x33 normalkey
0x34..0x37 normalkey
0x38..0x3B normalkey
0x3C..0x3F normalkey

Homebrew Exploits

2020-06-16T19:13:21Z

EvilFlight: /* Standalone Homebrew Launcher Exploits */

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits. '''No longer needed as of [https://github.com/AuroraWright/Luma3DS/releases/tag/v8.0 Luma 8.0]'''
| From '''9.0.0-7''' up to '''11.9.0-42'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (USA/EUR/JPN, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/zoogie/smilehax-IIe smilehax IIe]
| From '''9.0.0-7''' up to and including '''11.13.0-45'''
| SmileBASIC (JPN version 3.3.2 via app downgrade, USA/EUR 3.6.0, aka latest app version)
| zoogie
| [https://github.com/zoogie/smilehax-IIe/releases/latest Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.9.0-37'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|-
| style="background: salmon" | No
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X''' up to and including '''11.2.0-X'''.
| A gamecard or eShop-install of Monster Hunter X (JPN only), and the DLC encryption key (see installer instructions). '''Note: the secondary exploit still works, see bellow'''
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: salmon" | No
| [https://github.com/nedwill/soundhax soundhax]
| From '''9.0.0-13''' up to and including '''11.3.0-36'''.
| A USA, EUR, JPN or KOR system.
| nedwill
| [http://soundhax.com Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.6.0-X'''.
| An eShop-install of Swapdoodle (version 1.1.1 or lower). As of 2017-4-26, version 1.1.2 was released, blocking outdated app version from sending or receiving messages.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/rpwng2 RPwnG 2]
| From '''1.1.7-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA. A 3DS on firmware 11.7.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng2/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://twitter.com/MrNbaYoh/status/899394739543437313 RPwnG]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| An digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA/JPN is required. As of August 28, 2017 the code is instantly removed after publishing.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng/ Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/notehax notehax]
| From '''9.9.0-X''' up to and including '''11.5.0-X'''.
| A digital copy of Flipnote Studio 3D on ver 1.3.1 (JPN) and ver 1.0.0 for EUR/USA (not the latest)
| MrNbaYoh
| [https://mrnbayoh.github.io/notehax/ Install]
|-
| style="background: darkorange" | Only if you already purchased Blockfactory before it was removed from the eShop
| [https://github.com/Stary2001/haxfactory haxfactory]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of "Blockfactory" (USA/EUR)
| Stary2001
| [https://github.com/Stary2001/haxfactory Install]
|}

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X'''
| A copy of Steel Diver: Sub Wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X''', for '''X''' up to and including 39.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't co-exist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.2.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.2.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to '''11.9.0-X'''.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.9.0-X'''.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.9.0-X'''.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|-
| style="background: lightgreen" | Yes
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X'''(JPN) or '''10.3.0-X'''(EUR/USA) up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of Monster Hunter Generations or Monster Hunter X (without the game updates installed), and an internet connection during installation.
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/painthax painthax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| An eShop-install of Pixel Paint.
| MrNbaYoh
| [https://github.com/MrNbaYoh/painthax/releases/latest install]
|-
| style="background: salmon" | No
| [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh]
| From '''9.9.0-X''' up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of "The Legend of Zelda: Tri Force Heroes", and an Internet connection during installation. Unless you have "CFW", ctr-httpwn >=v1.2 with the included bosshaxx on a compatible system-version is also required. If installing via ctr-httpwn, you can't do so on >=v11.4. Note that the exploit itself was not fixed.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/ctpkpwn/releases Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.4.0-X'''.
| An eShop-install of Swapdoodle.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://github.com/ChampionLeake/RPwnG3 RPwnG3]
| From '''9.0.0-X'''(?) up to and including '''11.12.0-X'''.
| A Digital/Physical copy of "RPGMaker Fes Player/RPGMaker Fes" (USA/JPN 1.1.2 or lower ; EUR 1.1.4 or lower).
| [[User:ChampionLeake|ChampionLeake]]
| [https://github.com/ChampionLeake/RPwnG3/releases Install]
|}

==Exploits without Homebrew Launcher==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format, but could still prove useful by chaining to exploits with higher privileges.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: lime" | Yes
| [[bannerbomb3]] (System Settings)
| (Old3DS (2DS) (XL) / New3DS (XL)) '''11.5.0''' to '''11.13.0'''

(New2DS XL) '''(11.4.0)''' '''11.5.0''' to '''11.13.0'''

An exploit that uses a buffer overflow in a TWL export banner's title strings to gain rop execution.
|A USA, EUR, KOR, or JPN system with its movable.sed keyY extracted.
|[[User:zoogie|zoogie]]
|[[bannerbomb3|Install]]
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

[https://github.com/AuroraWright/Luma3DS Luma3DS], apart from providing signature patches for the installation and use of custom titles, includes the "Rosalina" system module, which among its features allows cleanly loading 3dsx applications as a native process with full ARM11 system permissions, by replacing an installed title's ExeFS and ExHeader during load time. It is currently the only option for running 3dsx applications on 11.4+ O3DSes; additionally, the *hax 2.x payload is incompatible with Rosalina and therefore so are homebrew applications requiring its target title system.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: salmon" | No, still usable pre-v11.4.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.3.0-X'''. This includes bosshaxx.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

Homebrew Exploits

2020-05-28T20:38:13Z

EvilFlight: /* Exploits without Homebrew Launcher*/

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits. '''No longer needed as of [https://github.com/AuroraWright/Luma3DS/releases/tag/v8.0 Luma 8.0]'''
| From '''9.0.0-7''' up to '''11.9.0-42'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.9.X'''.
| A cartridge or eShop version (USA/EUR/JPN, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.9.0-37'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|-
| style="background: salmon" | No
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X''' up to and including '''11.2.0-X'''.
| A gamecard or eShop-install of Monster Hunter X (JPN only), and the DLC encryption key (see installer instructions). '''Note: the secondary exploit still works, see bellow'''
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: salmon" | No
| [https://github.com/nedwill/soundhax soundhax]
| From '''9.0.0-13''' up to and including '''11.3.0-36'''.
| A USA, EUR, JPN or KOR system.
| nedwill
| [http://soundhax.com Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.6.0-X'''.
| An eShop-install of Swapdoodle (version 1.1.1 or lower). As of 2017-4-26, version 1.1.2 was released, blocking outdated app version from sending or receiving messages.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/rpwng2 RPwnG 2]
| From '''1.1.7-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA. A 3DS on firmware 11.7.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng2/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://twitter.com/MrNbaYoh/status/899394739543437313 RPwnG]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| An digital copy of RPG Maker Player (free) ver. 1.1.4 on EUR, ver. 1.1.2 on USA/JPN is required. As of August 28, 2017 the code is instantly removed after publishing.
| MrNbaYoh
| [https://mrnbayoh.github.io/rpwng/ Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/notehax notehax]
| From '''9.9.0-X''' up to and including '''11.5.0-X'''.
| A digital copy of Flipnote Studio 3D on ver 1.3.1 (JPN) and ver 1.0.0 for EUR/USA (not the latest)
| MrNbaYoh
| [https://mrnbayoh.github.io/notehax/ Install]
|-
| style="background: darkorange" | Only if you already purchased Blockfactory before it was removed from the eShop
| [https://github.com/Stary2001/haxfactory haxfactory]
| From '''9.0.0-X'''(?) up to and including '''11.9.0-X'''.
| A digital copy of "Blockfactory" (USA/EUR)
| Stary2001
| [https://github.com/Stary2001/haxfactory Install]
|}

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X'''
| A copy of Steel Diver: Sub Wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.9.0-X''', for '''X''' up to and including 39.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't co-exist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.2.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.2.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to '''11.9.0-X'''.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.9.0-X'''.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.9.0-X'''.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|-
| style="background: lightgreen" | Yes
| [https://github.com/svanheulen/genhax genhax]
| (New 3DS only) From '''9.9.0-X'''(JPN) or '''10.3.0-X'''(EUR/USA) up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of Monster Hunter Generations or Monster Hunter X (without the game updates installed), and an internet connection during installation.
| svanheulen
| [https://github.com/svanheulen/genhax_installer Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/MrNbaYoh/painthax painthax]
| From '''9.0.0-X''' up to and including '''11.6.0-X'''.
| An eShop-install of Pixel Paint.
| MrNbaYoh
| [https://github.com/MrNbaYoh/painthax/releases/latest install]
|-
| style="background: salmon" | No
| [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh]
| From '''9.9.0-X''' up to and including '''11.3.0-X'''.
| A gamecard or eShop-install of "The Legend of Zelda: Tri Force Heroes", and an Internet connection during installation. Unless you have "CFW", ctr-httpwn >=v1.2 with the included bosshaxx on a compatible system-version is also required. If installing via ctr-httpwn, you can't do so on >=v11.4. Note that the exploit itself was not fixed.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/ctpkpwn/releases Install]
|-
| style="background: salmon" | No
| [https://github.com/MrNbaYoh/doodlebomb doodlebomb]
| From '''9.0.0-X'''(?) up to and including '''11.4.0-X'''.
| An eShop-install of Swapdoodle.
| MrNbaYoh
| [https://mrnbayoh.github.io/doodlebomb/ Install]
|-
| style="background: darkorange" | Only if installed before August 28, 2017
| [https://github.com/ChampionLeake/RPwnG3 RPwnG3]
| From '''9.0.0-X'''(?) up to and including '''11.12.0-X'''.
| A Digital/Physical copy of "RPGMaker Fes Player/RPGMaker Fes" (USA/JPN 1.1.2 or lower ; EUR 1.1.4 or lower).
| [[User:ChampionLeake|ChampionLeake]]
| [https://github.com/ChampionLeake/RPwnG3/releases Install]
|}

==Exploits without Homebrew Launcher==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format, but could still prove useful by chaining to exploits with higher privileges.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: lime" | Yes
| [[bannerbomb3]] (System Settings)
| (Old3DS (2DS) (XL) / New3DS (XL)) '''11.5.0''' to '''11.13.0'''

(New2DS XL) '''(11.4.0)''' '''11.5.0''' to '''11.13.0'''

An exploit that uses a buffer overflow in a TWL export banner's title strings to gain rop execution.
|A USA, EUR, KOR, or JPN system with its movable.sed keyY extracted.
|[[User:zoogie|zoogie]]
|[[bannerbomb3|Install]]
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

[https://github.com/AuroraWright/Luma3DS Luma3DS], apart from providing signature patches for the installation and use of custom titles, includes the "Rosalina" system module, which among its features allows cleanly loading 3dsx applications as a native process with full ARM11 system permissions, by replacing an installed title's ExeFS and ExHeader during load time. It is currently the only option for running 3dsx applications on 11.4+ O3DSes; additionally, the *hax 2.x payload is incompatible with Rosalina and therefore so are homebrew applications requiring its target title system.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: salmon" | No, still usable pre-v11.4.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.3.0-X'''. This includes bosshaxx.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

3DS Userland Flaws

2020-05-01T10:05:36Z

EvilFlight: /* Non-system applications */

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| App: v1.1
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| Citizens of Earth
| Save file read stack smash
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.
| None
| [[10.7.0-32]].
| Time of exploit release.
| May 5, 2016
| [[User:Dazzozo|Dazzozo]]
|-
| SmileBASIC 3.x
| Poor parameter validation on "BGSCREEN" command
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| SmileBASIC 3.x
| Subscripted TIME$/DATE$ allow write access to DATA/BSS
| Utf-16 characters can be assigned to subscripted TIME$/DATE$ interpreter sysvars which results in write-only access to all of DATA and some BSS in userland.
TIME$[0]/DATE$[0] actually point to somewhere in rodata, and an overly large subscript can be used to write well past it and into the aforementioned areas. Demo [https://github.com/zoogie/smilehax-IIe here.]
| App: 3.6.2 (3.6.0 latest for US/EU, JP appvers. can be downgraded)
| System: [[11.13.0-45]].
| April 2020
| February 2020
| bug publicly documented [https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fsmilebasic.com%2Fdebug%2Farchive%2F here.]
Exploited by Zoogie
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]], [[User: ChampionLeake|ChampionLeake]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|-
| Mononoke Forest
| String Buffer Overflow via unchecked string length
| The game stores plaintext profile names in the savefile. The profile names are strcpy/memcpy to different areas of the game's functions in the stack. Using a large extensive profile name, a user can overwrite some stack-registers and point to stack buffer addresses to eventually gain control of the stack to lead and form a rop-chain.
| None
| App: v1.0.0
| August 14, 2019
| February 8, 2019
| [[User: ChampionLeake|ChampionLeake]] and [[User: Kartik|Kartik]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

* [[Pyramids (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [[Pyramids 2 (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.

* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.

* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.

* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.

* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.

* "Mutant Mudds": Overwriting the savefile with random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.

* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.

* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.

* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls

==Crashes needing investigation==
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|-
| 3DS [[System Settings]] stack smash via title strings in [[DSiWare_Exports]]
| DSiWare export banners contain 16 consecutive 0x100 byte, utf-16 game title strings for different languages. Nintendo correctly limits the string's max length by placing a NULL at str[127] before it's copied to the stack. However, they didn't allocate enough space for all 128 wchars (char/wchar type confusion?), so an attacker can craft a valid full-length string that will crash the stack at about str+0xEC. ROP execution can then be obtained from this crash in DSiWare Data Management as demonstrated [https://github.com/zoogie/Bannerbomb3 here].

Interesting note: A line feed wchar (00 0A) at any point in the string before the crash offset will prevent the crash from occurring.
| None
| [[11.13.0-45]]
| Dec. 2018
| Zoogie
|-
| 3DS SAFE_MODE [https://www.3dbrew.org/wiki/System_Settings#System_Updater System Updater] stack smash from proxy-url string
| During [[Recovery Mode]] and after all 3 wifi slots fail to find an access point for sysupdate, a user is permitted to access the wifi settings mode to make changes. Here, if the proxy-url field string's NULL terminator had been altered beforehand, a stack smash can occur when the user selects Proxy Settings -> Detailed Setup and the corrupted url string is displayed.

This is a difficult crash to control because the url string is converted from ascii to utf-16 between the slot and stack, effectively reducing the available gadgets to 0.4% of the normal amount. It's possible to improvise an "escape" using an eoreq pc w/shift gadget to combine registers and form a jump that can access 1/2 of all available gadgets.

Because this exploit runs *under* SAFE_MODE, it's possible to run safehax with one's choice of k11 and arm9 hax. Prerequisite: a userland exploit with cfg:s/i access to modify the wifi slot. A demonstration can be viewed [https://github.com/zoogie/unSAFE_MODE here].
| None
| [[11.13.0-45]]
| Jan. 2020
| Zoogie
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.

This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| [[10.7.0-32|10.7.0-32]]
|
| [[9.9.0-26|9.9.0-26]]
| February 25, 2016
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| Theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| <Old3DS/New3DS version which added initial theme support>
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| Shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
| [[9.3.0-21|9.3.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[5.0.0-11|5.0.0-X]]
|
| [[2.0.0-2|2.0.0-X]]
| June 9, 2016
| June 9, 2016
| [[User:Yellows8|Yellows8]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

3DS Userland Flaws

2020-04-26T08:37:41Z

EvilFlight: /* Non-system applications */

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| App: v1.1
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| Citizens of Earth
| Save file read stack smash
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.
| None
| [[10.7.0-32]].
| Time of exploit release.
| May 5, 2016
| [[User:Dazzozo|Dazzozo]]
|-
| SmileBASIC 3.x
| Poor parameter validation on "BGSCREEN" command
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| SmileBASIC 3.x
| Subscripted TIME$/DATE$ allow write access to DATA/BSS
| Utf-16 characters can be assigned to subscripted TIME$/DATE$ interpreter sysvars which results in write-only access to all of DATA and some BSS in userland.
TIME$[0]/DATE$[0] actually point to somewhere in rodata, and an overly large subscript can be used to write well past it and into the aforementioned areas.
| App: 3.6.2 (3.6.0 latest for US/EU, JP appvers. can be downgraded)
| System: [[11.13.0-45]].
| April 2020
| February 2020
| bug publicly documented [https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fsmilebasic.com%2Fdebug%2Farchive%2F here]
Exploited by Zoogie
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]], [[User: ChampionLeake|ChampionLeake]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|-
| Mononoke Forest
| String Buffer Overflow via unchecked string length
| The game stores plaintext profile names in the savefile. The profile names are strcpy/memcpy to different areas of the game's functions in the stack. Using a large extensive profile name, a user can overwrite some stack-registers and point to stack buffer addresses to eventually gain control of the stack to lead and form a rop-chain.
| None
| App: v1.0.0
| August 14, 2019
| February 8, 2019
| [[User: ChampionLeake|ChampionLeake]] and [[User: Kartik|Kartik]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

* [[Pyramids (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [[Pyramids 2 (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.

* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.

* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.

* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.

* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.

* "Mutant Mudds": Overwriting the savefile with random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.

* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.

* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.

* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls

==Crashes needing investigation==
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|-
| 3DS [[System Settings]] stack smash via title strings in [[DSiWare_Exports]]
| DSiWare export banners contain 16 consecutive 0x100 byte, utf-16 game title strings for different languages. Nintendo correctly limits the string's max length by placing a NULL at str[127] before it's copied to the stack. However, they didn't allocate enough space for all 128 wchars (char/wchar type confusion?), so an attacker can craft a valid full-length string that will crash the stack at about str+0xEC. ROP execution can then be obtained from this crash in DSiWare Data Management as demonstrated [https://github.com/zoogie/Bannerbomb3 here].

Interesting note: A line feed wchar (00 0A) at any point in the string before the crash offset will prevent the crash from occurring.
| None
| [[11.13.0-45]]
| Dec. 2018
| Zoogie
|-
| 3DS SAFE_MODE [https://www.3dbrew.org/wiki/System_Settings#System_Updater System Updater] stack smash from proxy-url string
| During [[Recovery Mode]] and after all 3 wifi slots fail to find an access point for sysupdate, a user is permitted to access the wifi settings mode to make changes. Here, if the proxy-url field string's NULL terminator had been altered beforehand, a stack smash can occur when the user selects Proxy Settings -> Detailed Setup and the corrupted url string is displayed.

This is a difficult crash to control because the url string is converted from ascii to utf-16 between the slot and stack, effectively reducing the available gadgets to 0.4% of the normal amount. It's possible to improvise an "escape" using an eoreq pc w/shift gadget to combine registers and form a jump that can access 1/2 of all available gadgets.

Because this exploit runs *under* SAFE_MODE, it's possible to run safehax with one's choice of k11 and arm9 hax. Prerequisite: a userland exploit with cfg:s/i access to modify the wifi slot. A demonstration can be viewed [https://github.com/zoogie/unSAFE_MODE here].
| None
| [[11.13.0-45]]
| Jan. 2020
| Zoogie
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.

This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| [[10.7.0-32|10.7.0-32]]
|
| [[9.9.0-26|9.9.0-26]]
| February 25, 2016
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| Theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| <Old3DS/New3DS version which added initial theme support>
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| Shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
| [[9.3.0-21|9.3.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[5.0.0-11|5.0.0-X]]
|
| [[2.0.0-2|2.0.0-X]]
| June 9, 2016
| June 9, 2016
| [[User:Yellows8|Yellows8]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

FIRM

2020-04-26T07:55:55Z

EvilFlight: /* SAFE_MODE_FIRM */

This page describes the file format for the [[Title list#00040138 - System Firmware|3DS' Firmware]], it contains up to four 'sections' of data comprising the ARM9 and ARM11 kernels, and some fundamental processes. The firmware sections are not encrypted. In a nutshell, a FIRM contains all the data required to set up the ARM9 and ARM11 kernels, and basic operating functionality.

The ARM9 section contains the ARM9 kernel (and loader) and the Process9 NCCH (which is the only process run in user mode on the ARM9). The ARM11 sections contain the ARM11 kernel (and loader), and various ARM11 process NCCHs. For NATIVE_FIRM/SAFE_MODE_FIRM these ARM11 processes are sm, fs, pm, loader, and pxi. Normally the 4th section is not used. The code loaded from FIRM is constantly running on the system until another FIRM is launched. The ARM11 kernel is hard-coded to always decompress the ExeFS .code of embedded ARM11 NCCHs without checking the exheader compression bit.

== FIRM Header ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 4
| Magic 'FIRM'
|-
| 0x004
| 4
| Boot priority (highest value = max prio), this is normally zero.
|-
| 0x008
| 4
| ARM11 Entrypoint
|-
| 0x00C
| 4
| ARM9 Entrypoint
|-
| 0x010
| 0x030
| Reserved
|-
| 0x040
| 0x0C0 (0x030*4)
| Firmware Section Headers
|-
| 0x100
| 0x100
| RSA-2048 signature of the FIRM header's SHA-256 hash. The signature is checked when bootrom/Process9 are doing FIRM-launch (with the public key being hardcoded in each). The signature is not checked when installing FIRM to the NAND firm0/firm1 partitions.
|}

== Firmware Section Headers ==

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 4
| Byte offset
|-
| 0x004
| 4
| Physical address where the section is loaded to.
|-
| 0x008
| 4
| Byte-size. While loading FIRM this is the field used to determine whether the section exists or not, by checking for value 0x0.
|-
| 0x00C
| 4
| Copy-method (0 = NDMA, 1 = XDMA, 2 = CPU mem-copy), Process9 ignores this field. Boot9 doesn't immediately throw an error when this isn't 0..2. In that case it will jump over section-data-loading which then results in the hash verification with the below hash being done with the hash already stored in the SHA hardware.
|-
| 0x010
| 0x020
| SHA-256 Hash of Firmware Section
|}

The contents of individual sections ''may'' be encrypted if the FIRM is not meant to be booted from NAND, i.e. if it is meant to be booted from SPI flash or NTR cartridge. If hash checks fail for all FIRM sections if treated as plaintext, it may be worth trying to check if the sections are encrypted. The encryption is detailed on [[Bootloader#Non-NAND_FIRM_boot|the bootloader page]].

== [[New_3DS]] FIRM ==
For New3DS firmwares (NATIVE_FIRM, TWL_FIRM, ..), the ARM9 FIRM binary has an additional layer of crypto. At the end of each ARM9 binary, there's a plaintext loader. The format of the FIRM header is identical to regular 3DS FIRM(the RSA modulo is the same as regular 3DS too).

Before checking [[CONFIG_Registers|CFG_SYSPROT9]] the loader main() does the following:
* On [[9.5.0-22|9.5.0-X]]: executes a nop instruction with r0=0 and r1=<address of arm9binhdr+0x50>.
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]].

If [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is clear (which means the OTP area is unlocked and so it knows that this is a hard reboot), it does the following things:
* Clears 0x200-bytes on the stack, then reads [[Flash_Filesystem|NAND]] sector 0x96(NAND image offset 0x12C00), with size 0x200-bytes into that stack buffer.
* Checks [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 again, if it's set then it executes a panic function(set r0-r2=0, execute nop instruction, then execute instruction "bkpt 0x99").
* Hashes data from the OTP region [[IO_Registers|0x10012000-0x10012090]] using SHA256 via the [[SHA_Registers|SHA]] hardware.
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]]. Initializes AES keyslot 0x11 keyX, keyY to the lower and higher portion of the above hash, respectively. Due to the above hashed data, the keyX+keyY here are console-unique.
* Decrypts the first 0x10-byte block in the above read NAND sector with keyslot 0x11 using AES-ECB. [[9.6.0-24|9.6.0-X]]: Then it decrypts the 0x10-bytes at offset 0x10 in the sector with keyslot 0x11.
* Then the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero. Runs the TWL key-init/etc code which was originally in the ARM9-kernel, then writes 0x2 to [[CONFIG_Registers|CFG_SYSPROT9]] to disable the OTP area.
* Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts arm9_bin_buf+0 using keyslot 0x11 with AES-ECB, and initialises keyX for keyslot 0x15 with it.
* [[9.6.0-24|9.6.0-X]]: Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts a 0x10-byte block from arm9loader .(ro)data using keyslot 0x11 with AES-ECB, and initializes keyX for keyslot 0x18 with it(same block as previous versions).
* [[9.6.0-24|9.6.0-X]]: Starting with this version keyslot 0x16 keyX init was moved here, see below for details on this. The code for this is same as [[9.5.0-22|9.5.0-X]], except the decrypted normalkey from sector+0x10 is used for keyslot 0x11 instead.
* Initialises KeyX for keyslots 0x18..0x1F(0x19..0x1F with [[9.6.0-24|9.6.0-X]]) with the output of decrypting a 0x10-byte block with AES-ECB using keyslot 0x11. This block was changed to a new one separate from keyslot 0x18, starting with [[9.6.0-24|9.6.0-X]]. The last byte in this 0x10-byte input block is increased by 0x01 after initializing each keyslot. Before doing the crypto each time, the loader sets the normal-key for keyslot 0x11 to the plaintext normalkey from sector+0(+0x10 with [[9.6.0-24|9.6.0-X]]). These are New3DS-specific keys.
* [[9.5.0-22|9.5.0-X]](moved to above with [[9.6.0-24|9.6.0-X]]): Sets the normal-key for keyslot 0x11 to the same one already decrypted on the stack. Decrypts the 0x10-byte block at arm9binhdr+0x60 with AES-ECB using keyslot 0x11, then sets the keyX for keyslot 0x16 to the output data.
* [[9.5.0-22|9.5.0-X]]: The normalkey, keyX, and keyY, for keyslot 0x11 are then cleared to zero.

When [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is set(which means this happens only when this loader runs again for firm-launch), the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero.

It sets KeyY for keyslot 0x15(0x16 with [[9.5.0-22|9.5.0-X]]) to arm9_bin_buf+16, the CTR to arm9_bin_buf+32 (both are unique for every version). It then proceeds to decrypt the binary with AES-CTR. When done, it sets the normal-key for the keyslot used for binary decryption to zeros. It then decrypts arm9_bin_buf+64 using an hardcoded keyY for keyslot 0x15([[9.5.0-22|9.5.0-X]]/[[9.6.0-24|9.6.0-X]] also uses keyslot 0x15), sets the normal-key for this keyslot to zeros again, then makes sure the output block is all zeroes. If it is, it does some cleanup then it jumps to the entrypoint for the decrypted binary. Otherwise it will clear the keyX, keyY, and normal-key for each of the keyslots initialized by this loader (on [[9.6.0-24|9.6.0-X]]+, on older versions this was bugged and cleared keys 0x00..0x07 instead of 0x18..0x1F), do cleanup(same cleanup as when the decrypted block is all-zero) then just loop forever.

Thus, the ARM9 binary has the following header:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 16
| Encrypted KeyX (same for all FIRM's)
|-
| 0x010
| 16
| KeyY
|-
| 0x020
| 16
| CTR
|-
| 0x030
| 8
| Size of encrypted binary, as ASCII text?
|-
| 0x038
| 8
| ?
|-
| 0x040
| 16
| Control block
|-
| 0x050
| 16
| Added with [[9.5.0-22|9.5.0-X]]. Only used for hardware debugging: a nop instruction is executed with r0=0 and r1=<address of this data>.
|-
| 0x060
| 16
| Added with [[9.5.0-22|9.5.0-X]]. Encrypted keyX for keyslot 0x16.
|}

Originally the padding after the header before offset 0x800(start of actual ARM9-binary) was 0xFF bytes, with [[9.5.0-22|9.5.0-X]] this was changed to 0x0.

For the New3DS NATIVE_FIRM arm9-section header, the only difference between the [[8.1.0-0_New3DS]] version and the [[9.0.0-20]] version is that the keyY, CTR, and the block at 0x30 in the header were updated.

===New3DS ARM9 binary loader versions===
{| class="wikitable" border="1"
|-
! FIRM system version(s)
! Description
|-
| [[8.1.0-0_New3DS]] - [[9.3.0-21|9.3.0-X]]
| Initial version.
|-
| [[9.5.0-22|9.5.0-X]]
| Added keyX initialization for keyslot 0x16(see above), and added code for clearing keyslot 0x11 immediately after the code finishes using keyslot 0x11. The keyslot used for arm9bin decryption was changed from 0x15 to 0x16. Added code for clearing keyslot 0x16 when control-block decryption fails. Added code for using arm9bin_hdr+0x50 with a nop instruction, at the very beginning of the main arm9-loader function. Added two new 0x10-blocks to the arm9bin-hdr.
|-
| [[9.6.0-24|9.6.0-X]] - [[11.3.0-36|11.3.0-X]]
| See above and [[9.6.0-24|here]].
|}

===New3DS ARM9 kernel===
The only actual code-difference for the Old3DS/New3DS ARM9-kernels' crt0, besides TWL AES / [[IO_Registers|0x10012000]] related code, is that the New3DS ARM9-kernel writes 0x1 to [[CONFIG_Registers|REG_EXTMEMCNT9]] in the crt0.

===New3DS Process9===
The following is all of the differences for Old3DS/New3DS Process9 with [[9.3.0-21|9.3.0-X]]:
* The FIRM-launch code called at the end of the New3DS proc9 main() has different mem-range checks.
* In the New3DS proc9, the v6.0/v7.0 keyinit function at the very beginning(before the original code) had additional code added for setting [[Flash_Filesystem|CTRNAND]] [[AES_Registers|keyslot]] 0x5, with keydata from .data. After setting the keyY, the keyY in .data is cleared.
* In New3DS proc9, the functions for getting the gamecard crypto keyslots / NCCH keyslot can return New3DS keyslots when New3DS flags(NCSD/NCCH) are set.
* The code/data for the binary near the end of arm9mem is slightly different, because of memory-region sizes.
* The only difference in .data(besides the above code binary) is that the New3DS proc9 has an additional 0x10-byte block for the keyslot 0x5 keyY, see above.

== Variations ==
There exists different official firmwares for the 3DS: The default one (NATIVE_FIRM) is used to run all 3DS content and boots by default, while backwards compatibility is handled by TWL_FIRM and AGB_FIRM. There furthermore is a rescue mode provided by SAFE_MODE_FIRM.

=== NATIVE_FIRM ===
NATIVE_FIRM is the FIRM which is installed to the [[Flash_Filesystem|NAND]] firm partitions, which is loaded by bootrom.

Version history:

{| class="wikitable" border="1"
! System version
! old 3DS title version
! old 3DS hex title contentID
! Kernel/FIRM version (old 3DS/new 3DS)
! FIRM ARM11-sysmodule Product Code
|-
| [[Factory_Setup|Factory]] FIRM (titleID 00040001-00000002)
| v0
| 00
| 2.3-0
|-
| Pre-1.0. Referenced in the v1.0 Home Menu NCCH plain-region.
|
|
| 2.23-X
|-
| [[1.0.0-0|1.0.0]]
| v432
| 00
| 2.27-0
|-
| [[1.1.0-1|1.1.0]]
| v1472
| 02
| 2.28-0
|-
| [[2.0.0-2|2.0.0]]
| v2516
| 09
| 2.29-7
|-
| [[2.1.0-3|2.1.0]]
| v3553
| 0B
| 2.30-18
| 0608builder
|-
| [[2.2.0-X|2.2.0]]
| v4595
| 0F
| 2.31-40
| 0909builder
|-
| [[3.0.0-5|3.0.0]]
| v5647
| 18
| 2.32-15
| 1128builder
|-
| [[4.0.0-7|4.0.0]]
| v6677
| 1D
| 2.33-4
| 0406builder
|-
| [[4.1.0-8|4.1.0]]
| v7712
| 1F
| 2.34-0
| 0508builder
|-
| [[5.0.0-11|5.0.0]]
| v8758
| 25
| 2.35-6
| 0228builder
|-
| [[5.1.0-11|5.1.0]]
| v9792
| 26
| 2.36-0
| 0401builder
|-
| [[6.0.0-11|6.0.0]]
| v10833
| 29
| 2.37-0
| 0520builder
|-
| [[6.1.0-11|6.1.0]]
| v11872
| 2A
| 2.38-0
| 0625builder
|-
| [[7.0.0-13|7.0.0]]
| v12916
| 2E
| 2.39-4
| 1125builder
|-
| [[7.2.0-17|7.2.0]]
| v13956
| 30
| 2.40-0
| 0404builder
|-
| [[8.0.0-18|8.0.0]]
| v15047
| 37
| 2.44-6
| 0701builder
|-
| [[8.1.0-0_New3DS]]
|N/A
|N/A
| 2.45-5
|-
| [[9.0.0-20|9.0.0]]
| v17120
| 38
| 2.46-0
| 0828builder
|-
| [[9.3.0-21|9.3.0]]
| v18182
| 3F
| 2.48-3
| 1125builder
|-
| [[9.5.0-22|9.5.0]]
| v19216
| 40
| 2.49-0
| 0126builder
|-
| [[9.6.0-24|9.6.0]]
| v20262
| 49
| 2.50-1
| 0311builder
|-
| [[10.0.0-27|10.0.0]]
| v21288
| 4B
| 2.50-7
| 0812builder
|-
| [[10.2.0-28|10.2.0]]
| v22313
| 4C
| 2.50-9
| 1009builder
|-
| [[10.4.0-29|10.4.0]]
| v23341
| 50
| 2.50-11
| 1224builder
|-
| [[11.0.0-33|11.0.0]]
| v24368
| 52
| 2.51-0
| 0406builder
|-
| [[11.1.0-34|11.1.0]]
| v25396
| 56
| 2.51-2
| 0805builder
|-
| [[11.2.0-35|11.2.0]]
| v26432
| 58
| 2.52-0
| 1015builder
|-
| [[11.3.0-36|11.3.0]]
| v27476
| 5C
| 2.53-0
| 0126builder
|-
| [[11.4.0-37|11.4.0]]
| v28512
| 5E
| 2.54-0
| 0314builder
|-
| [[11.8.0-41|11.8.0]]
| v29557
| 64
| 2.55-0
| 0710pseg-ciuser
|-
| [[11.12.0-44|11.12.0]]
| v30593
| 66
| 2.56-0
| 1021pseg-ciuser
|}

The above kernel/FIRM versions are in the format: <KERNEL_VERSIONMAJOR>.<KERNEL_VERSIONMINOR>-<KERNEL_VERSIONREVISION>.

=== SAFE_MODE_FIRM ===
SAFE_MODE is used for running the [[System_Settings#System_Updater|System Updater]]. SAFE_MODE_FIRM and NATIVE_FIRM for the initial versions are exactly the same, except for the system core version fields. Kernel/FIRM versions for SAFE_MODE_FIRM are: (old3ds) v432 = 3.27-0, v5632 = 3.32-0, (new3ds) v16081 = 3.45-3.

=== TWL_FIRM ===
TWL_FIRM handles DS(i) backwards compatibility.

The 3DS-mode ARM9 core seems to switch into DSi-mode(for running DSi-mode ARM9 code) by writing to a [[PDN]] register(this changes the memory layout to DSi-mode / etc, therefore this register poke *must* be executed from ITCM). This is the final 3DS-mode register poke before the ARM9 switches into DSi-mode. DS(i)-mode ARM7 code is run on the internal [[ARM7]] core, which is started up during TWL_FIRM boot. Trying to read from the exception-vector region(address 0x0) under this DSi-mode ARM7 seems to only return 0x00/0xFF data. Also note that this DSi-mode ARM7 runs code(stored in TWL_FIRM) which pokes some DSi-mode registers that on the DSi were used for disabling access to the DSi bootROMs, however these registers do not affect the 3DS DSi-mode ARM9/ARM7 "bootrom" region(exceptionvector region + 0x8000) at all.

For shutting down the system, TWL_FIRM writes u8 value 8 to [[I2C]] MCU register 0x20. For returning to 3DS-mode, TWL_FIRM writes value 4 to that MCU register to trigger a hardware system reboot.

The TWL_FIRM ARM11-process includes a TWL bootloader, see [http://dsibrew.org/wiki/Bootloader here] and [[Memory_layout#Detailed_TWL_FIRM_ARM11_Memory|here]] for details.

TWL_FIRM verifies all TWL RSA padding with the following. This is different from the DSi "BIOS" code.
* The first byte must be 0x0.
* The second byte must be 0x1 or 0x2.
* Executes a while(<value of byte at current pos in RSA message>). When the second_byte in the message is 0x1, the byte at curpos must be 0xFF(otherwise the non-zero value of the byte at curpos doesn't matter). This loop must find a zero byte before offset 0x7F in the message otherwise an error is returned.
* Returns an address for msg_curpos+1.
totalhashdatasize = rsasig_bytesize - above position in the message for the hashdata. The actual "totalhashdatasize" in the RSA message must be <= <expected hashdata_size>(0x74 for bootloader). The TWL_FIRM code copies the RSA "hashdata" to the output buffer, using the actual size of the RSA "hashdata".

=== AGB_FIRM ===
AGB_FIRM handles running GBA VC titles. The ARM9 FIRM section for TWL_FIRM and AGB_FIRM are exactly the same (for TWL_FIRM and AGB_FIRM versions which were updated with the same system-update).

== FIRM Launch Parameters ==
The FIRM-launch parameters structure is located at FCRAM+0, size 0x1000-bytes. The ARM11-kernel copies this structure elsewhere, then clears the 0x1000-bytes at FCRAM+0. It will not handle an existing structure at FCRAM+0 if [[CONFIG Registers#CFG_BOOTENV|CFG_BOOTENV]] is zero. The ARM9 kernel [[Configuration_Memory#0x1FF80016|writes some values]] about the boot environment to AXI WRAM during init to enable this.

Note: it seems NATIVE_FIRM ARM11-kernel didn't parse this during boot until [[3.0.0-5|3.0.0-X]]?

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x300
| 0x100
| 'TLNC' block created by TWL applications, handled by NS for backwards-compatibility purposes. See [[NS#Auto-boot|here]] for more info.
|-
| 0x400
| 0x4
| Flags
|-
| 0x410
| 0xC
| This is used for overriding the FIRM_* fields in [[Configuration_Memory]], when the flag listed below is set, in the following order(basically just data-copy from here to 0x1FF80060): "FIRM_?", FIRM_VERSIONREVISION, FIRM_VERSIONMINOR, FIRM_VERSIONMAJOR, FIRM_SYSCOREVER, and FIRM_CTRSDKVERSION.
|-
| 0x438
| 0x4
| The kernel checks this field for value 0xFFFF, if it matches the kernel uses the rest of these parameter fields, otherwise FIRM-launch parameters fields are ignored by the kernel.
|-
| 0x43C
| 0x4
| CRC32, this is calculated starting at FIRM-params offset 0x400, with size 0x140(with this field cleared to zero during calculation). When invalid the kernel clears the entire buffer used for storing the FIRM-params, therefore no actual FIRM-params are handled after that.
|-
| 0x440
| 0x10
| Titleinfo [[Filesystem_services#ProgramInfo|Program Info]], used by NS during NS startup, to launch the specified title when the below flag is set.
|-
| 0x450
| 0x10
| Titleinfo [[Filesystem_services#ProgramInfo|Program Info]]. This might be used for returning to the specified title, once the above launched title terminates?
|-
| 0x460
| 0x4
| Bit0: 0 = titleinfo structure isn't set, 1 = titleinfo structure is set.
|-
| 0x480
| 0x20
| This can be set via buf1 for [[APT:SendDeliverArg]]/[[APT:StartApplication]].
|-
| 0x4A0
| 0x10
| This can be set by [[NSS:SetWirelessRebootInfo]].
|-
| 0x4B0
| 0x14
| SHA1-HMAC of the banner for TWL/NTR titles. This can be set by [[NSS:SetTWLBannerHMAC]].
|-
| 0x500
| 0x40
| This is used by [[APT:LoadSysMenuArg]] and [[APT:StoreSysMenuArg]].
|-
| 0xD70
| 0x290
| [[Config Savegame|Config]] data struct for LGY FIRM.
|}

Flags from offset 0x400:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x1
| This can be used for overriding the default FCRAM [[Memory_layout|memory-regions]] allocation sizes(APPLICATION, SYSTEM, and BASE). The values for this is the same as [[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]]. Values 0-1 are handled the same way by the kernel. However for NS, 0=titleinfo structure for launching a title isn't set, while non-zero=titleinfo structure is set.
|-
| 0x1
| 0x3
| Setting bit0 here enables overriding the FIRM_* fields in [[Configuration_Memory]].
|}

[[Config Savegame|Config]] struct for booting LGY FIRMs from offset 0xD70:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x1
| Config block 0x30000.
|-
| 0x1
| 0x1
| Config block 0x70001.
|-
| 0x2
| 0x1
| System language (Config block 0xA0002).
|-
| 0x3
| 0x1
| [[Cfg:SecureInfoGetRegion|Region from SecureInfo]] ("pseudo-block" 0x140000 in LGY FIRM).
|-
| 0x4
| 0xF
| [[CfgS:SecureInfoGetSerialNo|Serial number from SecureInfo]] ("pseudo-block" 0x140001 in LGY FIRM).
|-
| 0x13
| 0x1
| Config block 0x100002.
|-
| 0x14
| 0x10
| Config block 0x100003.
|-
| 0x24
| 0x2
| Config block 0x100000.
|-
| 0x26
| 0x1
| Cleared to zero.
|-
| 0x27
| 0x1
| Cleared to zero.
|-
| 0x28
| 0x94
| Config block 0x100001.
|-
| 0xBC
| 0x2
| Config block 0x50000.
|-
| 0xBE
| 0x2
| Config block 0x50001.
|-
| 0xC0
| 0x38
| Config block 0x50002.
|-
| 0xF8
| 0x20
| Config block 0x50004.
|-
| 0x118
| 0x134
| Config block 0x20000.
|-
| 0x24C
| 0x10
| Config block 0x40000.
|-
| 0x25C
| 0x1C
| Config block 0x40001.
|-
| 0x278
| 0x4
| Cleared to zero.
|-
| 0x27C
| 0x4
| Cleared to zero.
|-
| 0x280
| 0x8
| Config block 0x30001.
|-
| 0x288
| 0x2
| CRC16 over the above fields from offset 0x0, size 0x288. If not valid, LGY FIRM uses dummy data from .(ro)data.
|-
| 0x28A
| 0x2
| If non-zero, the size (below) is hardcoded (currently) to value 0x288, otherwise the size field below is used.
|-
| 0x28C
| 0x4
| Value 0x288 (size used for verifying the CRC16).
|}

"Cleared to zero" fields above are not read at all by LGY FIRM.

3DS Userland Flaws

2020-04-26T06:15:53Z

EvilFlight: /* System applications */

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| App: v1.1
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| Citizens of Earth
| Save file read stack smash
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.
| None
| [[10.7.0-32]].
| Time of exploit release.
| May 5, 2016
| [[User:Dazzozo|Dazzozo]]
|-
| SmileBASIC 3.x
| Poor parameter validation on "BGSCREEN" command
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]], [[User: ChampionLeake|ChampionLeake]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|-
| Mononoke Forest
| String Buffer Overflow via unchecked string length
| The game stores plaintext profile names in the savefile. The profile names are strcpy/memcpy to different areas of the game's functions in the stack. Using a large extensive profile name, a user can overwrite some stack-registers and point to stack buffer addresses to eventually gain control of the stack to lead and form a rop-chain.
| None
| App: v1.0.0
| August 14, 2019
| February 8, 2019
| [[User: ChampionLeake|ChampionLeake]] and [[User: Kartik|Kartik]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

* [[Pyramids (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [[Pyramids 2 (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.

* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.

* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.

* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.

* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.

* "Mutant Mudds": Overwriting the savefile with random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.

* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.

* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.

* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls

==Crashes needing investigation==
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|-
| 3DS [[System Settings]] stack smash via title strings in [[DSiWare_Exports]]
| DSiWare export banners contain 16 consecutive 0x100 byte, utf-16 game title strings for different languages. Nintendo correctly limits the string's max length by placing a NULL at str[127] before it's copied to the stack. However, they didn't allocate enough space for all 128 wchars (char/wchar type confusion?), so an attacker can craft a valid full-length string that will crash the stack at about str+0xEC. ROP execution can then be obtained from this crash in DSiWare Data Management as demonstrated [https://github.com/zoogie/Bannerbomb3 here].

Interesting note: A line feed wchar (00 0A) at any point in the string before the crash offset will prevent the crash from occurring.
| None
| [[11.13.0-45]]
| Dec. 2018
| Zoogie
|-
| 3DS SAFE_MODE [https://www.3dbrew.org/wiki/System_Settings#System_Updater System Updater] stack smash from proxy-url string
| During [[Recovery Mode]] and after all 3 wifi slots fail to find an access point for sysupdate, a user is permitted to access the wifi settings mode to make changes. Here, if the proxy-url field string's NULL terminator had been altered beforehand, a stack smash can occur when the user selects Proxy Settings -> Detailed Setup and the corrupted url string is displayed.

This is a difficult crash to control because the url string is converted from ascii to utf-16 between the slot and stack, effectively reducing the available gadgets to 0.4% of the normal amount. It's possible to improvise an "escape" using an eoreq pc w/shift gadget to combine registers and form a jump that can access 1/2 of all available gadgets.

Because this exploit runs *under* SAFE_MODE, it's possible to run safehax with one's choice of k11 and arm9 hax. Prerequisite: a userland exploit with cfg:s/i access to modify the wifi slot. A demonstration can be viewed [https://github.com/zoogie/unSAFE_MODE here].
| None
| [[11.13.0-45]]
| Jan. 2020
| Zoogie
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.

This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| [[10.7.0-32|10.7.0-32]]
|
| [[9.9.0-26|9.9.0-26]]
| February 25, 2016
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| Theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| <Old3DS/New3DS version which added initial theme support>
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| Shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
| [[9.3.0-21|9.3.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[5.0.0-11|5.0.0-X]]
|
| [[2.0.0-2|2.0.0-X]]
| June 9, 2016
| June 9, 2016
| [[User:Yellows8|Yellows8]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

3DS Userland Flaws

2019-07-25T20:48:27Z

EvilFlight: /* System applications */

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| App: v1.1
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| Citizens of Earth
| Save file read stack smash
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.
| None
| [[10.7.0-32]].
| Time of exploit release.
| May 5, 2016
| [[User:Dazzozo|Dazzozo]]
|-
| SmileBASIC 3.x
| Poor parameter validation on "BGSCREEN" command
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

* [[Pyramids (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [[Pyramids 2 (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.

* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.

* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.

* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.

* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.

* "Mutant Mudds": Overwriting the savefile with random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.

* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.

* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.

* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls

==Crashes needing investigation==
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|-
| 3DS [[System Settings]] stack smash via title strings in [[DSiWare_Exports]]
| DSiWare export banners contain 16 consecutive 0x100 byte, utf-16 game title strings for different languages. Nintendo correctly limits the string's max length by placing a NULL at str[127] before it's copied to the stack. However, they didn't allocate enough space for all 128 wchars (char/wchar type confusion?), so an attacker can craft a valid full-length string that will crash the stack at about str+0xEC. ROP execution can then be obtained from this crash in DSiWare Data Management as demonstrated [https://github.com/zoogie/Bannerbomb3 here].

Interesting note: A line feed wchar (00 0A) at any point in the string before the crash offset will prevent the crash from occurring.
| None
| [[11.10.0-43]]
| Dec. 2018
| Zoogie
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.

This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| [[10.7.0-32|10.7.0-32]]
|
| [[9.9.0-26|9.9.0-26]]
| February 25, 2016
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| Theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| <Old3DS/New3DS version which added initial theme support>
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| Shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
| [[9.3.0-21|9.3.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[5.0.0-11|5.0.0-X]]
|
| [[2.0.0-2|2.0.0-X]]
| June 9, 2016
| June 9, 2016
| [[User:Yellows8|Yellows8]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

3DS System Flaws

2019-01-10T19:58:10Z

EvilFlight:

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 [[3DS_Userland_Flaws|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' 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_Services|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 [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! 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
| [[User:Derrek|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
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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?
| [[User:Yellows8|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|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 [[wikipedia:Pohlig-Hellman algorithm|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
| [[User:Myria|Myria]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|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
| [[User:Yellows8|Yellows8]]
|}

== Boot ROM ==
{| class="wikitable" border="1"
! 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 [[Flash_Filesystem|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
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[User:Yellows8|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 [[Flash_Filesystem|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
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution.
| None
| New3DS
| 2015(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|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 <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure
| None
| New3DS
| August 2015
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]
|}

== ARM9 software ==

=== arm9loader ===
{| class="wikitable" border="1"
|-
! 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
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|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
| [[User:Yellows8|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-36|11.3.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|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 [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|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-6|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-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|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 [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| arm9loaderhax: Missing verification block for the 9.6 keys
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 [[Savegames#6.0.0-11_Savegame_keyY|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 [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| [[11.3.0-36|11.3.0-X]]
| March 2015
|
| [[User:Plutooo|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-36|11.3.0-X]]
| Sometime in 2015
|
| [[User:Plutooo|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-22|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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! 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-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|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-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|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 [[AES|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-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|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-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|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 [http://dsibrew.org/wiki/NDS_Format 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-41|11.8.0-X]]
| [[11.8.0-41|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-22|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-36|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-37|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-29|10.4.0-X]]
|
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|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-33|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-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|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-41|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-33|11.8.0]]
| [[11.8.0-33|11.8.0]]
| ?
| Wiki: August 5, 2018
| Everyone
|-
| TWL_FIRM cmd-9 unchecked offset
| In [[1.0.0-0|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-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.
| ARM9 code execution
| [[2.0.0-2|2.0.0-X]]
| [[2.0.0-2|2.0.0-X]]
| January 2018
| Wiki: August 5, 2018
| [[User:Riley|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-33|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-24|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-24|9.6.0-X]]
| March 2015
| August 12, 2018
| [[User:Yellows8|Yellows8]], [[User:Myria|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:

<pre>...
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.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|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-36|11.3.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| This requires access to the [[Process_Services|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-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|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 [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|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-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|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
|
| [[User:Yellows8|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 useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.
| 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.8.0-X
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| seedminer: movable.sed keyY vulnerable to brute-force
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|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.8.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.8.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-11|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-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|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|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|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|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]]. This leaves the [[OTP Registers|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-5|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 [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|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 Registers|OTP]] area.
Decrypting New3DS sector 0x96 keyblock.
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! 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|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-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|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-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|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-36|11.3.0-X]]
| [[11.3.0-36|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-36|11.3.0-X]]
| November 26, 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| November 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| 2012
| Everyone
|-
| [[SVC|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-33|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 [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|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 [[SVC|SVCs]] access table at all.

Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|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_API|services]], ControlMemory on any given mem-region.
| None
| [[11.3.0-36|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-35|11.2.0-X]]
| [[11.2.0-35|11.2.0-X]]
| 2016
| nedwill, [[User:Derrek|derrek]]
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|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-36|11.3.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
|
| [[User:Derrek|derrek]], aliaspider
|-
| memchunkhax2
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|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-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
|
| [[User:Derrek|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|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-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| AffinityMask/processorid validation
| With [[10.0.0-27|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-27|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-27|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-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|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-21|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|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|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-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|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]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|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 <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|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
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|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
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[Services|"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
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|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 <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[Config_Services|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
| [[User:Nba_Yoh|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
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|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
| [[User:Yellows8|Yellows8]]
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|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
| [[User:Yellows8|Yellows8]]
|-
| [[MVD_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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.
| [[11.4.0-37|11.4.0-X]]
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|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-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|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-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|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 [[10.6.0-31|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|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|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 [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| [[11.4.0-37|11.4.0-X]]
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|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) [[#Process9|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-27|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)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|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
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|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?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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?
|
| [[User:Yellows8|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 [[RO_Services|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-36|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-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|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 [[SVC|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, [[User:Plutooo|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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|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 [[NWM_Services|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]]
|}

FirmwareNews

2019-01-04T05:37:05Z

EvilFlight:

As of this writing, the latest firmware is '''[[11.9.0-42]]'''.

See [[Homebrew Exploits|here]] regarding running homebrew.

----

Software-based full system control exploits are known and publicly available for system versions up to and including 11.9.0-42, while [[Bootloader#Non-NAND_FIRM_boot|ntrboothax]] allows for ARM9 arbitrary code execution on any 3DS-family console regardless of system firmware version (or even its presence at all).

FirmwareNews

2019-01-02T02:05:55Z

EvilFlight:

As of this writing, the latest firmware is '''[[11.9.0-42]]'''.

See [[Homebrew Exploits|here]] regarding running homebrew.

----

Software-based full system control exploits are known and [https://3ds.hacks.guide publicly available] for system versions up to and including the latest firmware shown above, while [[Bootloader#Non-NAND_FIRM_boot|ntrboothax]] allows for ARM9 arbitrary code execution on any 3DS-family console regardless of system firmware version (or even its presence at all).

FirmwareNews

2018-10-05T16:45:48Z

EvilFlight: Seedminer/Frogminer acknowledgment

As of this writing, the latest firmware is '''[[11.8.0-41]]'''.

See [[Homebrew Exploits|here]] regarding running homebrew.

----

Software-based full system control exploits are known and publicly available for system versions up to and including 11.8.0-41, while [[Bootloader#Non-NAND_FIRM_boot|ntrboothax]] allows for ARM9 arbitrary code execution on any 3DS-family console regardless of system firmware version (or even its presence at all).

3DS System Flaws

2018-09-29T02:56:26Z

EvilFlight:

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 [[3DS_Userland_Flaws|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_Services|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 [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! 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
| [[User:Derrek|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
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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?
| [[User:Yellows8|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|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 [[wikipedia:Pohlig-Hellman algorithm|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
| [[User:Myria|Myria]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|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
| [[User:Yellows8|Yellows8]]
|}

== Boot ROM ==
{| class="wikitable" border="1"
! 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 [[Flash_Filesystem|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
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[User:Yellows8|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 [[Flash_Filesystem|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
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution.
| None
| New3DS
| 2015(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|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 <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure
| None
| New3DS
| August 2015
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]
|}

== ARM9 software ==

=== arm9loader ===
{| class="wikitable" border="1"
|-
! 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
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|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
| [[User:Yellows8|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-36|11.3.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|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 [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|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-6|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-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|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 [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| arm9loaderhax: Missing verification block for the 9.6 keys
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 [[Savegames#6.0.0-11_Savegame_keyY|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 [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| [[11.3.0-36|11.3.0-X]]
| March 2015
|
| [[User:Plutooo|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-36|11.3.0-X]]
| Sometime in 2015
|
| [[User:Plutooo|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-22|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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! 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-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|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-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|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 [[AES|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-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|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-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|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 [http://dsibrew.org/wiki/NDS_Format 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-41|11.8.0-X]]
| [[11.8.0-41|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-22|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-36|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-37|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-29|10.4.0-X]]
|
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|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-33|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-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|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-41|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-33|11.8.0]]
| [[11.8.0-33|11.8.0]]
| ?
| Wiki: August 5, 2018
| Everyone
|-
| TWL_FIRM cmd-9 unchecked offset
| In [[1.0.0-0|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-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.
| ARM9 code execution
| [[2.0.0-2|2.0.0-X]]
| [[2.0.0-2|2.0.0-X]]
| January 2018
| Wiki: August 5, 2018
| [[User:Riley|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-33|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-24|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-24|9.6.0-X]]
| March 2015
| August 12, 2018
| [[User:Yellows8|Yellows8]], [[User:Myria|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:

<pre>...
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.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|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-36|11.3.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| This requires access to the [[Process_Services|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-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|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 [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|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-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|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
|
| [[User:Yellows8|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 useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.
| 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.8.0-X
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| seedminer: movable.sed keyY vulnerable to brute-force
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|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.8.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 (only am:sys is needed). 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.8.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-11|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-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|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|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|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|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]]. This leaves the [[OTP Registers|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-5|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 [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|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 Registers|OTP]] area.
Decrypting New3DS sector 0x96 keyblock.
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! 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|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-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|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-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|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-36|11.3.0-X]]
| [[11.3.0-36|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-36|11.3.0-X]]
| November 26, 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| November 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| 2012
| Everyone
|-
| [[SVC|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-33|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 [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|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 [[SVC|SVCs]] access table at all.

Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|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_API|services]], ControlMemory on any given mem-region.
| None
| [[11.3.0-36|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-35|11.2.0-X]]
| [[11.2.0-35|11.2.0-X]]
| 2016
| nedwill, [[User:Derrek|derrek]]
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|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-36|11.3.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
|
| [[User:Derrek|derrek]], aliaspider
|-
| memchunkhax2
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|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-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
|
| [[User:Derrek|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|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-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| AffinityMask/processorid validation
| With [[10.0.0-27|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-27|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-27|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-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|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-21|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|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|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-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|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]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|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 <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|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
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|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
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[Services|"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
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|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 <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[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
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|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
| [[User:Yellows8|Yellows8]]
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|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
| [[User:Yellows8|Yellows8]]
|-
| [[MVD_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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.
| [[11.4.0-37|11.4.0-X]]
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|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-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|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-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|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 [[10.6.0-31|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|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|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 [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| [[11.4.0-37|11.4.0-X]]
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|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) [[#Process9|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-27|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)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|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
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|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?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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?
|
| [[User:Yellows8|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 [[RO_Services|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-36|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-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|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 [[SVC|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, [[User:Plutooo|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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|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 [[NWM_Services|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]]
|}

Mysteries

2018-04-17T00:16:52Z

EvilFlight:

The following is a list of mysteries.

== General ==
* What is the CTR abbreviation?
: C may stand for Chiheisen ("horizon" in Japanese, the O3DS's codename being "Project Horizon").
:: Not true, Horizon refers to the OS.

== Hardware ==
=== Why are there two CTRCARD controllers? ===
'''Background:''' Also [http://problemkaputt.de/twl-core.jpg DSi SoC pinout] shows evidence of dual NTRCARD controllers on the final DSi SoC. (This was a [http://i.imgur.com/0kJlbEw.png planned feature] of the DSi before being axed later in development)

=== Why are there two EMMC controllers? ===
'''Theory:''' At some point during 3DS hardware development there was an idea to split up CTR and TWL nand into two different chips.
=== Is there a JTAG? ===
=== Is there more than one revision of the bootrom? ===
'''Background:''' Bootrom visible portion has been dumped on the entire 3DS Family (3DS, 3DSXL, 2DS, New3DS, New3DSXL, New2DSXL), and even a prototype board from April(?) 2010. All matching exactly.

=== What is the EMMC controller @ 0x10100000 doing? ===
'''Background:''' There's dead code in NWM referencing it.
=== Why did they put NTRCARD accessible from ARM11? ===
'''Theory:''' At some point during 3DS hardware development there was a concept where ARM11 ran a menu with DS(i) icons while ARM9 was in TWL mode.

=== Is there a secret message embedded in the 3DS keyscrambler constant? ===
'''Background:''' TWL key scrambler constant was "Nintendo Co., Ltd" in Japanese ("任天堂株式会社"), UTF-16LE encoded, with byte order mark. The 3DS key scrambler constant, by comparison, is random-looking.

=== What is the PDN abbreviation? ===
: Power distribution network

=== How does Nintendo reflash bricked systems? ===
Before trying to boot from NAND, the bootrom checks to see if a key combination (Start + Select + X) is being held, and whether the shell is closed. If so, it tries to boot from an inserted NTR (Nintendo DS) cartridge.
This allows to execute a FIRM that is probably used by Nintendo to reflash the system.

== Software ==
=== What was the problem in "initial program loader" that was mentioned in an FCC filing by Nintendo for 2DS? ===
'''Background:''' http://www.neogaf.com/forum/showthread.php?t=814624&page=1
=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
=== What is the PTM abbreviation? ===
: Power/time management

=== Why is the DTCM not used anywhere except bootrom? ===
'''Background:''' Bootrom is known to use part of DTCM as state, memsetting it to 0 when it's done. After that, it is never used again.
=== How is CTRAging launched during factory setup? ===
'''Background:''' No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.

'''Theory:''' NtrBoot another time
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===
=== Is there a deterministic formula for calculating the Movable.sed KeyY high u64? ===
'''Background:''' We know now that the high 4 bytes of KeyY can be reliably estimated to be 1/5th of the LocalFriendCodeSeed (low 8 bytes of KeyY), which is close enough to brute force. However, the actual value is usually about 0-4000 units off the actual high u32 of the KeyY (called msed3 in the seedminer implementation). Could there possibly be a deterministic formula given this 1/5 ratio is so close to the correct value? It's difficult to imagine this is just a coincidence.

Mii Maker

2018-02-28T03:24:17Z

EvilFlight:

'''Mii Maker''' lets you create [[Mii]]s, and is the successor of the Wii's Mii Channel.

It can transfer Miis over [[NWM_Services|local wireless]] from other systems running Mii Maker (3DS/Wii U), or receive, but not send, from Mii Channel.

== Wii Mii Channel transfer protocol ==

The Wii beacons are similar to the usual multi-cart NDS beacons, except: beacon_type is zero, and payload size is 0x14. The payload data is just the Wii UTF-16 nickname, with some extra unused zero data. The usual multi-cast NDS protocol is used for sending the 3DS nick to the Wii. After many keep-alive frames, it eventually sends a bunch of frames, each containing the whole Mii. There's a 6-byte header, followed by [http://wiibrew.org/wiki/Wiimote/Mii_Data Mii data]. At the end of these frames like most NDS frames is the 0200 byte marker.

== Mii QR Code format ==

3DS Mii QR is a standard 57x57 pixel Level 10 High ECC QR code with 'Mii' logo in center (refer to [http://www.denso-wave.com/qrcode Denso-Wave Inc] web site for QR Code format specifications). It contains 0x70-bytes of binary data. 3DS seems to have a fully implemented QR-code decoder, as it can interpret such Mii binary data being encoded even in the smallest possible for that data size Level 6 Low ECC QR code.

The data itself is encrypted with AES-CCM, xorpads can be determined from known plaintext here. The Mii Maker application uses the [[NS]] APT Wrap/Unwrap commands to encrypt/decrypt this Mii data. For the NS [[APT:Unwrap|Unwrap]] command, the Mii Maker application uses nonceoffset=12, noncesize=10, and inputbuffer-size=0x60. Note that the actual nonce size is 8 bytes due to Wrap/Unwrap implementation, and the nonce data should be moved 12 bytes afterwards after decryption. The rest of the data at 0x8-0x5F is encrypted, and should be split into two parts after decryption, with the nonce data in the middle. (See [[APT:Wrap|Wrap]] and [[APT:Unwrap|Unwrap]] for more information)

{| class="wikitable"
|-
! Offset
! Length
!
|-
| 0x0
| 0x4
| Mii ID (big-endian 32-bit unsigned integer) The most significant 3 bits determine whether the Mii is Special, Foreign, or Normal [http://www.davidhawley.co.uk/special-miis-gold-pants-and-creating.aspx] time_offset = (mii_id & 0x0FFFFFFF) * 2; time_offset is the time the Mii was created, represented as the number of seconds since 01/01/2010 00:00:00
|-
| 0x4
| 0x4
| High 4 octets of MAC address [http://www.adminsub.net/mac-address-finder/nintendo]
|-
| 0x8
| 0x4
| [[Mii#Mii_ID|Mii ID]], the encrypted data begins here.
|-
| 0xC
| 0x8
| System ID (this ID is produced by the output from [https://www.3dbrew.org/wiki/Cfg:GenHashConsoleUnique GenHashConsoleUnique(0x0)])
|-
| 0x14
| 0x2
| Low 2 octets of MAC address
|-
| 0x16
| 0x2
| padding (0000)
|-
| 0x18
| 0x2
| Bit-mapped: Birthday (4bit-day,5bit-month), Sex, Shirt, ??
|-
| 0x1A
| 0x14
| UTF-16 Mii Name (10 chars max)
|-
| 0x2E
| 0x2
| width & height
|-
| 0x30
| 0x1
| bit 0: disable sharing bit 1-4: face shape bit 5-7: skin color
|-
| 0x31
| 0x1
| bit 0-3: wrinkles bit 4-7: makeup
|-
| 0x32
| 0x1
| hair style
|-
| 0x33
| 0x1
| bit 0-2: hair color bit 3: flip hair
|-
| 0x34
| 0x4
| unknown
|-
| 0x38
| 0x1
| bit 0-4: eyebrow style bit 5-7: eyebrow color
|-
| 0x39
| 0x1
| bit 0-3: eyebrow scale bit 4-6: eyebrow yscale
|-
| 0x3A
| 0x2
| note that the bytes are swapped over (little-endian layout) bit 0-3: eyebrow rotation bit 5-8: eyebrow x spacing bit 9-13: eyebrow y position
|-
| 0x3C
| 0x1
| Allow Copying
|-
| 0x3D
| 0x3
| unknown
|-
| 0x40
| 0x1
| Mii Sharing Value
|-
| 0x41
| 0x7
| unknown
|-
| 0x48
| 0x14
| UTF-16 Author Name (10 chars max)
|-
| 0x5C
| 0x2
| unknown
|-
| 0x5E
| 0x2
| CRC16 over the previous 0x5E
|-
| 0x60
| 0x10
| AES-CCM MAC
|}

* QR codes made from the same 3DS for the same Mii are use the same AES-CCM nonce (you can recreate the xorpad by xoring with known values from this table).

== Mii Database ==

Created, received, or even met-in-multiplayer Miis are saved in [[Mii|CFL_DB.dat]].

== Savedata ==
=== editSaveData.bin ===
{| class="wikitable"
|-
! Offset
! Length
!
|-
| 0x0
| 0x4
| "TIDE" header (EDIT byteswapped)
|-
| 0x4
| 0x4
| zero
|-
| 0xC
| 0x4 (?)
| 01000000 (constant?)
|-
| 0x100
| 0x4
| Number of scanned Special Mii QRs
|-
| 0x104
| -
| Some data identifying each scanned Special Mii QRs, for the purpose of not making them scannable again. 8 or 12 byte each?
|-
| 0x2904
| 0x4
| Checksum?
|}

== ExtData ==
The ExtData [[Extdata#Filesystem|File System]] for Mii Maker is as follows:

root
├── icon
├── boss
└── user
└── ExBanner
└── COMMON.bin

{| class="wikitable" border="1"
|-
! File
! Details
! Size
! FW Introduced
! Plaintext
|-
| icon
| Duplicate from Application ExeFS. Always image 00000002.
| 0x36c0 Bytes
| [[1.0.0-0]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/MiiMakerExtdata/icon Download]
|-
| COMMON.bin
| [[Extended Banner]] for Home Menu. Always image 00000003.
| 0x20224 Bytes
| [[1.0.0-0]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/MiiMakerExtdata/COMMON.bin Download]
|}

Talk:Main Page

2018-02-25T00:46:57Z

EvilFlight: /* Seedminer? */

So how about a [http://wiisixtyfour.webs.com/images/3dsbrew-bg4545.png logo]? --[[User:Bg4545|wiisixtyfour]] 06:59, 1 April 2011 (CEST)

Great one, let's put it as default logo ! --[[User:GeekShadow|GeekShadow]] 09:37, 1 April 2011 (CEST)

Here's one I made, which doesn't use any official artwork/photography: [http://dl.dropbox.com/u/1077900/Graphics/3dbrew.png PNG] [http://dl.dropbox.com/u/1077900/Graphics/3dbrew.svg SVG] --[[User:BHSPitMonkey|BHSPitMonkey]] 05:36, 7 April 2011 (CEST)

How about making the default skin [http://3dbrew.org/w/index.php?title=Main_Page&useskin=monobook MonoBook]?, I like the it better. --[[User:Elisherer|Elisherer]] 10:58, 6 October 2011 (CEST)

I want to dump RAM.What can I do now?How can I learn? --[[User:Matyapiro31|Matyapiro31]] 16:30, 20 November 2011 (CET)
:Sorry, this is not the correct page to talk about that. However, it's a good topic for our new forum! http://n-dev.net/index.php --[[User:Lazymarek9614|Lazymarek9614]] 17:43, 20 November 2011 (CET)

-Hello, I would like to translate this great wiki into French, how should I do ? Thanks :)
:I guess each page you want to translate you need to edit the page's link with a '/' (slash) after it and the language code (fr for french i think), for instance edit the page http://www.3dbrew.org/wiki/Main_Page/Fr and then put a link on the bottom next to Japanese.. --[[User:Elisherer|Elisherer]] 17:49, 21 December 2011 (CET)
::You should take a look [http://www.mediawiki.org/wiki/Template:Languages here]...Apperantly we don't have the needed template for it to work automaticaly maybe we need the admin to install some kind of extension to support this type of thing. --[[User:Elisherer|Elisherer]] 18:59, 21 December 2011 (CET)

-Yes, it would be more practical. For now, I'll continue translating like that, please tell me when the plugin is added.
---I added a language selection bar at the bottom of each main page.

I cannot have be accessing for a week.Why?--Matyapiro31 12:51, 19 April 2012 (CEST)
== SVG upload ==

Hey neimod, can you enable svg uploading? I want to upload graphics for the buttons [http://sherer.co.il/svg/ I made] (for future homebrew and stuff)--[[User:Elisherer|Elisherer]] 14:41, 9 February 2012 (CET)
: You can address this issue to [[User:Mha|Mha]] (mha on irc) --[[User:Neimod|Neimod]] 19:04, 9 February 2012 (CET)

Game Screenshots...

Hey guys how can i export the photos from DoA:D from 3DS to PC i have the right file but on mc if i change to .jpg or mpo it does not open...

== Does anyone know how to tell an installed/braindumped title's version? ==

I'm on 9.3 and have hax. I want to know this so I can contribute versions to to the title list. --[[User:Hiccup|Hiccup]] ([[User talk:Hiccup|talk]]) 14:57, 6 January 2016 (CET)
:1.If you have NAND Xorpad you can dump and decrypt to get the .[[TMD]] files and read the version from it. 2.Use [[AM]] service, and use "AM_ListTitles" from libctru, structure "AM_TitleEntry" includes the version. 3.Most versions of System Titles are fetched via System Update SOAP response, thanks to [[User:Yellows8|Yellows8]] for that.
:BTW I suggest you to ask questions on 4dsdev.org or IRC(EFNET.org#3dsdev) thus it may be dealt faster. --[[User:Syphurith|Syphurith]] ([[User talk:Syphurith|talk]]) 11:35, 7 January 2016 (CET)

== question ==

Can we get an actual board to discuss things instead of a shitty wiki that's setup like this? --[[User:NintendoFan|NintendoFan]] ([[User talk:NintendoFan|talk]]) 09:36, 3 May 2016 (CEST)

: It says so in the previous discussion on this page :P [4dsdev.org] --[[User:Ryccardo|Ryccardo]] ([[User talk:Ryccardo|talk]]) 09:52, 3 May 2016 (CEST)

:: 4dsdev looks quite dead with a sticky about merging that is 5 months old. :P GBAtemp [http://gbatemp.net/categories/nintendo-3ds-discussions.198/] is quite active, why not there? --[[User:MKody|MKody]] ([[User talk:MKody|talk]]) 10:40, 3 May 2016 (CEST)

::: Eh, while GBATemp is a good place I'd much rather have a board that's specifically dedicated to 3DS modding, not just modding in general. Also, I'd much rather start fresh with a new board than trying to revive a dead community that's been merged into some other board. --[[User:NintendoFan|NintendoFan]] ([[User talk:NintendoFan|talk]]) 07:58, 6 May 2016 (CEST)

== Uploads are broken ==

MediaWiki throws a MWException whenever I try to upload an image file. Perhaps uploads are not configured properly? —'''[[User:Nicholatian|nicho]][[User_talk:Nicholatian|latian]]''[[Special:Contributions/Nicholatian|fury]]''''' 20:09, 15 June 2016 (CEST)

== Seedminer? ==

There should be some documentation about seedminer on this wiki.

Please check the 3ds system flaws page: search "movable.sed keyY vulnerable to brute-force"

3DS System Flaws

2018-02-18T03:03:06Z

EvilFlight:

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 [[3DS_Userland_Flaws|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_Services|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 [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! 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
| [[User:Derrek|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
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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?
| [[User:Yellows8|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| The [[Flash_Filesystem|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).

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
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|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 [[wikipedia:Pohlig-Hellman algorithm|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
| [[User:Myria|Myria]]
|-
| Boot9 AES keyinit function issues
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[User:Yellows8|Yellows8]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|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
| [[User:Yellows8|Yellows8]]
|-
| sighax: Boot9 improper PKCS #1 v1.5 signature validation
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of 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, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.
# 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.

When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.
| None
| New3DS
| July 2015
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution.
| None
| New3DS
| 2015(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).
|}

== ARM9 software ==

=== arm9loader ===
{| class="wikitable" border="1"
|-
! 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
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|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
| [[User:Yellows8|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-36|11.3.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|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 [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|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-6|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-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|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 [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 [[Savegames#6.0.0-11_Savegame_keyY|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 [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| [[11.3.0-36|11.3.0-X]]
| March, 2015
|
| [[User:Plutooo|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-22|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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! 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-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|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-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|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 [[AES|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 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-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|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 boot9 prot. Arm9 code execution on factory/earlier firmware.
| [[1.0.0-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
|-
| 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-22|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-36|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-37|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-29|10.4.0-X]]
|
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|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-33|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-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]
| ?
|
| ?
|-
| 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:

<pre>...
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.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|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-36|11.3.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| This requires access to the [[Process_Services|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-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|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 [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|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-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|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
|
| [[User:Yellows8|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 useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.
| 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
|
| [[User:Yellows8|Yellows8]]
|-
| 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.6.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.6.0-X
| 2015?
| December 2016
| Everyone
|-
| [[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-11|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-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|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|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|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|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|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-5|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 [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! 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|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-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|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-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|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-36|11.3.0-X]]
| [[11.3.0-36|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-36|11.3.0-X]]
| November 26, 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| November 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| 2012
| Everyone
|-
| [[SVC|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-33|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 [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|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 [[SVC|SVCs]] access table at all.

Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|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_API|services]], ControlMemory on any given mem-region.
| None
| [[11.3.0-36|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-35|11.2.0-X]]
| [[11.2.0-35|11.2.0-X]]
| 2016
| nedwill, [[User:Derrek|derrek]]
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|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-36|11.3.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
|
| [[User:Derrek|derrek]], aliaspider
|-
| memchunkhax2
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|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-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
|
| [[User:Derrek|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|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-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| AffinityMask/processorid validation
| With [[10.0.0-27|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-27|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-27|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-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|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-21|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|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|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-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|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]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|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 <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|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
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|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
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[Services|"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
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|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 <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[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
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|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
| [[User:Yellows8|Yellows8]]
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|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
| [[User:Yellows8|Yellows8]]
|-
| [[MVD_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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.
| [[11.4.0-37|11.4.0-X]]
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|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-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|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-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|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 [[10.6.0-31|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|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|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 [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| [[11.4.0-37|11.4.0-X]]
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|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) [[#Process9|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-27|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)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|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
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|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?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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?
|
| [[User:Yellows8|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 [[RO_Services|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-36|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-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|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 [[SVC|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, [[User:Plutooo|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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|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 [[NWM_Services|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]]
|}

3DS System Flaws

2018-02-01T05:56:00Z

EvilFlight:

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 [[3DS_Userland_Flaws|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_Services|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 [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! 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
| [[User:Derrek|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
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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?
| [[User:Yellows8|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| The [[Flash_Filesystem|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).

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
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|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 [[wikipedia:Pohlig-Hellman algorithm|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
| [[User:Myria|Myria]]
|-
| Boot9 AES keyinit function issues
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[User:Yellows8|Yellows8]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|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
| [[User:Yellows8|Yellows8]]
|-
| sighax: Boot9 improper PKCS #1 v1.5 signature validation
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of 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, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.
# 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.

When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.
| None
| New3DS
| July 2015
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution.
| None
| New3DS
| 2015(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).
|}

== ARM9 software ==

=== arm9loader ===
{| class="wikitable" border="1"
|-
! 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
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|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
| [[User:Yellows8|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-36|11.3.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|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 [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|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-6|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-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|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 [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 [[Savegames#6.0.0-11_Savegame_keyY|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 [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| [[11.3.0-36|11.3.0-X]]
| March, 2015
|
| [[User:Plutooo|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-22|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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! 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-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|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-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|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 [[AES|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 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-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|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 boot9 prot. Arm9 code execution on factory/earlier firmware.
| [[1.0.0-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
|-
| 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-22|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-36|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-37|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-29|10.4.0-X]]
|
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|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-33|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-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]
| ?
|
| ?
|-
| 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:

<pre>...
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.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|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-36|11.3.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| This requires access to the [[Process_Services|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-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|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 [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|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-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|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
|
| [[User:Yellows8|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 useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.
| 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
|
| [[User:Yellows8|Yellows8]]
|-
| 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.6.0-X
| December 2017
| January 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-11|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-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|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|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|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|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|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-5|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 [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! 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|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-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|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-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|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-36|11.3.0-X]]
| [[11.3.0-36|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-36|11.3.0-X]]
| November 26, 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| November 2016
| [[User:Yellows8|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-36|11.3.0-X]]
| 2012
| Everyone
|-
| [[SVC|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-33|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 [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|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 [[SVC|SVCs]] access table at all.

Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|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_API|services]], ControlMemory on any given mem-region.
| None
| [[11.3.0-36|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-35|11.2.0-X]]
| [[11.2.0-35|11.2.0-X]]
| 2016
| nedwill, [[User:Derrek|derrek]]
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|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-36|11.3.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
|
| [[User:Derrek|derrek]], aliaspider
|-
| memchunkhax2
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|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-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
|
| [[User:Derrek|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-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|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-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| AffinityMask/processorid validation
| With [[10.0.0-27|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-27|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-27|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-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|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-21|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|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|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-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|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]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|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 <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|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
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|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
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|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?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[Services|"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
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|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 <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! 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
|-
| [[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
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|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
| [[User:Yellows8|Yellows8]]
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|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
| [[User:Yellows8|Yellows8]]
|-
| [[MVD_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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.
| [[11.4.0-37|11.4.0-X]]
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|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-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|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-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|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 [[10.6.0-31|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|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|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 [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| [[11.4.0-37|11.4.0-X]]
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|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) [[#Process9|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-27|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)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|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
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|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?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|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
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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?
|
| [[User:Yellows8|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 [[RO_Services|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-36|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-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|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 [[SVC|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, [[User:Plutooo|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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|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?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|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 [[NWM_Services|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
| [[User:Yellows8|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
| [[User:Yellows8|Yellows8]]
|}

Mii Maker

2018-01-12T01:00:41Z

EvilFlight:

'''Mii Maker''' lets you create [[Mii]]s, and is the successor of the Wii's Mii Channel.

It can transfer Miis over [[NWM_Services|local wireless]] from other systems running Mii Maker (3DS/Wii U), or receive, but not send, from Mii Channel.

== Wii Mii Channel transfer protocol ==

The Wii beacons are similar to the usual multi-cart NDS beacons, except: beacon_type is zero, and payload size is 0x14. The payload data is just the Wii UTF-16 nickname, with some extra unused zero data. The usual multi-cast NDS protocol is used for sending the 3DS nick to the Wii. After many keep-alive frames, it eventually sends a bunch of frames, each containing the whole Mii. There's a 6-byte header, followed by [http://wiibrew.org/wiki/Wiimote/Mii_Data Mii data]. At the end of these frames like most NDS frames is the 0200 byte marker.

== Mii QR Code format ==

3DS Mii QR is a standard 57x57 pixel Level 10 High ECC QR code with 'Mii' logo in center (refer to [http://www.denso-wave.com/qrcode Denso-Wave Inc] web site for QR Code format specifications). It contains 0x70-bytes of binary data. 3DS seems to have a fully implemented QR-code decoder, as it can interpret such Mii binary data being encoded even in the smallest possible for that data size Level 6 Low ECC QR code.

The data itself is encrypted with AES-CCM, xorpads can be determined from known plaintext here. The Mii Maker application uses the [[NS]] APT Wrap/Unwrap commands to encrypt/decrypt this Mii data. For the NS [[APT:Unwrap|Unwrap]] command, the Mii Maker application uses nonceoffset=12, noncesize=10, and inputbuffer-size=0x60. Note that the actual nonce size is 8 bytes due to Wrap/Unwrap implementation, and the nonce data should be moved 12 bytes afterwards after decryption. The rest of the data at 0x8-0x5F is encrypted, and should be split into two parts after decryption, with the nonce data in the middle. (See [[APT:Wrap|Wrap]] and [[APT:Unwrap|Unwrap]] for more information)

{| class="wikitable"
|-
! Offset
! Length
!
|-
| 0x0
| 0x4
| Mii ID (big-endian 32-bit unsigned integer) The most significant 3 bits determine whether the Mii is Special, Foreign, or Normal [http://www.davidhawley.co.uk/special-miis-gold-pants-and-creating.aspx] time_offset = (mii_id & 0x0FFFFFFF) * 2; time_offset is the time the Mii was created, represented as the number of seconds since 01/01/2010 00:00:00
|-
| 0x4
| 0x4
| High 4 octets of MAC address [http://www.adminsub.net/mac-address-finder/nintendo]
|-
| 0x8
| 0x4
| [[Mii#Mii_ID|Mii ID]], the encrypted data begins here.
|-
| 0xC
| 0x8
| System ID
|-
| 0x14
| 0x2
| Low 2 octets of MAC address
|-
| 0x16
| 0x2
| padding (0000)
|-
| 0x18
| 0x2
| Bit-mapped: Birthday (4bit-day,5bit-month), Sex, Shirt, ??
|-
| 0x1A
| 0x14
| UTF-16 Mii Name (10 chars max)
|-
| 0x2E
| 0x2
| width & height
|-
| 0x30
| 0x1
| bit 0: disable sharing bit 1-4: face shape bit 5-7: skin color
|-
| 0x31
| 0x1
| bit 0-3: wrinkles bit 4-7: makeup
|-
| 0x32
| 0x1
| hair style
|-
| 0x33
| 0x1
| bit 0-2: hair color bit 3: flip hair
|-
| 0x34
| 0x4
| unknown
|-
| 0x38
| 0x1
| bit 0-4: eyebrow style bit 5-7: eyebrow color
|-
| 0x39
| 0x1
| bit 0-3: eyebrow scale bit 4-6: eyebrow yscale
|-
| 0x3A
| 0x2
| note that the bytes are swapped over (little-endian layout) bit 0-3: eyebrow rotation bit 5-8: eyebrow x spacing bit 9-13: eyebrow y position
|-
| 0x3C
| 0x1
| Allow Copying
|-
| 0x3D
| 0x3
| unknown
|-
| 0x40
| 0x1
| Mii Sharing Value
|-
| 0x41
| 0x7
| unknown
|-
| 0x48
| 0x14
| UTF-16 Author Name (10 chars max)
|-
| 0x5C
| 0x2
| unknown
|-
| 0x5E
| 0x2
| CRC16 over the previous 0x5E
|-
| 0x60
| 0x10
| AES-CCM MAC
|}

* QR codes made from the same 3DS for the same Mii are use the same AES-CCM nonce (you can recreate the xorpad by xoring with known values from this table).

== Mii Database ==

Created, received, or even met-in-multiplayer Miis are saved in [[Mii|CFL_DB.dat]].

== Savedata ==
=== editSaveData.bin ===
{| class="wikitable"
|-
! Offset
! Length
!
|-
| 0x0
| 0x4
| "TIDE" header (EDIT byteswapped)
|-
| 0x4
| 0x4
| zero
|-
| 0xC
| 0x4 (?)
| 01000000 (constant?)
|-
| 0x100
| 0x4
| Number of scanned Special Mii QRs
|-
| 0x104
| -
| Some data identifying each scanned Special Mii QRs, for the purpose of not making them scannable again. 8 or 12 byte each?
|-
| 0x2904
| 0x4
| Checksum?
|}

== ExtData ==
The ExtData [[Extdata#Filesystem|File System]] for Mii Maker is as follows:

root
├── icon
├── boss
└── user
└── ExBanner
└── COMMON.bin

{| class="wikitable" border="1"
|-
! File
! Details
! Size
! FW Introduced
! Plaintext
|-
| icon
| Duplicate from Application ExeFS. Always image 00000002.
| 0x36c0 Bytes
| [[1.0.0-0]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/MiiMakerExtdata/icon Download]
|-
| COMMON.bin
| [[Extended Banner]] for Home Menu. Always image 00000003.
| 0x20224 Bytes
| [[1.0.0-0]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/MiiMakerExtdata/COMMON.bin Download]
|}

Serials

2017-11-25T05:53:40Z

EvilFlight: /* Back of Card Serial */

This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).

== Console Serial Numbers ==

A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.

The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)

After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.

Example: CW404567772

The non-check digits are 40456777. Separating into odd and even groups, we get the following:

Odds: 4 + 4 + 6 + 7 = 21
Evens: 0 + 5 + 7 + 7 = 19

Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.

The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.

The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.

{| class="wikitable"
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)
|-
| ''DSi'' || T || V
|-
| ''DSi XL/LL'' || W || ''unknown''
|-
| ''Wii U'' || F || ''unknown''
|-
| 3DS || C || E
|-
| 3DS XL/LL || S || R
|-
| 2DS || A || P
|-
| New 3DS || Y || Y
|-
| New 3DS XL/LL || Q || Q
|-
| New 2DS XL/LL || N || N
|}

Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.

Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).

{| class="wikitable"
! Sales Region !! Region Lock !! Region Suffix
|-
| Japan || Japan || JF, JH, JM
|-
| North America || North America || W
|-
| Middle East / Southeast Asia || North America || S
|-
| Europe || Europe || EF, EH, EM
|-
| Australia || Europe || AH, AG
|-
| South Korea || Korea || KF, KH, KM
|-
| China (iQue) || China || CF, CH, CM
|}

== Console Models ==

{| class="wikitable"
! Device !! Product Code
|-
| ''DS'' || NTR
|-
| ''DS lite'' || USG
|-
| ''DSi'' || TWL
|-
| ''DSi XL/LL'' || UTL
|-
| ''Wii U'' || WUP
|-
| 3DS || CTR
|-
| 3DS XL/LL || SPR
|-
| 2DS || FTR
|-
| [[New 3DS]] || KTR
|-
| [[New 3DS]] XL/LL || RED
|-
| New 2DS XL/LL || JAN
|}

The DS had the product code NTR (short for Nitro), so we see the TR is recurring.

== Title ID and Unique ID ==
''see [[Titles]]''

== NCCH Product Code ==

This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.

The product code is located in a [[NCCH]]'s header (not its ExHeader).

The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".

So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".

A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:

[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]

{| class="wikitable"
! Category letter !! Description
|-
| P || Cartridge software, or downloadable versions of them.
|-
| N || Digital-only releases, including [[Title list|system applications and applets]].
|-
| M || [[DLC]]
|-
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.
|-
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.
|}

The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].

See the next chapter for explanation of the other components of the Product Code.

== Physical Serial ==

[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]

{| class="wikitable"
! Field !! Length !! Description !! colspan=2 | Values
|-
|-align=center
| rowspan="6" | Product
| rowspan="6" | 2
| rowspan="6" | Product type
|-
| LN || Cartridge
|-
| MA || Instruction manual
|-
| TS || Game box
|-
| FA || Leaflet
|-
| MK || Quick-start Guide
|-align=center
| rowspan="3" | Retail/Demo
| rowspan="3" | 1
| rowspan="3" |
|-
| A || Retail
|-
| Z || Demo
|-align=center
| rowspan="3" | CTR/KTR
| rowspan="3" | 3
| rowspan="3" | Platform
|-
| CTR || 3DS
|-
| KTR || New 3DS
|-align=center
| rowspan="11" | Type
| rowspan="11" | 1
| rowspan="11" |
|-
| A || Retail
|-
| B ||
|-
| C || part of the default serial 'CTAP'
|-
| E ||
|-
| H || used for built in applications like [[Mii Maker]]
|-
| J || normal eShop Title
|-
| K || unknown, seen in Mighty Gunvolt
|-
| S || usually a 3D Classics eShop title
|-
| P || used with GBA eShop titles
|-
| T || used with NES eShop titles
|-align=center
| Identifier
| 2
| colspan=3 |Game name (two alphanumeric characters)
|-align=center
| rowspan="10" | Region
| rowspan="10" | 1
| rowspan="10" |
|-
| E || English (US)
|-
| P || PAL (Europe/Australia)
|-
| J || Japanese (Japan)
|-
| K || Korean (Korea)
|-
| C || Chinese (China/Taiwan)
|-
| Y || Multiple regions
|-
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)
|-
| Z || Multiple regions
|-
| A || All (region-free)
|-
|-align=center
| rowspan="9" | Label Region
| rowspan="9" | 3
| rowspan="9" |
|-
| USA || USA
|-
| EUR || Europe
|-
| CAN || Canada
|-
| JPN || Japan
|-
| KOR || Korea
|-
| TWN || Taiwan/Hong Kong
|-
| CHN || China
|-
| UKV || United Kingdom version(?) (United Kingdom)
|}

=== Electronic Manuals ===

Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:

CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]

CTR-[Type][Identifier][Region]-[Region]-[Digit]

* P/N/T/U - Same as in product code structure
* [Type][Identifier][Region] - Same as in serial structure
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.

'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.

==Back of Card Serial==
AREPY10111 (example)

AAAABCDEEE (presumably) 
'''A''' - Identifier (last 4 digits of product code) 
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec) 
'''C''' - Production Year (2010 + C) 
'''D''' - Revision 
'''E''' - Production Run? (000-999)

Serials

2017-11-25T05:47:49Z

EvilFlight: /* Back of Card Serial */

This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).

== Console Serial Numbers ==

A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.

The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)

After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.

Example: CW404567772

The non-check digits are 40456777. Separating into odd and even groups, we get the following:

Odds: 4 + 4 + 6 + 7 = 21
Evens: 0 + 5 + 7 + 7 = 19

Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.

The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.

The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.

{| class="wikitable"
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)
|-
| ''DSi'' || T || V
|-
| ''DSi XL/LL'' || W || ''unknown''
|-
| ''Wii U'' || F || ''unknown''
|-
| 3DS || C || E
|-
| 3DS XL/LL || S || R
|-
| 2DS || A || P
|-
| New 3DS || Y || Y
|-
| New 3DS XL/LL || Q || Q
|-
| New 2DS XL/LL || N || N
|}

Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.

Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).

{| class="wikitable"
! Sales Region !! Region Lock !! Region Suffix
|-
| Japan || Japan || JF, JH, JM
|-
| North America || North America || W
|-
| Middle East / Southeast Asia || North America || S
|-
| Europe || Europe || EF, EH, EM
|-
| Australia || Europe || AH, AG
|-
| South Korea || Korea || KF, KH, KM
|-
| China (iQue) || China || CF, CH, CM
|}

== Console Models ==

{| class="wikitable"
! Device !! Product Code
|-
| ''DS'' || NTR
|-
| ''DS lite'' || USG
|-
| ''DSi'' || TWL
|-
| ''DSi XL/LL'' || UTL
|-
| ''Wii U'' || WUP
|-
| 3DS || CTR
|-
| 3DS XL/LL || SPR
|-
| 2DS || FTR
|-
| [[New 3DS]] || KTR
|-
| [[New 3DS]] XL/LL || RED
|-
| New 2DS XL/LL || JAN
|}

The DS had the product code NTR (short for Nitro), so we see the TR is recurring.

== Title ID and Unique ID ==
''see [[Titles]]''

== NCCH Product Code ==

This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.

The product code is located in a [[NCCH]]'s header (not its ExHeader).

The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".

So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".

A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:

[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]

{| class="wikitable"
! Category letter !! Description
|-
| P || Cartridge software, or downloadable versions of them.
|-
| N || Digital-only releases, including [[Title list|system applications and applets]].
|-
| M || [[DLC]]
|-
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.
|-
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.
|}

The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].

See the next chapter for explanation of the other components of the Product Code.

== Physical Serial ==

[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]

{| class="wikitable"
! Field !! Length !! Description !! colspan=2 | Values
|-
|-align=center
| rowspan="6" | Product
| rowspan="6" | 2
| rowspan="6" | Product type
|-
| LN || Cartridge
|-
| MA || Instruction manual
|-
| TS || Game box
|-
| FA || Leaflet
|-
| MK || Quick-start Guide
|-align=center
| rowspan="3" | Retail/Demo
| rowspan="3" | 1
| rowspan="3" |
|-
| A || Retail
|-
| Z || Demo
|-align=center
| rowspan="3" | CTR/KTR
| rowspan="3" | 3
| rowspan="3" | Platform
|-
| CTR || 3DS
|-
| KTR || New 3DS
|-align=center
| rowspan="11" | Type
| rowspan="11" | 1
| rowspan="11" |
|-
| A || Retail
|-
| B ||
|-
| C || part of the default serial 'CTAP'
|-
| E ||
|-
| H || used for built in applications like [[Mii Maker]]
|-
| J || normal eShop Title
|-
| K || unknown, seen in Mighty Gunvolt
|-
| S || usually a 3D Classics eShop title
|-
| P || used with GBA eShop titles
|-
| T || used with NES eShop titles
|-align=center
| Identifier
| 2
| colspan=3 |Game name (two alphanumeric characters)
|-align=center
| rowspan="10" | Region
| rowspan="10" | 1
| rowspan="10" |
|-
| E || English (US)
|-
| P || PAL (Europe/Australia)
|-
| J || Japanese (Japan)
|-
| K || Korean (Korea)
|-
| C || Chinese (China/Taiwan)
|-
| Y || Multiple regions
|-
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)
|-
| Z || Multiple regions
|-
| A || All (region-free)
|-
|-align=center
| rowspan="9" | Label Region
| rowspan="9" | 3
| rowspan="9" |
|-
| USA || USA
|-
| EUR || Europe
|-
| CAN || Canada
|-
| JPN || Japan
|-
| KOR || Korea
|-
| TWN || Taiwan/Hong Kong
|-
| CHN || China
|-
| UKV || United Kingdom version(?) (United Kingdom)
|}

=== Electronic Manuals ===

Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:

CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]

CTR-[Type][Identifier][Region]-[Region]-[Digit]

* P/N/T/U - Same as in product code structure
* [Type][Identifier][Region] - Same as in serial structure
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.

'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.

==Back of Card Serial==
AREPY10111 (example)

AAAABCDEEE (presumably) 
'''A''' - Identifier 
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec) 
'''C''' - Production Year (2010 + C) 
'''D''' - Revision 
'''E''' - Production Run? (000-999)

Mysteries

2017-10-18T21:24:06Z

EvilFlight: /* Is there more than one revision of the bootrom? */

The following is a list of mysteries.

== General ==
* What is the CTR abbreviation?
: C may stand for Chiheisen ("horizon" in Japanese, the O3DS's codename being "Project Horizon").
:: Not true, Horizon refers to the OS.

== Hardware ==
=== Why are there two CTRCARD controllers? ===
'''Background:''' Also [http://problemkaputt.de/twl-core.jpg DSi SoC pinout] shows evidence of dual NTRCARD controllers on the final DSi SoC. (This was a [http://i.imgur.com/0kJlbEw.png planned feature] of the DSi before being axed later in development)

=== Why are there two EMMC controllers? ===
'''Theory:''' At some point during 3DS hardware development there was an idea to split up CTR and TWL nand into two different chips.
=== Is there a JTAG? ===
=== Is there more than one revision of the bootrom? ===
'''Background:''' Bootrom visible portion has been dumped on the entire 3DS Family (3DS, 3DSXL, 2DS, New3DS, New3DSXL, New2DSXL), and even a prototype board from April(?) 2010. All matching exactly.

=== What is the EMMC controller @ 0x10100000 doing? ===
'''Background:''' There's dead code in NWM referencing it.
=== Why did they put NTRCARD accessible from ARM11? ===
'''Theory:''' At some point during 3DS hardware development there was a concept where ARM11 ran a menu with DS(i) icons while ARM9 was in TWL mode.

=== Is there a secret message embedded in the 3DS keyscrambler constant? ===
'''Background:''' TWL key scrambler constant was "Nintendo Co., Ltd" in Japanese ("任天堂株式会社"), UTF-16LE encoded, with byte order mark. The 3DS key scrambler constant, by comparison, is random-looking.

=== What is the PDN abbreviation? ===
: Power distribution network

=== How does Nintendo reflash bricked systems? ===
'''Theory:''' Before trying to boot from NAND, the bootrom checks to see if a key combination (Start + Select + X) is being held, and whether the shell is closed. If so, it tries to boot from an inserted NTR (Nintendo DS) cartridge.
This allows to execute a FIRM that is probably used by Nintendo to reflash the system.

== Software ==
=== What was the problem in "initial program loader" that was mentioned in an FCC filing by Nintendo for 2DS? ===
'''Background:''' http://www.neogaf.com/forum/showthread.php?t=814624&page=1
=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
=== What is the PTM abbreviation? ===
: Power/time management

=== Why is the DTCM not used anywhere except bootrom? ===
'''Background:''' Bootrom is known to use part of DTCM as state, memsetting it to 0 when it's done. After that, it is never used again.
=== How is CTRAging launched during factory setup? ===
'''Background:''' No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.

'''Theory:''' NtrBoot another time
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===

11.4.0-37

2017-06-15T17:03:52Z

EvilFlight: New 2DS XL Version

The Old3DS+New3DS 11.4.0-37 system update was released on April 10, 2017. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN.

Security flaws fixed: yes.

==Change-log==
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience

==System Titles==
===NATIVE_FIRM===
====Process9====
Exactly two functions were changed.

The global boolean preventing [[FIRM|SAFE_FIRM]] from being launched is now set in Process9's main() if [[CONFIG9_Registers#CFG9_BOOTENV|CFG9_BOOTENV]] has bit0 set, that is to say, if it has been launched from a firmlaunch (this register is set to 1 just before a firmlaunch). The following code has also been added in the firmlaunch function itself, immediately after the code-block where the boolean is checked: <code>if(!(CFG9_BOOTENV & 1) /* not a firmlaunch */ || (CFG9_BOOTENV & 6) /* firmlaunched from LGY_FIRM (if even possible at all) */) goto panic</code>.

This is to properly fix [[3DS_System_Flaws#Process9|safehax]].

====New3DS kernel9loader====
New3DS kernel9loader wasn't updated.

====ARM11 kernel====
There's exactly three code changes:

* [[CONFIG11_Registers#CFG11_WIFIUNK|CFG11_WIFIUNK]] is now set to 0x10 in Kernel11's crt0
* A new SVC, [[SVC|svc 0x5A]] has been introduced, to enable or disable wifi
* The code handling [[SVC|svcArbitrateAddress]] with type = SIGNAL, has been changed. It now counts the actual number of threads arbitrating on that address, and if it is non-zero, it executes the following hack: <code>if(coreId == 0 && currentThread->dynamicPriority >= 50) waitCycles(0x64E)</code>. This supposedly works around the lag issue in some games, which has been introduced on [[11.3.0-36]]

===Modules===
No FIRM ARM11 sysmodule was changed.

===[[NWM_Services|NWM-sysmodule]]===
The [[CONFIG11_Registers]] are no longer directly mapped under userland for NWM-sysmodule.
This prevents anything under NWM-module from modifying the GPUPROT register. This was used by both *hax payload(prior to v11.4 release) and [https://github.com/smealum/udsploit udsploit].

The codebin was updated.

The crt0-poke in PDN that NWM previously did:
0x1EC4010C |= 0x10

.. has been removed from NWM. This one has been moved into kernel bootup.

All accesses to 0x1EC40180 have been replaced by a new syscall, [[SVC|0x5A]].

This now includes code from old CTRSDK update(s). A new func was added for calling a func, previously that func was directly called via vtable funcptr. The only other changes was new heap code(and the code for using it basically), for fixing the NWMUDS sharedmem [[3DS_System_Flaws|vuln]]. This includes code which actually validates heap memchunkhdrs, with svcBreak being executed on failure.

A new string was added at 0x13E200: "used"(with 3 0xFF bytes afterwards), this is used by the new heap code. The wifi-fw was moved from .data to .rodata.

===[[HTTP_Services|HTTP-sysmodule]]===
There were exactly 3 changes in the HTTP-sysmodule codebin.

Two functions, the memalloc and memfree functions used with HTTP sharedmem, were updated to use the new function. The new function is for heap memchunkhdr validation. This additional code is the same new heap code as NWM-sysmodule. This fixed the vuln used by ctr-httpwn at the time of sysupdate release.

===[[Friend_Services|Friends-sysmodule]]===
Like past updates the only change in this codebin was the fpdver(0x9->0xA).

===[[NS_and_APT_Services|NS-sysmodule]]===
The only changes for NS was version values in the codebin, nothing else.

===[[Internet Browser]]===
The web-browser was updated, only for New3DS. See [[Internet Browser|here]] for details.

===[[Nintendo_3DS_Sound]]===
soundhax was fixed, it appears other vulns were fixed too.

Exactly 8 functions were changed in the codebin.

L_1d3ba8
updated, prev ver @ L_1d3ba8.
Added only the following code:
if(len<2)return;
if(len>=0xfe)len=0xfe;
*lenstorage = len;

L_1d3d10
updated, prev ver @ L_1d3cfc.
When L_1ea0b8 returns non-zero, this now clears the 4-bytes at inr1.

L_1f32c4
updated, prev ver @ L_1f329c.
This now writes u32 val0 to inr0+0x34 immediately after the nop instruction.

L_275754
updated, prev ver @ L_27572c.
This now executes the following each time L_1ea0b8 returns non-zero: sp20 = 0;

L_275ed4
updated, prev ver @ L_275e94.
Added the following code after the branch for "if(*(inr1+8)==0)":
if(len>0xfe){len=0xfe;<jump over the code which checks len0>}
Identical changes were added at 0x276054, except with len val 0x82.
Likewise at 0x276138 except with len val 0x76.

L_280000
updated, prev ver @ L_27ff90.
This was added at 0x280444: if(len>0xfe)len=0xfe;
Minor(?) other changes.

L_280c74
updated, prev ver @ L_280b60.
This now writes u32 val0 to inr0+0x34 immediately after the nop instruction.

L_281ab0
updated, prev ver @ L_281998.
Added the following: if(len>=0xfe)len=0xfe;
This was added at 0x281b94:
if(somelen>=0xfe)
{
len=0xfe;
}
else
{
len=somelen;
}
*r4 = val;
Then len is used for a string data-copy(ASCII/UTF16), unless it's UTF16 and len is <=0.

===[[Title_list|SNOTE_AP]]===
This was updated with vuln fixes similar to the sound-app.

LT_1004d6
updated, prev ver @ LT_1004d6.
Added a func call for LT_1017c8 at 0x100508.

LT_1017c8
new func.
Only called by LT_1004d6.
return LT_10250c(0x405, 5, 0x5109d503);

LT_103368
updated, prev ver @ LT_1032f8.
The first func call was removed, it's now located in LT_1017c8.

LT_11ea6c
updated, prev ver @ LT_11ea60.
Added the following: if(len>0xfe)*lenptr = 0xfe;

LT_11f210
updated, prev ver @ LT_11f1fc.
The following was added at 0x11f49c: if(len>0xfe)len=0xfe;
Before executing "return ~0x63;" this now calls LT_12f542.
minor other changes.

LT_11f84c
updated, prev ver @ LT_11f828.
This now clears inr0+0x34 after calling L_14cabc.

LT_11f9ac
updated, prev ver @ LT_11f984.
Added the following: if(len>0xfe)*lenptr=0xfe;
==New 2DS XL Version==
On June 15, 2017 a new version of 11.4.0-37E was released pre-installed with the AU/NZ debut of the New 2DS XL model of the 3ds family. There are 13 updated titles over the base NUS version included this new model, apparently to ensure compatibility with the New 2DS XL's unique 3D-less hardware configuration. A list of changed titles can be found [https://gist.github.com/ihaveamac/bffc8694ac209207c8db86a98f6c4238 here].
==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=04-10-17_08-00-38&sys=ctr]
* [https://yls8.mtheall.com/ninupdates/reports.php?date=04-10-17_08-00-47&sys=ktr]

FirmwareNews

2017-06-03T15:16:02Z

EvilFlight: typo

As of this writing, the latest firmware is '''[[11.4.0-37|11.4.0-37]]'''.

See [[Homebrew Exploits|here]] regarding running homebrew.

----

Full system control exploits are only known for system versions up to and including '''11.4.0-X''' and public for system versions up to and including '''11.3.0-X'''

Internet Browser

2016-08-17T10:32:07Z

EvilFlight: /* v9.9 dummy web-browser */

The 3DS Internet Browser was added in the June 2011 Update for JPN/EUR/USA.

From the Internet Browser help section:
In compliance with the LGPL, the source code of the OSS is available via the Nintendo website.
This source code can be downloaded here:
[http://mediacontent.nintendo-europe.com/NOE/images/service/OpenSources.zip] [http://www.nintendo.co.jp/support/oss/index.html]

The 3DS Internet Browser is [http://en.wikipedia.org/wiki/Netfront Netfront] Browser NX v1.0 based on [http://en.wikipedia.org/wiki/WebKit WebKit] engine.

On O3DS the exheader name of this title is "SPIDER"; on N3DS, "SKATER".
The only difference between the ExeFS .code for each region of the Old3DS/New3DS browser, is byte values for the title uniqueID/region.

A [[#v9.9_dummy_web-browser|"dummy" browser]] (which replaces the actual browser) is being included with cartdrige games shipping the [[9.9.0-26|9.9.0-X]] system update.
In addition, versions of the real browser since 9.9.0-26X attempt to [[#Forced_system-update|check-in with a Nintendo server]] to determine if the existing browser version is out of date.

==[[New 3DS]] Internet Browser==
New3DS has a separate browser title, with the exheader name "SKATER".
Unlike the Old3DS browser, the New3DS browser has videos+HTML5 support.

This browser also has a filter enabled by default in the JPN version.
Disabling it requires paying money with a credit-card, for [[NIM_Services|purchasing]] web-browser [[Title_list/DLC|DLC]].
During startup the browser does various HTTPS comms. When visting an URL, the browser sends a plaintext HTTP POST here: [http://ars.ifuser.jp:20080/ars2/rating]. The raw POST data begins with "ARS/2.0\r\n\x00", the rest appears to be encrypted. The server reply content also has this ARS header + encrypted data. This appears to use a fixed xorpad, likely from a fixed encryption CTR/IV. The server content responses for allowed sites, and blocked sites, are fixed. When the server returns that the site is blocked, the browser goes to this page: [http://ars.ifuser.jp/filter/44.html](the Referrer header value is set to the same URL it's actually requesting).

The WebKit source was updated since the Old3DS browser.
The New3DS browser uses the following services: [[MVD_Services|mvd:STD]] and [[IR_Services|ir:rst]](DLC-related services are used too but those aren't New3DS specific).
Video decoding is done with [[MVD_Services|mvd:STD]]. Audio decoding/playback is done with a browser-specific DSP binary. The Old3DS browser used CSND for audio playback, the New3DS browser doesn't have access to that at all since it uses DSP instead.

=== Video / libstagefright ===
The browser manual includes licenses for Android and PacketVideo. The browser uses libstagefright from Android. Just like WebKit, the browser appears to use a very old version of libstagefright with security/other changes back-ported(for example, the v10.7 browser libstagefright codebase seems to be older than [https://android.googlesource.com/platform/frameworks/av/+/ec77122351b4e78c1fe5b60a208f76baf8c67591%5E%21/media/libstagefright/MPEG4Extractor.cpp this]). This codebase is missing certain chunk-parsing code for 3GP.

HTTP for libstagefright is internally handled with [[HTTP_Services|HTTPC]], with a similar(?) set of RootCAs as for browser-version-check.

===User-Agent and Browser Versions===
Normal user-agent format: <code style="font-size:larger;">Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/<WebKit version> (KHTML, like Gecko) NX/<Netfront version> Mobile NintendoBrowser/<Mobile NintendoBrowser version>.<region></code>

<region> can be one of the following: "JP", "US", or "EU".

{| class="wikitable" border="1"
|-
! Mobile NintendoBrowser version(displayed in browser settings)
! Normal UA
! Mobile UA
! CDN Title-version
! Network-only system-update version
! Notes
|-
| 1.0.9934
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.8 Mobile NintendoBrowser/1.0.9934.<region>
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v10
| [[9.0.0-20]]
| Initial version.
|-
| 1.1.9996
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.10 Mobile NintendoBrowser/1.1.9996.<region>
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v1027
| [[9.3.0-21]]
| See below regarding OSS changes.
|-
| 1.2.10085
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.13 Mobile NintendoBrowser/1.2.10085.<region>
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v2051
| [[9.6.0-24]]
| See below.
|-
| None
| None
| None
| v3075
| v9.9 CUP
| v9.9 CUP dummy web-browser, see below.
|-
| 1.3.10126
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.15 Mobile NintendoBrowser/1.3.10126.US
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v3077
| [[9.9.0-26]]
| See below.
|-
| 1.4.10138
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.17 Mobile NintendoBrowser/1.4.10138.US
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v4096
| [[10.2.0-28]]
| See below.
|-
| 1.5.10143
|
|
| v5121
| [[10.4.0-29]]
| See below.
|-
| 1.6.10147
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.19 Mobile NintendoBrowser/1.6.10147.US
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v6144
| [[10.6.0-31]]
| See below.
|-
| 1.7.10150
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.19 Mobile NintendoBrowser/1.7.10150.US
|
| v7184
| [[10.7.0-32]]
| See below.
|}

Note that the latest Old3DS browser WebKit version at the time the initial New3DS browser was released, was the following: 532.8.

The first version of the KOR New3DS browser was v9.6(which was when the New3DS KOR titles were originally added). Each version of the KOR browser has the same NintendoBrowser version as the other regions. The KOR browser has been only updated when the browser for the other regions were updated, hence the title-versions are the same as well. The KOR browser ExeFS .code is different from the other regions(more than just region-related IDs etc).

==== OSS 9.0 and 9.3 diff ====
The following is a diff of the OSS archives from [http://www.nintendo.co.jp/support/oss/index.html here], for v9.0 and v9.3.

Files NewNintendo3DS_OpenSources9.0.0-/WKC/WebCore/platform/network/WKC/ResourceHandleManagerWKC.cpp and NewNintendo3DS_OpenSources9.3.0-/WKC/WebCore/platform/network/WKC/ResourceHandleManagerWKC.cpp differ
Files NewNintendo3DS_OpenSources9.0.0-/WKC/WebKit/WKC/webkit/WKCVersion.h and NewNintendo3DS_OpenSources9.3.0-/WKC/WebKit/WKC/webkit/WKCVersion.h differ

WKC_CUSTOMER_RELEASE_VERSION was changed from "0.5.8" to "0.5.10".

The following code was added to ResourceHandleManager::doRedirect(): curl_easy_setopt(d->m_handle, CURLOPT_SHARE, 0);

==== v9.6 ====
WebKit/OSS code was actually updated.
ExeFS .code was updated. The following files in RomFS were updated:
* "/banner/CN/Skater.icn" and "/banner/KR/Skater.icn".
* "/browser/rootca.pem"
* "/build/buildinfo.dat"
* "/cairo.cro.lex" and "/.crr/static.crr"
* "/lyt/Button/ButtonSelectHSearch.arc"
* "/lyt/Kbd/Swkbd.arc"
* "lyt/Kbd.arc"
* "skater.msbt" under all of the "/message/<region>_<language>/" directories.
* "/oss.cro.lex", "/peer.cro.lex", "/static.crs", and "/webkit.cro.lex".

The following was added to RomFS:
* "/favicon/naver.dat"
* A "KO" directory under "/iwnn".

==== v9.9 ====
ExeFS:/.code was updated.

The only RomFS changes is file-updating, all of the following files were updated:
/browser/rootca.pem
/build/buildinfo.dat
/cairo.cro.lex
/.crr/static.crr
/message/CN_Simp_Chinese/skater.msbt
/message/EU_Dutch/skater.msbt
/message/EU_English/skater.msbt
/message/EU_French/skater.msbt
/message/EU_German/skater.msbt
/message/EU_Italian/skater.msbt
/message/EU_Portuguese/skater.msbt
/message/EU_Russian/skater.msbt
/message/EU_Spanish/skater.msbt
/message/JP_Japanese/skater.msbt
/message/KR_Hangeul/skater.msbt
/message/TW_English/skater.msbt
/message/TW_Trad_Chinese/skater.msbt
/message/US_English/skater.msbt
/message/US_French/skater.msbt
/message/US_Portuguese/skater.msbt
/message/US_Spanish/skater.msbt
/oss.cro.lex
/peer.cro.lex
/static.crs
/webkit.cro.lex

See [https://gist.github.com/yellows8/9fb509fde4112339f342 here] for a diff of the OSS(WebKitLibraries/ is not included due to the massive cairo library diff). An exploitable security vuln(which was already known in the context of 3DS webkit) was fixed. [[User:Yellows8|Yellows8]]' private(at the time of writing) exploit for it is based on the PoC from [http://pastebin.com/ufBCQKda here](see the pastebin for the actual pastebin author).

==== v10.2 ====
The libstagefright build in the main SKATER codebin was updated to a version which fixed libstagefright vuln(s): the vuln used in [[browserhax|browserhax_fright]] at the time of sysupdate release was fixed. The *only* code changed in the main codebin, was code related to libstagefright.

The only RomFS changes is file-updating, all of the following files were updated(see the forced-sysupdate section regarding what changed in the message files):
/browser/rootca.pem
/build/buildinfo.dat
/.crr/static.crr
/message/CN_Simp_Chinese/skater.msbt
/message/EU_Dutch/skater.msbt
/message/EU_English/skater.msbt
/message/EU_French/skater.msbt
/message/EU_German/skater.msbt
/message/EU_Italian/skater.msbt
/message/EU_Portuguese/skater.msbt
/message/EU_Russian/skater.msbt
/message/EU_Spanish/skater.msbt
/message/JP_Japanese/skater.msbt
/message/KR_Hangeul/skater.msbt
/message/TW_English/skater.msbt
/message/TW_Trad_Chinese/skater.msbt
/message/US_English/skater.msbt
/message/US_French/skater.msbt
/message/US_Portuguese/skater.msbt
/message/US_Spanish/skater.msbt
/oss.cro.lex
/static.crs
/webkit.cro.lex

OSS diff:
diff --git a/NewNintendo3DS_OpenSources9.9.0-/WKC/WebKit/WKC/webkit/WKCVersion.h b/NewNintendo3DS_OpenSources10.2.0-/WKC/WebKit/WKC/webkit/WKCVersion.h
index 4543297..0860336 100644
--- a/NewNintendo3DS_OpenSources9.9.0-/WKC/WebKit/WKC/webkit/WKCVersion.h
+++ b/NewNintendo3DS_OpenSources10.2.0-/WKC/WebKit/WKC/webkit/WKCVersion.h
@@ -29,7 +29,7 @@
#define WKC_VERSION_CHECK(major, minor, micro) \
(((major)*10000) + ((minor)*100) + (micro)) >= ((WKC_VERSION_MAJOR*10000) + (WKC_VERSION_MINOR*100) + (WKC_VERSION_MICRO))

-#define WKC_CUSTOMER_RELEASE_VERSION "0.5.15"
+#define WKC_CUSTOMER_RELEASE_VERSION "0.5.17"

#define WKC_WEBKIT_VERSION "536.30"

diff --git a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/ChangeLog b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/ChangeLog
index a5abb35..cf5a9fa 100644
--- a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/ChangeLog
+++ b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/ChangeLog
@@ -1,3 +1,12 @@
+2013-11-05 Ryosuke Niwa <rniwa@webkit.org>
+
+ Use-after-free in SliderThumbElement::dragFrom
+ https://bugs.webkit.org/show_bug.cgi?id=123873
+
+ Reviewed by Andreas Kling.
+
+ Merge https://chromium.googlesource.com/chromium/blink/+/04a23bfca2d04101a1828d36ff36c29f3a24f34b
+
2015-02-06 Maciej Stachowiak <mjs@apple.com>

REGRESSION(r179706): Caused memory corruption on some tests (Requested by _ap_ on #webkit).
@@ -879,7 +888,7 @@
* rendering/RenderLineBoxList.cpp:
(WebCore::RenderLineBoxList::dirtyLinesFromChangedChild):

-2014-01-21 LÃ¡szlÃ³ LangÃ³ <llango.u-szeged@partner.samsung.com>
+2014-01-21 Laszlo Lango <llango.u-szeged@partner.samsung.com>

Assertion failure in Range::nodeWillBeRemoved
https://bugs.webkit.org/show_bug.cgi?id=121694
@@ -1879,7 +1888,7 @@

2012-09-14 Simon Fraser <simon.fraser@apple.com>

- REGRESSION: transition doesnât always override transition-property
+ REGRESSION: transition doesnft always override transition-property
https://bugs.webkit.org/show_bug.cgi?id=96658

Reviewed by Dean Jackson.
@@ -3691,8 +3700,8 @@
glyph with font data for the primary font, presumably to meet the SVG
spec requirement: "If the references to alternate glyphs do not result
in successful identification of alternate glyphs to use, then the
- character(s) that are inside of the çª¶åltGlyphçª¶?element are rendered as
- if the çª¶åltGlyphçª¶?element were a çª¶?spançª¶?element instead."
+ character(s) that are inside of the âaltGlyphâ?element are rendered as
+ if the âaltGlyphâ?element were a â?spanâ?element instead."

If the alt glyph is not then found we are in the case from the spec
and indeed we should use the primary font. However, we end up replacing the GlyphPage
diff --git a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/html/RangeInputType.cpp b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/html/RangeInputType.cpp
index 484adec..d7e9e8d 100644
--- a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/html/RangeInputType.cpp
+++ b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/html/RangeInputType.cpp
@@ -164,7 +164,7 @@ void RangeInputType::handleMouseDownEvent(MouseEvent* event)
ASSERT(element()->hasShadowRoot());
if (targetNode != element() && !targetNode->isDescendantOf(element()->shadowTree()->oldestShadowRoot()))
return;
- SliderThumbElement* thumb = sliderThumbElementOf(element());
+ RefPtr<SliderThumbElement> thumb = sliderThumbElementOf(element());
if (targetNode == thumb)
return;
thumb->dragFrom(event->absoluteLocation());

==== v10.4 ====
The ExeFS codebin was updated, the only change was that the following code was updated in the actual NupCheck HTTPS request function:
* Previous version: sprintf(out, "https://cbvc.cdn.nintendo.net/SNAKE/2/%s", region);
* Current version: sprintf(out, "https://cbvc.cdn.nintendo.net/SNAKE/%d/%s", 3, region);

libpng was updated from version 1.5.21 to 1.5.24.

The following RomFS files were updated(see the forced-sysupdate section regarding what changed in the message files):
/browser/rootca.pem
/build/buildinfo.dat
/cairo.cro.lex
/.crr/static.crr
/message/CN_Simp_Chinese/skater.msbt
/message/EU_Dutch/skater.msbt
/message/EU_English/skater.msbt
/message/EU_French/skater.msbt
/message/EU_German/skater.msbt
/message/EU_Italian/skater.msbt
/message/EU_Portuguese/skater.msbt
/message/EU_Russian/skater.msbt
/message/EU_Spanish/skater.msbt
/message/JP_Japanese/skater.msbt
/message/KR_Hangeul/skater.msbt
/message/TW_English/skater.msbt
/message/TW_Trad_Chinese/skater.msbt
/message/US_English/skater.msbt
/message/US_French/skater.msbt
/message/US_Portuguese/skater.msbt
/message/US_Spanish/skater.msbt
/oss.cro.lex differ
/peer.cro.lex differ
/static.crs differ
/webkit.cro.lex differ

==== v10.6 ====
The ExeFS codebin was updated.

[[browserhax|browserhax_fright_tx3g]] was fixed. The code handling tx3g now matches the latest libstagefright git.

Hence the below RomFS listing, no OSS was updated at all(besides libstagefright mentioned above).

The following RomFS files were updated:
/build/buildinfo.dat
/static.crs

==== v10.7 ====
Basically the same changes as Old3DS v10.7, except with the usual buildinfo.dat update in RomFS. The below date is 6 days after the browser-version-check [[3DS_Userland_Flaws|bypass]] was publicly disclosed.

cat v7184/00000025_romfs/build/buildinfo.dat
10150
applet
2016-03-02 18:25

=== New3DS Browser Specifications ===
[http://www.nintendo.co.jp/3ds/new/features/modal_net.html]

English version:
* "Browser engine: NetFront® Browser NX v3.0"
* "User agent: Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML and like Gecko) NX/3.0.*.*.* Mobile NintendoBrowser/1.0.**** JP
* ** Version information is stated.
* *** When using the “Mobile version request” function, it differs from the above-mentioned character string"
* "Supported protocols: HTTP1.0/HTTP1.1/SSL3.0/TLS1.0/TLS1.1/TLS1.2"
* "Web standard: HTML4.01 / HTML5 / XHTML1.1 / Fullscreen API / Gamepad API / SVG / WebSocket / Video Subtitle / WOFF / Web Messaging / Server-Sent / Web Storage (partial) / XMLHttpRequest / Canvas element / Video / DOM Levels 1-3 / ECMAScript / CSS1 / CSS2.1 / CSS3 (partial)"
* "Image format: bmp / gif / ico / jpeg / png / svg (There are, however, possibilities that some images won't display.)"
* "Image preview: mpo / jpeg (There are, however, possibilities that some images won't display.)"
* "Video format: MP4, M3U8 + TS (HTTPLiveStreaming) (There are, however, some videos that may not be played.)"
* "Video codec: H.264 - MPEG-4 AVC Video (max 854x480 at level 3.2, 3D compatible) (There are, however, some videos that can not be played.)"
* "Audio codec: AAC - ISO / IEC 14496-3 MPEG-4AAC, MP3 (There are, however, some videos that can not be played.)"
* "Format for uploading 3D videos: .mkv (In order to be played, videos must be converted to the appropriate format within the site you are uploading to. In some cases, the video will not play even if converted.)"
* "Plug-ins: Plug-ins such as Adobe Flash are not supported"
* "Active Rating System filtering: provided by Digital Arts, Inc.. Access to web content can be limited based on its category information, restricting access to web content that may result inappropriate."
* "Websites can be requested to provide the mobile version (However, if the web page does not have a mobile version, it won't change the way it's displayed.)"

MJPEG + .avi is also supported.

==== Notes ====
* The html "color" <input> type is not supported.

== Old3DS browser ==

=== Old3DS Browser Specifications ===
* "Browser engine: NetFront® Browser"
* "User agent: Mozilla/5.0 (Nintendo 3DS; region; ; en) Version/1.7498.US"
* "Supported protocols: HTTP1.0/HTTP1.1/SSLv3/TLS1.0"
* "Web standard: HTML 4.01/XHTML 1.1/CSS 1/CSS 2.1/CSS 3 (partial functionality)/DOM Levels 1-3/ECMAScript
/XMLHttpRequest/Canvas Element (partial functionality)"
* "Image format: MPO / GIF / JPEG / PNG / BMP / ICO (some images cannot be displayed)"
* "Plug-ins: Plug-ins such as Adobe Flash are not supported"

Old3DS browser doesn't support events "focusin" and "focusout"

=== User-Agent and Browser Versions ===
User-agent format: <code style="font-size:larger;">Mozilla/5.0 (Nintendo 3DS; U; ; <lang>) Version/<version>.<region></code>.

<lang> is "en", "fr", etc. <region> is "US", "EU", etc. See below for <version>.
{| class="wikitable" border="1"
|-
! Browser version
! CDN Title-version
! Network-only system-update version
! Notes
|-
| 1.7412
| v6
| [[2.0.0-2|2.0.0-2]]
| This was the initial version.
|-
| 1.7455
| v1024
| [[2.1.0-4]]
| ExeFS .code was updated, both of the CROs(webkit/OSS) were updated too.
|-
| 1.7498
| v2050
| [[4.0.0-7]]
| ExeFS .code was updated, both of the CROs(webkit/OSS) were updated too. The manual CFA was updated as well.
|-
| 1.7538
| v0
| [[4.2.0-9]]
| First version of the KOR browser. The CROs are different from the USA/EUR/JPN [[4.0.0-7]] browser.
|-
| 1.7552
| v3075
| [[5.0.0-11]]
| ExeFS .code and icon were updated, both of the CROs(webkit/OSS) were updated too. The manual CFA was updated as well.
|-
| 1.7552
| v3088
| [[7.0.0-13]]
| The main NCCH wasn't updated at all(same TMD contentID/content-hash as the previous version), only the manual CFA for this title was updated.
|-
| 1.7567
| v4096
| [[7.1.0-16]]
| The CXI .code was updated, some data in the RomFS was updated(none of the CROs such as webkit.cro were updated). The manual CFA was updated too.
|-
| 1.7585
| v5121
| [[9.5.0-23]]
| The CXI .code was updated, and the manual CFA was updated. RomFS changes:
* "/browser/rootca.pem" updated
* "/cro/oss.cro" updated
* "/cro/static.crs" updated
* "/cro/webkit.cro" updated
* "/.crr/static.crr" updated
* "/layout/dialogheader/WirelessSwitchOff.arc" was removed
* "/layout/favorite/favicondata/KOR.arc" updated

A vuln used in a public(at the time of this sysupdate) webkit exploit for spider was fixed, which also fixed the removewinframe exploit from [https://github.com/yellows8/3ds_webkithax here].
|-
| None
| v6147
| v9.9 CUP
| v9.9 CUP dummy web-browser, see below.
|-
| 1.7610
| v6149
| [[9.9.0-26]]
| See below.
|-
| 1.7616
| v7168
| [[10.2.0-28]]
| See below.
|-
| 1.7622
| v8192
| [[10.6.0-31]]
| See below.
|-
| 1.7625
| v9232
| [[10.7.0-32]]
| See below.
|}

=== Heap ===
The USA/EUR/JPN + KOR browser allocates the 0x08000000 heap with size 0x01A97000. The size used by the CHN and TWN browser is 0x01997000, exactly 0x100000-bytes smaller.

=== Old3DS v9.9 ===
ExeFS:/.code was updated.

The only changes in RomFS were file-updating, the following files were updated:
/browser/rootca.pem
/cro/oss.cro
/cro/static.crs
/cro/webkit.cro
/.crr/static.crr
/message/CN_Simp_Chinese/spider.msbt
/message/EU_Dutch/spider.msbt
/message/EU_English/spider.msbt
/message/EU_French/spider.msbt
/message/EU_German/spider.msbt
/message/EU_Italian/spider.msbt
/message/EU_Portuguese/spider.msbt
/message/EU_Russian/spider.msbt
/message/EU_Spanish/spider.msbt
/message/JP_Japanese/spider.msbt
/message/KR_Hangeul/spider.msbt
/message/TW_English/spider.msbt
/message/TW_Trad_Chinese/spider.msbt
/message/US_English/spider.msbt
/message/US_French/spider.msbt
/message/US_Portuguese/spider.msbt
/message/US_Spanish/spider.msbt

OSS diff for v9.5 and v9.9, without the .dox changes:

diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/WKC/WebKit/WKC/webkit/WKCVersion.h b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h
index be5ff09..55a7274 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/WKC/WebKit/WKC/webkit/WKCVersion.h
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h
@@ -29,7 +29,7 @@
#define WKC_VERSION_CHECK(major, minor, micro) \
(((major)*10000) + ((minor)*100) + (micro)) >= ((WKC_VERSION_MAJOR*10000) + (WKC_VERSION_MINOR*100) + (WKC_VERSION_MICRO))

-#define WKC_CUSTOMER_RELEASE_VERSION "1.8.14"
+#define WKC_CUSTOMER_RELEASE_VERSION "1.8.16"

#define WKC_WEBKIT_VERSION "532.7"

diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/webkit/WebCore/rendering/RenderBox.cpp b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderBox.cpp
index da4127e..d03403e 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/webkit/WebCore/rendering/RenderBox.cpp
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderBox.cpp
@@ -305,23 +305,23 @@ int RenderBox::scrollHeight() const

int RenderBox::scrollLeft() const
{
- return hasOverflowClip() ? layer()->scrollXOffset() : 0;
+ return layer() && hasOverflowClip() ? layer()->scrollXOffset() : 0;
}

int RenderBox::scrollTop() const
{
- return hasOverflowClip() ? layer()->scrollYOffset() : 0;
+ return layer() && hasOverflowClip() ? layer()->scrollYOffset() : 0;
}

void RenderBox::setScrollLeft(int newLeft)
{
- if (hasOverflowClip())
+ if (hasOverflowClip() && layer())
layer()->scrollToXOffset(newLeft);
}

void RenderBox::setScrollTop(int newTop)
{
- if (hasOverflowClip())
+ if (hasOverflowClip() && layer())
layer()->scrollToYOffset(newTop);
}

=== Old3DS v10.2 ===
The slider vuln from [https://github.com/yellows8/3ds_webkithax here] was fixed in the Old3DS browser.

The main codebin .text only increased by 0x10-bytes.

The only changes in RomFS was that the following files were updated:
/cro/oss.cro
/cro/static.crs
/cro/webkit.cro
/.crr/static.crr

OSS diff:
diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/WKC/WebKit/WKC/webkit/WKCVersion.h
index 55a7274..fc153c4 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/WKC/WebKit/WKC/webkit/WKCVersion.h
@@ -29,7 +29,7 @@
#define WKC_VERSION_CHECK(major, minor, micro) \
(((major)*10000) + ((minor)*100) + (micro)) >= ((WKC_VERSION_MAJOR*10000) + (WKC_VERSION_MINOR*100) + (WKC_VERSION_MICRO))

-#define WKC_CUSTOMER_RELEASE_VERSION "1.8.16"
+#define WKC_CUSTOMER_RELEASE_VERSION "1.8.17"

#define WKC_WEBKIT_VERSION "532.7"

diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderSlider.cpp b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/webkit/WebCore/rendering/RenderSlider.cpp
index b2f5cef..1dd3dbd 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderSlider.cpp
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/webkit/WebCore/rendering/RenderSlider.cpp
@@ -221,6 +221,7 @@ RenderSlider::~RenderSlider()
{
if (m_thumb)
m_thumb->detach();
+ m_thumb = 0;
}

int RenderSlider::baselinePosition(bool, bool) const
@@ -493,7 +494,8 @@ void RenderSlider::forwardEvent(Event* event)
}
}

- m_thumb->defaultEventHandler(event);
+ if (m_thumb)
+ m_thumb->defaultEventHandler(event);
}

bool RenderSlider::inDragMode() const

=== Old3DS v10.6 ===
[[browserhax|spider28hax]] was fixed. The "2^32 characters long string" vuln described [[3DS_Userland_Flaws|here]] was ''finally'' fixed.

''A lot'' of WebKit issues/vulns were fixed, see [https://gist.github.com/yellows8/b1e10caa1d8bb8a46316 here] for the changes.

libpng was updated from version 1.4.12 to 1.4.19. zlib was updated from 1.2.7 to 1.2.8.

The .text size increased by 0x478-bytes.

The only changes in RomFS was that the following files were updated:
/cro/oss.cro
/cro/static.crs
/cro/webkit.cro
/.crr/static.crr
/manual/Manual.bcma

=== Old3DS v10.7 ===
''Nothing'' changed except some words for version-values in .text being updated(RomFS wasn't changed), code for browser-version-check was [[#v10.7_2|updated]].

== Forced system-update ==
The Old3DS/New3DS Internet Browser updated with [[9.9.0-26]] added the following message strings:
In order to use the Internet
browser, a system update
is required.
To perform a system update,
select System Update from Other
Settings in System Settings.

The Internet browser cannot be
used at this time.
Please check your network
environment or try again later.

For whatever reason, the above ''message strings'' were removed with New3DS-browser v10.2, then re-added with v10.4. This does not apply to the Old3DS browser. Whenever v10.2 New3DS browser tries to use these message-strings for displaying a browser-update-related message, it will crash due to an assert failing since the message-strings are missing. Hence, if/when the v10.2 update-check page is ever updated where the browser tries to display a message for it, or when accessing that page fails, the browser will automatically crash.

This wasn't enforced(web-browser displaying the above message when the installed browser isn't the latest version) until October 26, 2015.

This message only triggers when attempting to load a web-page. This is only handled the first time the browser accesses a web-page, during this browser session.

The browser codebins starting with v9.9 now contain the following URL strings:
* Old3DS: <nowiki>"https://cbvc.cdn.nintendo.net/CTR/1/<region>"</nowiki>
* New3DS: <nowiki>"https://cbvc.cdn.nintendo.net/SNAKE/1/<region>"</nowiki>

The <region> string is one of the following:
* "JPN"
* "USA"
* "EUR"
* "KOR"

Starting with the browser from [[10.2.0-28]], the "1" in the above URLs were changed to "2". With the New3DS browser from [[10.4.0-29]], it's now "3".

As of October 26, 2015, the "1" URLs return the browser-version for v9.9(decimal number as a string without any "."), while the "2" URLs returns 0.

if(internal_browserver > server_browserver)
{
<safe>
}
else
{
<update message>
}

Hence, internal_browserver == server_browserver will trigger the sysupdate message, which appears to be the normal way to indicate that the current browser is outdated(see above).

There is a cache for this in savedata. The request is only done when at least 24-hours have passed since the last time the request was done(see the below savedata section).

It is still possible to guard against this update by blocking the previous URLs using a proxy.
It is not possible to remove the update message by entering the [[Recovery Mode]].

=== Page request ===
For this request, all root-CAs bundled with the browser are trusted, in addition to two of the SSL module builtin Nintendo root-CAs.

The browser(with New3DS at least) does the following with [[HTTP_Services|HTTPC]] for requesting the above page:
* Initializes the HTTP context and uses [[HTTPC:InitializeConnectionSession]] + [[HTTPC:SetProxyDefault]].
* Uses [[HTTP_Services|HTTPC]] command 0x250080 twice with cmd[1]=contexthandle: first time cmd[2]=0x3, second time cmd[2]=0x6.
* Then [[HTTPC:AddTrustedRootCA]] is used 48 times to setup 48 trusted root CAs. This appears to be every cert in the browser "romfs:/browser/rootca.pem" file converted to DER, in the same order from there(in other words, every single root CA the browser trusts by default for normal web-browsing).
* Then [[HTTPC:BeginRequest]] is used.
* Then [[HTTPC:ReceiveDataTimeout]] is used, the recv-size seems to be fixed to 0x20.
* Then [[HTTPC:GetResponseStatusCodeTimeout]] is used.
* Then [[HTTPC:GetDownloadSizeState]] is used.
* Then the HTTP context is closed.

Raw request data(New3DS USA v10.2 browser):
000000: 47 45 54 20 2f 53 4e 41 4b 45 2f 32 2f 55 53 41 GET /SNAKE/2/USA
000010: 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a HTTP/1.1..Host:
000020: 20 63 62 76 63 2e 63 64 6e 2e 6e 69 6e 74 65 6e cbvc.cdn.ninten
000030: 64 6f 2e 6e 65 74 0d 0a 0d 0a do.net....

=== v10.7 ===
The only actual code change with Old3DS/New3DS browser v10.7 was that the code which calculates the diff_timestamp was moved to immediately after the block which initializes <state_timestamp> when <state_timestamp> is all-zero. This fixed the browser-version-check [[3DS_Userland_Flaws|bypass]].

== v9.9+ dummy web-browser ==
Gamecards v9.9 and above include, with their sysupdate, a dummy Old3DS/New3DS web-browser. The *only* thing this title does is display the same message listed in the above forced-update section. The message files in RomFS *only* contain that message string above. There are no "http" strings in the main codebin, and [[RO_Services|RO]] isn't used either(no CRO data in RomFS at all). Both browsers are internally called "dummySpider".

Hence, if you update your system with any v9.9 or above gamecard, the system web-browser will be rendered *completely* useless until you install a system-update from CDN(no network requests involved here).

== Savedata ==
=== New3DS ===
On newer SKATER versions, it appears *all* NAND savedata is stored under the [[System_SaveData|0x000200BB]] savedata.

==== 0x000200BB savedata ====
This only contains "t.bin" with filesize 0xadf80, the format is below.

The timestamp format used here is the number of milliseconds since January 1, 2000(local-time).

When using the "Initialize savedata" option in the browser, that deletes this savedata file/image then exits the browser. This file is then re-created when the browser gets started again.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x68
| 0x4?
| This counter is incremented each time the savedata is written.
|-
| 0x70
| 0x8
| Timestamp for when the savedata was last written.
|-
| 0x94
| 0x15?
| This is all-zeros on non-JPN systems. On JPN systems where the browser filter is disabled, this is a string in the following format: "4110-%016llX".
|-
| 0xD8
| 0x8
| s64 timestamp, can be either a normal positive timestamp or a relative negative one. Used with the forced-update described above. When an update is detected this timestamp is negative, otherwise this is a normal positive timestamp(it's unknown how exactly this timestamp is checked). When positive, this seems to be the last time the forced-update HTTPS request was done where no update was needed.
|}

==APT Parameters==
The URL to load can optionally be loaded from char[] string [[APT:SendParameter|paramblk+0]]. This is used when scanning URL QR-codes in Home Menu / etc.

==Errors==
"Failed to load part of this page": This can be caused by failing to load "/favicon.ico". For example, this can be caused by loading a plain HTTP page, with plain-http favicon redirecting to HTTPS. If cert-verify then fails with favicon in this case, this error would then trigger.

==Other details==

*It scored 90/100 on [http://acid3.acidtests.org/ Acid3] test
*Images from the Internet can be saved to the [[SD Filesystem|SD Card]] and viewed using the [[Nintendo 3DS Camera]] application.
*Images saved to an [[SD Filesystem|SD Card]] or to the Nintendo 3DS system memory can be uploaded to blogs or other sites that allow the uploading of photos using :
<input type="file" />
* HTML5Test.com say that Drag and drop is supported but it's not (code on WebKit is ready, but it's not implemented on interface of browser)

==Tips==

=== Detect User Agent ===

To detect if the user agent is Nintendo 3DS Browser :

<script type="text/javascript">
if (navigator.userAgent.indexOf('Nintendo 3DS') == -1) { //If the UserAgent is not "Nintendo 3DS"
location.replace('http://www.3dbrew.org'); //Redirect to an other page
}
</script>

* You can check navigator.platform=="Nintendo 3DS" as well.

=== Scrolling ===

Scrolling can be altered by modifying document.body.scrollTop and document.body.scrollLeft. However, there are drawbacks related to working with these properties:

* Both properties return 0 when accessed
* Setting one property resets the other property's scroll position

In order to set both at the same time (without either resetting to 0), use window.scrollTo.

=== Events ===
==== Key Events ====
The following buttons trigger the onkeydown, onkeypress and onkeyup events:

{|class="wikitable" width="20%"
! Code !! Button
|-
| 13 || A
|-
| 37 || Left
|-
| 38 || Up
|-
| 39 || Right
|-
| 40 || Down
|}

The events cannot have their default action cancelled. Other buttons do not trigger key events.

==== Touch/Mouse Events ====
onmousedown, onmouseup & onclick are all triggered by the browser. However, the onmousedown event doesn't trigger until you lift the stylus or you've held it on the screen for ~2 seconds—which is when text selection mode is activated—making it pretty much the same as onmouseup. The events cannot have their default action cancelled.

The onmousemove and common touch/gesture events are not supported.

== Screen Resolution ==

The up screen resolution is 400×240. However, the viewable area in the browser is only 400×220.

The touch screen resolution is 320×240. However, the viewable area in the browser is only 320×212.

You can have a page span both screens. However, the browser will behave as if the bottom screen is the only active screen and the top screen is scrolled off. This is important when computing CSS coordinates. Items positioned from "bottom" will be positioned based on 220px and not the full 432px of both screens.

== Using Both Screens ==

Generally the easiest way to accomplish the correct layout is to create HTML elements that "contain" the top and bottom screens. Here's an example:

<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=400">
<style>
body{margin:0px;}
#topscreen{width:400px;height:220px;overflow:hidden;}
#bottomscreen{width:320px;height:212px;overflow:hidden;margin:0 auto;}
</style>
</head>
<body>
<div id="topscreen">Top Screen</div>
<div id="bottomscreen">Bottom Screen</div>
</body>
</html>

This scheme allows the page to be easily manipulated through JavaScript. In order to have the window snap to the correct position, use the following JavaScript code:

window.setInterval(function () {
window.scrollTo(40, 220);
}, 50);

This automatically resets the position if the user accidentally scrolls the page.

==Example Sites==

* [http://www.nintendo.com/3ds/internetbrowser/bookmarks Nintendo 3DS Bookmarks] - This is the first bookmark pre-installed in the browser.
* [http://3ds.andysmith.co.uk/jFox.html jFox] (Short URL: http://bit.ly/iB7FqW)
* [http://ditto3d.com/3ds Ditto3D] (Short URL: http://bit.ly/oVreWA)

Makerom

2016-06-06T01:19:01Z

EvilFlight: fix sample rsf link

{{Infobox homebrew
| title = makerom
| type = pc utility
| author = [[User:3dsguy|3dsguy]]
| download = https://github.com/profi200/Project_CTR/releases
| source = https://github.com/profi200/Project_CTR/tree/master/makerom
| version = 0.15
}}

makerom is a tool which can be used to create [[NCCH]], [[NCSD|CCI]], and [[CIA]] files.

== Format Overviews ==
=== NCCH ===
The native format storing code binaries and data archives for the 3DS is [[NCCH]]. [[NCCH]] files are comprised of:
* code/exheader/plainregion (used for code execution) (plainregion just lists included SDK library add-ons)
* icon (app title text, icon, homemenu settings, see [[SMDH|here]]
* banner (cbmd + cwav, i.e. the upper screen banner/sound shown on the homemenu)
* logo (the splash screen displayed after an application is launched from the homemenu)
* romfs (read-only filesystem used to store resources)

Typical uses for NCCH files include:
* Executable image (code+exheader+icon+banner+logo+romfs)
* e-Manual archive (accessed from homemenu) (romfs)
* [[Download Play|DLP]] child CIA archive (accessed from application) (romfs)
* Update Data archive (romfs)
* Standalone data archive (romfs)
* DLC index archive (icon+romfs)
* DLC archive (romfs)

=== CCI ===
The native format for gamecard images is [[NCSD|CCI]] and is a NCCH container format. CCI files are limited to containing 8 NCCH files, and can contain NCCH files for applications titles only.
==== NCCH configuration for CCI ====
{| class="wikitable"
|-
! NCCH
! Required
! Index
|-
| Executable image
| YES
| 0
|-
| e-Manual archive
| NO
| 1
|-
| DLP child CIA archive
| NO
| 2
|-
| Update Data archive
| NO
| 7
|}

=== CIA ===
The native format for packaging NCCH files for install is [[CIA]], which is also a NCCH container format. CIA files are limited to containing 65535 NCCH files and can be used to contain NCCH files for any title type. CIA files also contain '''signed''' data used by the 3DS for general title management and DRM. Installing custom CIA files on a 3DS which also uses eShop/SysUpdates is unwise as conflicts will likely occur.

==== NCCH configurations for CIA ====
Applications (Application/DlpChild/Demo/Patch/SystemApplication):
{| class="wikitable"
|-
! NCCH
! Required
! Index
|-
| Executable image
| YES
| 0
|-
| e-Manual archive
| NO
| 1
|-
| DLP child CIA archive
| NO
| 2
|}

System Applet/Module:
{| class="wikitable"
|-
! NCCH
! Required
! Index
|-
| Executable image
| YES
| 0
|}

System Data Archives:
{| class="wikitable"
|-
! NCCH
! Required
! Index
|-
| Data archive
| YES
| 0
|}

DLC:

The number of DLC data archives in DLC varies for each DLC.
{| class="wikitable"
|-
! NCCH
! Required
! Index
|-
| DLC index archive
| YES
| 0
|-
| DLC data archive
| YES
| Varies
|}

== Using Makerom ==

=== Command line ===

makerom [general args] [rsf args] [crypto args] [ncch 0 build args] [cci args] [cia args]

'''General Arguments'''
{| class="wikitable"
|-
! Argument
! Acceptable values
! Notes
|-
| -f <format>
| 'ncch'/'cxi'/'cfa'/'cci'/'cia'
| Specify the output file format. 'ncch'/'cxi'/'cfa' has no affect, probably parsed without error for legacy support.
|-
| -o <path>
| Valid file path.
| Specify name/path for output file. Makerom will decided a name if this is not specified.
|-
| -v
| not required
| Enables verbose output.
|}

'''RSF Arguments'''
{| class="wikitable"
|-
! Argument
! Acceptable values
! Notes
|-
| -rsf <path>
| Valid file path
| Specify the path to Rom Specification File(RSF). See below for creating RSF.
|-
| -D<NAME>=<VALUE>
|
| This is used to substitute where "$(<NAME>)" exists in the RSF files with "<VALUE>". (Uppercase isn't a requirement)
|}

'''Crypto Arguments'''
{| class="wikitable"
|-
! Argument
! Acceptable values
! Notes
|-
| -target <target>
| 't'/'d'/'p'
| Specify key-chain. This affects encryption, signing and '-desc' template availability. t=test, suitable for homebrew. d=devkit(incomplete), suitable for devkits. p=retail(unusable), suitable for signing retail software?
|-
| -ckeyid <index>
| Any value between 0-255 (inclusive).
| Overrides the default common key used to encrypt CIA title keys.
|-
| -showkeys
| none
| Dumps loaded key-chain to stdout.
|}

'''NCCH Build Arguments'''
{| class="wikitable"
|-
! Argument
! Acceptable values
! Notes
|-
| -elf <file>
| Valid file path
| Specify ELF. See below for creating ELF.
|-
| -icon <file>
| Valid file path
| Specify [[SMDH|icon]].
|-
| -banner <file>
| Valid file path
| Specify banner.
|-
| -desc <apptype>:<fw>
| <apptype>='app'/'ecapp'/'demo'/'dlpchild'. <fw>='kernel version minor'.
| Use a template for [[Exheader|exheader/accessdesc]]. These are hard-coded, so not all firmwares have a template. A value from 1-7 can be used in place of 'kernel version minor'. A template shouldn't be used if the title needs "special" permissions, the RSF must be configured fully.
|-
| -exefslogo
| none
| Include logo in ExeFS. Required for usage on <5.0 systems.
|}

Arguments useful for rebuilding a NCCH file:
{| class="wikitable"
|-
! Argument
! Acceptable values
! Notes
|-
| -code <file>
| Valid file path
| Specify decompressed/plaintext exefs code binary.
|-
| -exheader <file>
| Valid file path
| Specify plaintext exheader binary.
|-
| -logo <file>
| Valid file path
| Specify logo.
|-
| -plainrgn <file>
| Valid file path
| Specify NCCH plain-region.
|-
| -romfs <file>
| Valid file path
| Specify an unencrypted RomFS binary.
|}

'''CCI Arguments'''
{| class="wikitable"
|-
! Argument
! Acceptable values
! Notes
|-
| -content <path>:<index>
| <path>=Valid file path. <index>=Any value between 0-7 (inclusive)
| Include a built NCCH file in the CCI container. "-i" can be used instead of "-content".
|-
| -devcci
| none
| Build a debug CCI?
|-
| -nomodtid
| none
| Don't modify the TitleIds of NCCH files included to match NCCH0
|-
| -alignwr
| none
| Align the offset for the Card2 writable region to the end of the last NCCH in the CCI.
|}

'''CIA Arguments'''
{| class="wikitable"
|-
! Argument
! Acceptable values
! Notes
|-
| -content <path>:<index>:<id>
| <path>=Valid file path. <index>=Any value between 0x0-0xFFFF (inclusive). <id>=Any value between 0x0-0xFFFFFFFF (inclusive)
| Include a built NCCH file in the CIA container. If <id> isn't specified, it will be generated randomly. "-i" can be used instead of "-content".
|-
| -major <version>
| Any value between 0-63 (inclusive)
| Specify the version major for the title. This cannot be used with "-dver".
|-
| -minor <version>
| Any value between 0-63 (inclusive)
| Specify the version minor for the title. This cannot be used with "-dver".
|-
| -micro <version>
| Any value between 0-15 (inclusive)
| Specify the version micro for the title.
|-
| -dver <version>
| Any value between 0-4095 (inclusive)
| Specify the data-title version for the title. This cannot be used with "-major" or "-minor".
|-
| -dlc
| none
| Specify this flag when building a DLC CIA.
|-
| -rand
| none
| Use a random title key to encrypt CIA content.
|}

==== Examples ====

General examples:

'''Create CXI'''
makerom -o sample.cxi -rsf sample.rsf -target t -elf sample.elf -icon sample.icn -banner sample.bnr -desc app:4

'''Create CFA'''
makerom -o sample.cfa -rsf sample.rsf -target t

'''Create CCI'''
makerom -f cci -o sample.cci -target t -i sample.cxi:0 -i sample.cfa:1

'''Create CIA'''
makerom -f cia -o sample.cia -target t -i sample.cxi:0:0 -i sample.cfa:1:1

Makerom supports building a NCCH file and including it automatically (as index 0) into a NCCH container:

'''Create CCI and CXI at the same time and include a CFA'''
makerom -f cci -o sample.cci -rsf sample.rsf -target t -elf sample.elf -icon sample.icn -banner sample.bnr -desc app:4 -i sample.cfa:1

'''Create CIA and CXI at the same time and include a CFA'''
makerom -f cia -o sample.cia -rsf sample.rsf -target t -elf sample.elf -icon sample.icn -banner sample.bnr -desc app:4 -i sample.cfa:1:1

Rebuilding CXI:
makerom -o rebuild.cxi -rsf rebuild.rsf -target t -code rebuild/code.bin -exheader rebuild/exheader.bin -icon rebuild/icon.bin -banner rebuild/banner.bin -romfs rebuild/romfs.bin

=== Creating RSF files ===
Inspired by Nintendo's format for their makerom, a yaml configuration file is required for creating NCCH files. CIA/CCI can be created without using a RSF file, but default settings will be used.

For CXI, RSF files can be used to specify permissions, and access control settings. Makerom can use default settings by use of the "-desc" option, which removes the requirement for specifying them in the RSF file.

Sample RSF to be used with "-desc": [https://gist.githubusercontent.com/3DSGuy/83e12e0ae3dcccb9827f/raw/sample0.rsf download] (link broken)

Sample RSF to be used without "-desc": [https://gist.github.com/jakcron/9f9f02ffd94d98a72632 download]

=== Creating ELF files ===
The latest devkitARM used in conjunction with [https://github.com/smealum/ctrulib ctrulib] can create ELF files compatible with makerom.

ELF files that are created using the official SDK are also supported by makerom.

== Compiling Source ==
For Windows a MinGW-W64/MSYS build setup is required.

For Linux, gcc/g++/make must be installed.

All additional libraries used by makerom (polarssl/libyaml) are included in the source, and are linked statically.

Hardware

2015-09-18T20:37:57Z

EvilFlight: /* Common hardware */

This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are custom made and are expanded upon here or in other pages.

== Common hardware ==
{| class="wikitable"
! Type !! Description
|-
| ARM11 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html ARM11 2x MPCore & 2x VFPv2 Co-Processor] 268MHz(~268123480 Hz).
On New3DS models, there is instead 4x MPCore, 4x VFPv2, and 268-804MHz CPU.
|-
| ARM9 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/index.html ARM946] 134MHz(~134058675 Hz),
|-
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz,
|-
| DSP || [https://twitter.com/CEVADSP/status/177172880918986752 CEVA TeakLite]. 134Mhz. 24ch 32728Hz sampling rates.
|-
| VRAM || 6 MB within SoC.
|}
The above clock-rates were calculated by calling svcGetSystemTick in sets of 5(call it, execute svcSleepThread for 1s, then call it again), then the average of those were calculated. The clock-rate listed above applies for *all* 4 New3DS MPCores.

New3DS exclusives are able to clock the CPU at 804MHz, but this appears to be limited to the currently running application/app cores. (timed by running svcGetSystemTick on either side of a long idle loop to stay in the current process context. svcSleepThread + svcGetSystemTick implies a tick counter running at 268mhz in this mode.)

== Specifications ==
{| class="wikitable"
! Type !! 3DS !! 3DSXL !! 2DS !! N3DS !! N3DSXL
|-
| SoC || CPU CTR (1048 0H)
CPU CTR (1214 32)
|| CPU CTR A (1226 60)
CPU CTR (1037 21)
|| CPU CTR B (??) || CPU LGR A (1444 86) || CPU LGR A (1446 17)
|-
| FCRAM || [http://www.fujitsu.com/downloads/MICRO/fma/pdf/MB81EDS516545_e511463.pdf 2x64MB Fujitsu MB82M8080-07L] || Fujitsu MB82DBS16641 || Fujitsu MB82DBS1664 || ?? || Fujitsu MB82MK9A9A
|-
| Storage || Toshiba THGBM2G3P1FBAI8 1GB || ?? || Toshiba THGBM4G3P1H8BAIR 1GB || Samsung KLM4G1YEQC 4GB (in 1.3GiB SLC mode)
Toshiba THGBMBG4P1KBAIT 2GB (MLC)
|| Samsung KLM4G1YEMD-B031 4GB (in 1.3GiB SLC mode)
Toshiba THGBMBG4P1KBAIT (MLC)
|-
| Audio Codec || TI PAIC3010B 0AA37DW || ?? || ?? || TI AIC3010B 39C4ETW || TI AIC3010D 48C01JW
|-
| Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf Invensense ITG-3270 MEMS Gyroscope] || ?? || ?? || ?? || ??
|-
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || ?? || ?? || ?? || ??
|-
| Wifi || Atheros AR6014 || ?? || ?? || ?? || Atheros AR6014G-AL1C
|-
| Infrared IC || NXP S750 0803 TSD031C || ?? || ?? || ?? || NXP S750 1603 TSD438C
|-
| Custom Microcontroller || Renesas UC CTR || ?? || Renesas UC CTR 324KM47 KG10 || Renesas UC KTR || Renesas UC KTR 442KM13 TK14
|-
| PMIC? || TI 93045A4 OAAH86W || ?? || ?? || TI 93045A4 38A6TYW G2 || TI 93045A4 49AF3NW G2
|}

* [11] Official Documentation

* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):

* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).

* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].

* [12] This IC is somewhat similar to [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html this].

== FCRAM ==

There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.

The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.

== SoC ==

The 3DS has much of it's internals housed in a SoC (System on Chip) just like it's predecessors. This is done to reduce build costs, cut down on power consumption, as well as make the PCB layout less complex and make the system harder to tamper with. The SoC, branded as the Nintendo 1048 0H, contains the CPU, GPU, DSP and VRAM.

According to official documents, the CPU used is a dual-core ARM11 CPU, clocked at 268MHz. One core is dedicated to system software, while the other is used for application programming, each known as the syscore and appcore, respectively.

== GPU ==

Designed by Digital Media Professionals Inc. (DMP) and codenamed PICA200, 268Mhz.

Block diagram of an ULTRAY2000 based architecture PICA200:

[[File:Pica200BlockDiagram.png]]

PICA200 is compatible with OpenGL ES 1.1. It furthermore provides unique functionality for:
* Per-fragment lighting ("Lighting Maestro")
* Hard- and soft-shadowing ("Shadow Maestro")
* Polygon subdivision ("Figure Maestro")
* Bump mapping and procedural textures ("Mapping Maestro")
* Rendering of gaseous objects ("Particle Maestro")

Some parts of the extended functionality are provided in hardware by an extended geometry pipeline. Most importantly, PICA200 has three programmable vertex processors. There is furthermore a unit called [[GPU/Primitive_Engine|Primitive Engine]], which is a geometry shader unit (using the same instruction set as vertex shaders) with support for variable-size primitives. The Primitive Engine functionality may be disabled, and the geometry shader unit then acts as a fourth vertex processor. See [[Shader_Instruction_Set]] for more information on the shader instruction set.

[[GPU/Fragment Lighting|Fragment lighting]] is implemented as an optional pipeline step during pixel processing. It's implemented by having the vertex shader output an additional attribute describing the transformation (represented by a quaternion) to surface-local space. This per-vertex quaternion can then be interpolated across screen space to calculate dot products relevant for lighting (e.g. light vector dot normal vector). To provide support for advanced lighting models, these dot products are used as indices into programmable lookup tables. With this setup, PICA200 in particular supports the shading models Blinn-Phong, Cook-Terrance, Ward, and microfacet-based BRDF-models.

PICA200 supports four texture units, the fourth of which is used exclusively for [[GPU/Procedural Texture Generation|procedural texture generation]].

== SDIO controller ==

Nintendo recommends SD cards up to 32 GB however the internal SDIO controller seems to support SD cards up to 2.19 Terabyte (32-bit sector number). It's unknown if it really can handle that much. 128 GB was tested and works fine however it causes a major slowdown of the system especially at boot.

== Images ==

=== Front ===

[[Image:CTR_Front.jpg|600px]]

[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]

=== Back ===

[[Image:CTR_Back.jpg]]

[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]

=== NAND pinout ===

NAND dumping has been successful, but the image is encrypted.

==== Normal model ====

[[Image:CTR_NAND_pinout.png]]

==== XL model ====

[[Image:CTR_NAND_pinout_XL.jpg|500px]]

==== 2DS ====

[[Image:2DSeMMC.jpg|500px]]

==== New 3DS ====

[[Image:N3DSeMMC.jpg]]

==== New 3DS XL ====

[[Image:N3DSXLeMMC.jpg]]

=== WiFi dongle pinout ===
[[Image:CTR_WiFiDongle_pinout.png|600px]]

SDIO interface is colored red:
* CLK
* CMD
* D0, D1, D2, D3

This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.

The proprietary and by now ancient DS-mode WiFi is colored yellow, pins are unknown.

I2C eeprom is colored blue:
* SCL
* SDA

SPI Flash is colored purple:
* CLK
* CS#
* SI
* SO
* WP#
* NC

=== Auxiliary Microntroller ===
[[Image:CTR_UC.png|600px]]

Monitors HOME button, WiFi switch, 3D slider, volume control slider.
Controls LEDs, various power supplies.

Devices attached to I2C bus:
* UC (master?)
* Accelerometer (slave address 0x18)
* SoC (master? slave?)

Hardware

2015-07-29T04:49:53Z

EvilFlight: restored from Google cache -yellows8 authored

This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are custom made and are expanded upon here or in other pages.

== Common hardware ==
{| class="wikitable"
! Type !! Description
|-
| ARM11 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html ARM11 2x MPCore & 2x VFPv2 Co-Processor] 268MHz(~268123480 Hz).
On New3DS models, there is instead 4x MPCore & 4x VFPv2.
|-
| ARM9 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/index.html ARM946] 134MHz(~134058675 Hz),
|-
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz,
|-
| DSP || [https://twitter.com/CEVADSP/status/177172880918986752 CEVA TeakLite]. 134Mhz. 24ch 32728Hz sampling rates.
|-
| VRAM || 6 MB within SoC.
|}
The above clock-rates were calculated by calling svcGetSystemTick in sets of 5(call it, execute svcSleepThread for 1s, then call it again), then the average of those were calculated. The clock-rate listed above applies for *all* 4 New3DS MPCores.

== Specifications ==
{| class="wikitable"
! Type !! 3DS !! 3DSXL !! 2DS !! N3DS !! N3DSXL
|-
| SoC || CPU CTR (1048 0H)
CPU CTR (1214 32)
|| CPU CTR A (1226 60)
CPU CTR (1037 21)
|| CPU CTR B (??) || CPU LGR A (1444 86) || CPU LGR A (1446 17)
|-
| FCRAM || [http://www.fujitsu.com/downloads/MICRO/fma/pdf/MB81EDS516545_e511463.pdf 2x64MB Fujitsu MB82M8080-07L] || Fujitsu MB82DBS16641 || Fujitsu MB82DBS1664 || ?? || Fujitsu MB82MK9A9A
|-
| Storage || Toshiba THGBM2G3P1FBAI8 1GB || ?? || Toshiba THGBM4G3P1H8BAIR 1GB || Samsung KLM4G1YEQC 4GB || Samsung KLM4G1YEMD-B031 4GB
|-
| Audio Codec || TI PAIC3010B 0AA37DW || ?? || ?? || TI AIC3010B 39C4ETW || TI AIC3010D 48C01JW
|-
| Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf Invensense ITG-3270 MEMS Gyroscope] || ?? || ?? || ?? || ??
|-
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || ?? || ?? || ?? || ??
|-
| Wifi || Atheros AR6014 || ?? || ?? || ?? || Atheros AR6014G-AL1C
|-
| Infrared IC || NXP S750 0803 TSD031C || ?? || ?? || ?? || NXP S750 1603 TSD438C
|-
| Custom Microcontroller || Renesas UC CTR || ?? || Renesas UC CTR 324KM47 KG10 || Renesas UC KTR || Renesas UC KTR 442KM13 TK14
|-
| PMIC? || TI 93045A4 OAAH86W || ?? || ?? || TI 93045A4 38A6TYW G2 || TI 93045A4 49AF3NW G2
|}

* [11] Official Documentation

* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):

* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).

* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].

* [12] This IC is somewhat similar to [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html this].

== FCRAM ==

There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.

The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.

== SoC ==

The 3DS has much of it's internals housed in a SoC (System on Chip) just like it's predecessors. This is done to reduce build costs, cut down on power consumption, as well as make the PCB layout less complex and make the system harder to tamper with. The SoC, branded as the Nintendo 1048 0H, contains the CPU, GPU, DSP and VRAM.

According to official documents, the CPU used is a dual-core ARM11 CPU, clocked at 268MHz. One core is dedicated to system software, while the other is used for application programming, each known as the syscore and appcore, respectively.

== GPU ==

Designed by Digital Media Professionals Inc. (DMP) and codenamed PICA 200, 268Mhz. Supports OpenGL ES 1.1.

[[File:Pica200BlockDiagram.png]]

Block diagram of an ULTRAY2000 based architecture PICA200

== SDIO controller ==

Nintendo recommends SD cards up to 32 GB however the internal SDIO controller seems to support SD cards up to 2.19 Terabyte (32-bit sector number). It's unknown if it really can handle that much. 128 GB was tested and works fine however it causes a major slowdown of the system especially at boot.

== Images ==

=== Front ===

[[Image:CTR_Front.jpg|600px]]

[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]

=== Back ===

[[Image:CTR_Back.jpg]]

[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]

=== NAND pinout ===

NAND dumping has been successful, but the image is encrypted.

==== Normal model ====

[[Image:CTR_NAND_pinout.png]]

==== XL model ====

[[Image:CTR_NAND_pinout_XL.jpg|500px]]

==== 2DS ====

[[Image:2DSeMMC.jpg|500px]]

==== New 3DS ====

[[Image:N3DSeMMC.jpg]]

==== New 3DS XL ====

[[Image:N3DSXLeMMC.jpg]]

=== WiFi dongle pinout ===
[[Image:CTR_WiFiDongle_pinout.png|600px]]

SDIO interface is colored red:
* CLK
* CMD
* D0, D1, D2, D3

This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.

The proprietary and by now ancient DS-mode WiFi is colored yellow, pins are unknown.

I2C eeprom is colored blue:
* SCL
* SDA

SPI Flash is colored purple:
* CLK
* CS#
* SI
* SO
* WP#
* NC

=== Auxiliary Microntroller ===
[[Image:CTR_UC.png|600px]]

Monitors HOME button, WiFi switch, 3D slider, volume control slider.
Controls LEDs, various power supplies.

Devices attached to I2C bus:
* UC (master?)
* Accelerometer (slave address 0x18)
* SoC (master? slave?)