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 74:
Line 72: − |- − | 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 Line 98:
Line 85: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 106:
Line 124: − + − + − − See also "kernelhax via gspwn" below. − + − + − + − + − + − When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.+ Line 129:
Line 145: − + + + + + + + + + + + + + + Line 199:
Line 228: − + Line 212:
Line 241: − + + + + + + + + + + Line 254:
Line 292: − − + Line 267:
Line 304: − + − + Line 274:
Line 311: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 323:
Line 393: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 425:
Line 533: − + − + − + − + − + Line 447:
Line 555: − + + + + + + + + + + Line 470:
Line 587: − + Line 512:
Line 629: − + − + − + − + + Line 536:
Line 654: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 834:
Line 998: − + Line 843:
Line 1,007: + + + + + + + + + + + + + + + + + + + Line 856:
Line 1,039: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 916:
Line 1,164: − + Line 965:
Line 1,213: − + − | [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])+ Line 985:
Line 1,233: − + − + Line 1,088:
Line 1,336: + + + + + + + + +
→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==
| 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
| RSA keyslots don't clear exponent when setting modulus
| March 2016
| March 2016
| [[User:Myria|Myria]]
| [[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
| Boot9 AES keyinit function issues
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| New3DS has same boot ROM as Old3DS
| [[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).
| 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
| None
| New3DS
| New3DS
| February 7, 2017
| October 2014
| [[User:Yellows8|Yellows8]]
| Everyone
|-
|-
| sighax: Boot9 improper PKCS #1 v1.5 signature validation
| 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, does improper validation of the padding in three ways:
| 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, 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 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 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.
# 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.
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
| None
| New3DS
| New3DS
|-
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| 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.
| [[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
| None
| New3DS
| New3DS
| 2015(?)
| 2015(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).
| [[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]]
|}
|}
| [[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.
| None
| None
| [[11.3.0-36|11.3.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
| Leak of normal-key matching a key-generator key
| 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.
| 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.
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.
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.
| 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]]
| pre-[[1.0.0-0|1.0.0-X]]
|-
|-
| Factory firmware is vulnerable to sighax
| 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.
| 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.
| 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]]
| [[1.0.0-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 19, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
| [[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
| safefirmhax
|
|
| ?
| ?
|-
| 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
|-
|-
| [[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 useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.
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.
| None.
| None.
| 11.6.0-X
| 11.10.0-X
| April 2013
| April 2013
|
|
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
|-
| movable.sed keyY vulnerable to brute-force
| 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.
| 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.
| 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.
| None.
| 11.6.0-X
| 11.8.0-X
| December 2017
| December 2017
| January 2018
| January 2018
| 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.
| 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.
| None.
| 11.6.0-X
| 11.10.0-X
| 2015?
| 2015?
| December 2016
| December 2016
| Everyone
| 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.
| 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).
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.
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.
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
|-
| [[SM]] out-of-bounds BSS write (table 1 entry too small)
| 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.
| 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.
|
|
|
|
|-
| 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]] missing input array index validation
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.
| ROP under NWM-module.
| ROP under NWM-module.
| [[11.4.0-37|11.4.0-X]]
| None (need to check, but CTRSDK heap code is vulnerable)
| [[9.0.0-20|9.0.0-X]]
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 10, 2016
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| ROP under HTTP sysmdule.
| [[11.4.0-37|11.4.0-X]]
| None
| [[11.13.0-45|11.13.0-X]]
| Late 2015
| Late 2015
| March 22, 2016
| March 22, 2016
| [[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
|
|
! 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