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

It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.

However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.

By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the Pohlig-Hellman algorithm. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.

This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.

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.

b) boot9 IRQ handler (this has the disadvantage that you must restore the original handler, then call it manually when your payload runs)

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).

Retrieving this keydata and the NAND keystore of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current New3DS-only AES keyXs including the newer batch introduced in 9.6.0-X. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.

This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <3.0.0-X.

This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.

Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.

This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.

This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x save, and 7.x NCCH keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init.

Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.

Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with 9.6.0-X.

Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.

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)

The fix for firmlaunch-hax was only applied to NATIVE_FIRM in 9.5.0-X, leaving SAFE_FIRM exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.

This was fixed by adding bound checks on the read data.

This had a use after 9.6.0-X: on a compromised 3DS running 9.2.0, you could install the 9.6.0 NATIVE_FIRM to FIRM0/FIRM1, but avoid putting it into the NATIVE_FIRM title. This would boot the 9.2.0 system software but with the 9.6.0 Process9 and Kernel11. With a user-mode exploit in a sufficiently-privileged application (e.g. mset), you could trigger a FIRM launch back to NATIVE_FIRM, which would load the 9.2.0 Process9 and Kernel11.

9.6.0's keyslots 0x15 and 0x16 are unknown to 9.2.0, so 9.2.0 would not clear them. You then could do firmlaunchhax against 9.2.0 to get ARM9 access with keyslots 0x15 and 0x16 set to their proper 9.6.0 values, allowing decrypting 9.6.0's encrypted titles. Once the New3DS keystore was dumped, this became moot.

As such, a file that starts with 8 hex digits can crash process9 if placed directly inside the extdata directory. It can crash in various ways based on subtle differences in the way the user triggers the crash event.

While mostly leading to null derefs, in one specific context, process9 jumps directly to an ID1 string being held in ARM9 memory. Surprisingly, the 3DS doesn't discern what characters are used for the ID1 directory name on the SD, only requiring exactly 32 chars. This allows the attacker to insert arm instructions into the unicode ID1 dirname and take control of the ARM9, and thus, full control of the 3DS.

• They used it as index to a lookup-table without checking the value at all.
• Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.

From 3.0.0-X this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).

This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types here) and using an Old3DS NCSD Header, it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.

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-X by preventing irqId 15 to be bound on retail units altogether (in both functions).

By passing a big enough "size" parameter, an attacker can map chunks of data at VA 0 in the destination (caller) 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.

However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.

When updating the kernel global PID counter under svcCreateProcess the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because SM-module allows processes with PID value less than to access all services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the SVCs access table at all.

Inlined ldrex+strex code is used for updating the above counter. 11.2.0-X had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.

With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).

There are multiple ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.

This was fixed in 9.3.0-X by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.

• The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.

• Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

• Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun.
• The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)

This was fixed in 7.0.0-13: starting with 7.0.0-13 "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With 7.0.0-13 there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.

This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).

Unfortunately, as of 11.4.0-37, the overwritten fields are totally unused after their initialization by __libc_init_array.

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).

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.

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).

This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.

This is exploited by ctr-httpwn.

This was fixed after ninjhax release by adding checks on CRO0-based pointers before writing to them.

While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.

A function named "UdsNode::ParseUpdateMigrationNodeInfoMessage" is called to handle packets with cmd=5.

This checks the player nodeID (returns if not player 1, that is, UDS network host), then calls an additional function which does a loop of 64-bit copies to a fixed-size stack buffer using unchecked index and data from the received packet contents.

This therefore leads to trivial RCE (of every UDS network client) by just sending a single UDS packet; only 0xC u64s on stack can be overwritten easily, but just 2 is enough to start a ROP chain and pivot to the rest of the UDS packet contents elsewhere on the stack.

To exploit some games, an attacker would need to also reimplement the DLP server protocol (and any quirks that game has when parsing the UDS network passphrase obtained from the DLP server). One game that requires this is Mario Party: Island Tour (only the dlplay child connects to a UDS network).

Earliest version of Pia known to be vulnerable is v2.x. v1.x still parses this packet, but does not have the stack-copy loop (index is still unchecked there leading to heap overflow but due to overwrites not being contiguous in memory it may or may not be exploitable).

Fixed with Pia version 4.x, which refactored the UDS send/receive wrapper code and parses completely different commands.

Wiki: November 20, 2023.