2
edits
Changes
Jump to navigation
Jump to search
mLine 2:
Line 2: − + − − * Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material. − + Line 21:
Line 19: − + − + + + Line 72:
Line 72: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 86:
Line 178: + + + + + + + + + + + + + + + + + + + + + + + + Line 97:
Line 213: − + Line 108:
Line 224: − + − + Line 122:
Line 238: − + − + − + + + + + + + + + + Line 164:
Line 289: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − | ARM9 code execution − | None − | [[10.3.0-28|10.3.0-X]] Line 178:
Line 385: + + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 229:
Line 476: − + Line 239:
Line 486: − + Line 286:
Line 533: − + − + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 313:
Line 587: − + Line 355:
Line 629: − + − + − + − + − + + Line 379:
Line 654: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 386:
Line 762: − + − + − | None+ − + + + + + + + + + + + + + + + + + + + + + + + Line 402:
Line 800: − + − + − + + + + + + + + + + + − + − + + + + + + + + + + + + + + + + + Line 573:
Line 997: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 586:
Line 1,039: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 601:
Line 1,233: − + − + Line 654:
Line 1,286: − + Line 704:
Line 1,336: + + + + + + + + + Line 716:
Line 1,357: + + + + + + + + + +
→FIRM Sysmodules
=Stale / Rejected Efforts=
=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.
* 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==
==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). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.
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).
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).
! Discovered by
! Discovered by
|-
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| 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.
| 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.
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 ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.
This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
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.
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| New3DS
| February 2015
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
| [[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 2<sup>43</sup> (~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 ==
== ARM9 software ==
=== arm9loader ===
=== arm9loader ===
{| class="wikitable" border="1"
{| class="wikitable" border="1"
! Public disclosure timeframe
! Public disclosure timeframe
! Discovered by
! 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
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| None
| [[10.4.0-29|10.4.0-X]]
| [[11.3.0-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| ~April 2015, implemented in May 2015
| 13 January 2016
| 13 January 2016
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| 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.
| 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.
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.
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
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| None
| [[10.4.0-29|10.4.0-X]]
| [[11.3.0-36|11.3.0-X]]
| March, 2015
| March 2015
|
|
| [[User:Plutooo|plutoo]]
| [[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
| Uncleared New3DS keyslot 0x11
| 32c3 3ds talk (December 27, 2015)
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
| [[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
| 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
| March 2015
| 32c3 3ds talk (December 27, 2015)
| 32c3 3ds talk (December 27, 2015)
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.
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.
| Bypassing title version check at installation, which then allows downgrading any title.
| None
| [[11.0.0-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]
| 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
| FAT FS code null-deref
| See description.
| See description.
| None
| None
| [[10.2.0-28|10.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| March 15, 2015
| March 15, 2015
| December 29, 2015
| December 29, 2015
| Reusing the previously used keyslot, for crypto with PS.
| Reusing the previously used keyslot, for crypto with PS.
| None
| None
| [[10.2.0-28|10.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| December 29, 2015
|-
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| [[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.
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not fixed.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
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.
| 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.
| None.
| ?
| 11.10.0-X
| April 2013
| April 2013
|
|
| [[User:Yellows8|Yellows8]]
| [[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
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
| [[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.
| 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
| ARM9 code execution
! Discovered by
! Discovered by
|-
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| [[CONFIG Registers#CFG9_SYSPROT9|CFG9_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. See [[OTP Registers|here]] regarding the data stored there.
| 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.
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. This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.x, and retrieve the required OTP data using this flaw.
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 of the [[OTP Registers|OTP]] area
| Dumping the [[OTP Registers|OTP]] area.
Decrypting New3DS sector 0x96 keyblock.
| [[3.0.0-5|3.0.0-X]]
| [[3.0.0-5|3.0.0-X]]
|
|
! Timeframe this was discovered
! Timeframe this was discovered
! Discovered by
! 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
| [[SVC]] table too small
|
|
| None
| None
| [[10.2.0-28|10.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| 2012
| 2012
| Everyone
| Everyone
|-
|-
| [[SVC|svcBackdoor (0x7B)]]
| [[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) requires patching the kernel .text or modifying SVC-access-control.
| 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
| See description
| [[11.0.0-33|11.0.0-X]] (deleted)
| [[10.2.0-28|10.2.0-X]]
|
|
|
| Everyone
| 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
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
|
|
| None
| None
| [[10.2.0-28|10.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
|
|
|
|
|-
|-
| Memchunkhax2
| 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
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]]
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
| [[10.4.0-29|10.4.0-X]]
|
|
| derrek
| [[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
| AffinityMask/processorid validation
| May 19(?)-20, 2015
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
| [[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
|}
|}
! Timeframe this was added to wiki
! Timeframe this was added to wiki
! Discovered by
! 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]]
|-
| [[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
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| [[SPI_Services|SPI]] service out-of-bounds write
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
| 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
| None
| [[9.5.0-22]]
| [[11.14.0-46]]
| March 2015
| March 2015
|
|
| 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).
| 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 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
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.
| User-mode code execution.
| None
| None
! Timeframe this was discovered
! Timeframe this was discovered
! Discovered by
! 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
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
|
|
| September(?) 2014
| 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]]
| [[User:Yellows8|Yellows8]]
|}
|}