From f1475acefaf68cf8bb215c395c9de7ddd3ca733c Mon Sep 17 00:00:00 2001 From: Tony Wasserka Date: Sat, 28 Sep 2024 11:48:30 +0200 Subject: [PATCH] Adopt href shortcode --- content/005tools.md | 2 +- content/3DSExplorer.md | 2 +- content/3DS_System_Flaws.md | 898 +++++++++--------- content/3DS_Userland_Flaws.md | 212 ++--- content/3DS_Virtual_Console.md | 6 +- content/AES_Registers.md | 104 +- content/APT:AppletUtility.md | 2 +- content/Activity_Log.md | 2 +- content/Amiibo.md | 2 +- content/CiTRUS.md | 2 +- content/Circle_Pad_Pro.md | 2 +- content/Crappy_Tiny_Reader.md | 2 +- content/DISA_and_DIFF.md | 2 +- content/DSP_Binary.md | 6 +- content/Extdata.md | 18 +- content/FIRM.md | 4 +- content/FRD_Savegame.md | 4 +- content/Flash_Filesystem.md | 84 +- content/Friend_code.md | 72 +- content/GSPGPU:RegisterInterruptRelayQueue.md | 4 +- content/GSPGPU:WriteHWRegs.md | 2 +- content/HID:GetIPCHandles.md | 12 +- content/Hardware.md | 2 +- content/Home_Menu.md | 178 ++-- content/Homebrew_Exploits.md | 18 +- content/I2C_Registers.md | 26 +- content/Inner_FAT.md | 4 +- content/Internet_Browser.md | 32 +- content/Kernel_ABI.md | 36 +- content/Memory_layout.md | 16 +- content/Mii_Maker.md | 4 +- content/NIMS:ConnectNoTicketDownload.md | 2 +- content/NIMS:RegisterSelf.md | 2 +- content/NIMS:RegisterTask.md | 10 +- content/NIMS:SetAttribute.md | 4 +- content/NIMS:UnregisterTask.md | 2 +- content/NWM_Services.md | 16 +- content/News_Services.md | 4 +- content/Nintendo_3DS_Sound.md | 2 +- .../Nintendo_Badge_Arcade/PrizeCollection.md | 2 +- content/OTP_Registers.md | 6 +- content/PSPXI:EncryptDecryptAes.md | 22 +- content/RO_Services.md | 4 +- content/SD_Filesystem.md | 14 +- content/SVC.md | 22 +- content/Services_API.md | 310 +++--- content/System_Font.md | 2 +- content/System_Settings.md | 14 +- content/YouTube.md | 10 +- 49 files changed, 1104 insertions(+), 1104 deletions(-) diff --git a/content/005tools.md b/content/005tools.md index d8323af4..9e5c727c 100644 --- a/content/005tools.md +++ b/content/005tools.md @@ -53,5 +53,5 @@ it's own.
File:005tools.png
+{{% href "../File:005tools.png" %}}>File:005tools.png
diff --git a/content/3DSExplorer.md b/content/3DSExplorer.md index 4b11f842..ba4b8ee6 100644 --- a/content/3DSExplorer.md +++ b/content/3DSExplorer.md @@ -279,7 +279,7 @@ v0.1
-
File:Screenshot +
File:Screenshot 3dsexplorer.png
diff --git a/content/3DS_System_Flaws.md b/content/3DS_System_Flaws.md index 2d697ca5..e46f4107 100644 --- a/content/3DS_System_Flaws.md +++ b/content/3DS_System_Flaws.md @@ -73,7 +73,7 @@ succeed.

exact same ARM9/ARM11 bootrom for the unprotected areas. New3DS End of February 2014 -derrek, WulfyStylez +derrek, WulfyStylez (May 2015) independently @@ -92,11 +92,11 @@ memory/AXIWRAM/VRAM keeps its contents. None New3DS March 2014 -derrek +derrek 32bits of actual console-unique TWLNAND keydata -On retail the 8-bytes at ARM9 address On retail the 8-bytes at ARM9 address 0x01FFB808 are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top @@ -108,7 +108,7 @@ generation is 8-bytes(all bytes actually set). None New3DS 2012? -Yellows8 +Yellows8 DSi / 3DS-TWL key-generator @@ -123,7 +123,7 @@ too.

None New3DS 2011 -Yellows8 +Yellows8 3DS key-generator @@ -136,12 +136,12 @@ found, leading to deducing the key-generator function. None New3DS February 2015 -Yellows8, plutoo +Yellows8, plutoo RSA keyslots don't clear exponent when setting modulus -The RSA keyslots are +The RSA keyslots are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.

However, when setting a keyslot's modulus, the RSA hardware leaves @@ -162,13 +162,13 @@ keys are located in the protected ARM9 boot ROM. None New3DS March 2016 -Myria +Myria -CFG11_GPUPROT allowing acccess to AXIWRAM/FCRAM-BASE-memregion -CFG11_GPUPROT can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has @@ -178,7 +178,7 @@ below).

None New3DS February 7, 2017 -Yellows8 +Yellows8 @@ -199,7 +199,7 @@ below).

FIRM partitions known-plaintext -The FIRM +The FIRM partitions are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM @@ -220,13 +220,13 @@ partitions. Boot9 AES keyinit function issues -Boot9 seems to have two +Boot9 seems to have two bugs in the AES key-init function, see here. +{{% href "../AES_Registers" %}} title="wikilink">here. None BootROM issue. 2015 -Yellows8 +Yellows8 New3DS has same boot ROM as Old3DS @@ -242,7 +242,7 @@ this meant that it is possible to boot Old3DS firmware on New3DS (see sighax: Boot9 improper validation of FIRM partition RSA signatures -The FIRM +The FIRM partitions are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:

@@ -272,11 +272,11 @@ one week to find a match. None New3DS July 2015 -derrek +derrek Boot9 FIRM loading doesn't blacklist memory-mapped I/O -Boot9's FIRM loading +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 @@ -287,9 +287,9 @@ runs) None New3DS 2015(?) -derrek (2015?), Normmatt and SciresM independently (January +derrek (2015?), Normmatt and SciresM independently (January 2017). @@ -332,9 +332,9 @@ to infinite loops since they shouldn't be triggered. Summary Description Successful exploitation result -Fixed in FIRM system +Fixed in FIRM system version -Last FIRM system version this +Last FIRM system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe @@ -345,11 +345,11 @@ flaw was checked for Generating the keysector console-unique keys with ITCM+Boot9 -Boot9 decrypts the -0x100-byte OTP using +Boot9 decrypts the +0x100-byte OTP using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into ITCM. This is the +{{% href "../Memory_layout" %}} title="wikilink">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.

@@ -366,7 +366,7 @@ keysector(which is dangerous). 2015 January 6, 2017 -Yellows8 +Yellows8 Rearrangable keys in the NAND keystore @@ -379,29 +379,29 @@ be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot. arm9loaderhax given existing ARM9 code execution None -11.3.0-X +11.3.0-X Early 2016 27 September 2016 -Myria, dark_samus; -mathieulh (independently); Myria, dark_samus; +mathieulh (independently); plutoo (independently) + others Uncleared OTP hash keydata in console-unique 0x11 key-generation -Kernel9Loader does not clear the Kernel9Loader does not clear the SHA_HASH register after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of OTP data used to seed the console-unique NAND keystore +{{% href "../OTP_Registers" %}} title="wikilink">OTP data used to seed the console-unique NAND keystore decryption key set on keyslot 0x11.

-

Retrieving this keydata and the 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.

@@ -411,7 +411,7 @@ 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.

+{{% href "../3.0.0-6" "broken" %}} title="wikilink">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 @@ -425,13 +425,13 @@ the moment people dumped a New3DS OTP. Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.) None -11.3.0-X +11.3.0-X ~April 2015, implemented in May 2015 13 January 2016 -WulfyStylez, Dazzozo, shinyquagsire23 -(complimentary + implemented), WulfyStylez, Dazzozo, shinyquagsire23 +(complimentary + implemented), plutoo, Normmatt (discovered independently) @@ -449,20 +449,20 @@ prerequisite hacks. See arm9loaderhax / description. See arm9loaderhax / description. Theorized around mid July, 2015. Later implemented+tested by plutoo and derrek. +{{% href "../User:Plutooo" "broken" %}} title="wikilink">plutoo and derrek. 32c3 3ds talk (December 27, 2015) -Yellows8 +Yellows8 arm9loaderhax: Missing verification block for the 9.6 keys -Starting with 9.6.0-X a +Starting with 9.6.0-X a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. -This was technically an issue from 9.5.0-X with the original sector+0 keydata, however -the below is only possible with 9.6.0-X since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.

Writing an incorrect key to NAND will cause arm9loader to decrypt the @@ -474,8 +474,8 @@ 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 +{{% href "../Savegames" %}} title="wikilink">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.

@@ -483,15 +483,15 @@ keyslot init.

can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS. -Recovery of 6.x save key/7.x Recovery of 6.x save key/7.x NCCH key, access to uncleared OTP hash keydata None -11.3.0-X +11.3.0-X March 2015 -plutoo +plutoo arm9loader runs on Old3DS @@ -503,17 +503,17 @@ New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS. arm9loader bugs also compromise Old3DS None -11.3.0-X +11.3.0-X Sometime in 2015 -plutoo +plutoo presumably Uncleared New3DS keyslot 0x11 -Originally the New3DS FIRM +Originally the New3DS FIRM arm9bin loader only cleared keyslot 0x11 when it gets executed at -firmlaunch. This was fixed with 9.5.0-X by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11. This means that any ARM9 code that can execute before the loader clears the keyslot @@ -522,16 +522,16 @@ keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.

Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with 9.6.0-X. +{{% href "../9.6.0-24" %}} title="wikilink">9.6.0-X. New3DS keyXs generation -Mostly fixed with Mostly fixed with 9.5.0-X, completely fixed with new keys with 9.6.0-X. +{{% href "../9.6.0-24" %}} title="wikilink">9.6.0-X. -February 3, 2015 (one day after February 3, 2015 (one day after 9.5.0-X release) -Yellows8 +Yellows8 @@ -544,9 +544,9 @@ title="wikilink">9.5.0-X release) Summary Description Successful exploitation result -Fixed in FIRM system +Fixed in FIRM system version -Last FIRM system version this +Last FIRM system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe @@ -556,11 +556,11 @@ flaw was checked for Leak of normal-key matching a key-scrambler key -New 3DS firmware versions 8.1.0 through 9.2.0 set the encryption key for New 3DS firmware versions 8.1.0 through 9.2.0 set the encryption key for Amiibo data using a hardcoded normal-key in -Process9. In firmware 9.3.0, +Process9. In firmware 9.3.0, Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.

@@ -570,20 +570,20 @@ key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced. Deducing the keyX for keyslot 0x39 and the key scrambler algorithm -New 3DS 9.3.0-X, sort +New 3DS 9.3.0-X, sort of -10.0.0-X +10.0.0-X Sometime in 2015 after the hardware key-generator was broken. 32c3 3ds talk (December 27, 2015) -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 hardware generated key. However while +{{% href "../AES" %}} title="wikilink">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 @@ -596,12 +596,12 @@ common-key keyX is recovered.

the retail key-generator. Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys. -pre-1.0.0-X +pre-1.0.0-X Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk January 20, 2016 -jakcron +jakcron Factory firmware is vulnerable to sighax @@ -612,27 +612,27 @@ version 1.0.0-0. Deducing the mechanics of the sighax vulnerability in boot9 without having a dump of protected boot9. ARM9 code execution on factory/earlier firmware. -1.0.0-X -1.0.0-X +1.0.0-X +1.0.0-X May 9, 2017 May 19, 2017 -SciresM, Myria +SciresM, 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 +{{% href "../11.14.0-46" %}} title="wikilink">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-X +11.14.0-X 2020 December 18, 2020 -MrNbaYoh +MrNbaYoh twlhax: Corrupted SRL header leads to memory overwrite @@ -651,8 +651,8 @@ and for DSi mode's interleaved memory, it is possible to overwrite part of Process9's stack and take control with a ROP chain.

Fixed in 11.8.0-X by... (fill me in) ARM9 code execution (whilst still in 3DS mode) -11.8.0-X -11.8.0-X +11.8.0-X +11.8.0-X August 11, 2018 smea @@ -665,7 +665,7 @@ AGB_FIRM can be tricked into executing the still vulnerable PrepareArm9ForTwl function. ARM9 code execution (whilst still in 3DS mode) None -11.14.0-X +11.14.0-X December 17, 2020 Everyone @@ -676,12 +676,12 @@ PrepareArm9ForTwl function. updated for vuln fixes), this can be noticed by just checking 3dbrew/ninupdates title-listings.

The fix for firmlaunch-hax was only applied to NATIVE_FIRM in 9.5.0-X, leaving SAFE_FIRM +{{% href "../9.5.0-22" %}} title="wikilink">9.5.0-X, leaving SAFE_FIRM exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead. ARM9 code execution -11.3.0-X +11.3.0-X 2012-2013? Wiki: January 2, 2017 @@ -701,7 +701,7 @@ attack.

This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4. ARM9 code execution -11.4.0-X +11.4.0-X safefirmhax fix Wiki: April 10, 2017 @@ -717,34 +717,34 @@ trigger a buffer overflow. With a custom banner for a NTR flashcart, this leads to code execution in Process9.

This was fixed by adding bound checks on the read data. ARM9 code execution -10.4.0-X +10.4.0-X March 2015 32c3 3ds talk (December 27, 2015) -plutoo +plutoo -Title downgrading via AM(Title downgrading via AM(PXI) When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.

However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the Title_Database, Process9 +{{% href "../Title_Database" %}} title="wikilink">Title_Database, Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.

-

11.0.0-X fixed this for key +

11.0.0-X fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs. Bypassing title version check at installation, which then allows downgrading any title. -11.0.0-X, for key system +11.0.0-X, for key system titles. -NATIVE_FIRM / AM-sysmodule NATIVE_FIRM / AM-sysmodule 11.0.0-X ? @@ -754,19 +754,19 @@ title="wikilink">11.0.0-X Anti-downgrade list did not include all system titles initially The anti-downgrade list did not include legacy FIRMs until 11.8.0-X. Therefore, legacy FIRMs +{{% href "../11.8.0-41" %}} title="wikilink">11.8.0-X. Therefore, legacy FIRMs could still be downgraded. Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below). -11.8.0 -11.8.0 +11.8.0 +11.8.0 ? Wiki: August 5, 2018 Everyone TWL_FIRM cmd-9 unchecked offset -In 1.0.0-X's TWL_FIRM, +In 1.0.0-X's TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were). Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).

@@ -778,24 +778,24 @@ arm9mem, NTR secure area in fcram, TWL secure area in fcram], to

offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.

-

In 2.0.0-X TWL_FIRM, those +

In 2.0.0-X TWL_FIRM, those commands were stubbed out. ARM9 code execution -2.0.0-X -2.0.0-X +2.0.0-X +2.0.0-X January 2018 Wiki: August 5, 2018 -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-X now prevents +(11.0.0-X now prevents installing old versions of system titles, but this doesn't affect titles already installed.)

-

This had a use after 9.6.0-X: +

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 @@ -811,11 +811,11 @@ keystore was dumped, this became moot. Decrypting 9.6.0 NCCH files without dumping New3DS keystore None (but now moot) -9.6.0-X +9.6.0-X March 2015 August 12, 2018 -Yellows8, Myria +Yellows8, Myria FAT FS code null-deref @@ -845,18 +845,18 @@ Checking for unused clusters. Leaving filesystem unchanged. Useless null-based-read None -9.6.0-X +9.6.0-X July 8-9, 2015 -Yellows8 +Yellows8 -FS:EnumerateExtSaveData crashes process9 when trying to parse a file as an extdata directory in Data Management (MSET9) In the implementation for FSPXI:EnumerateExtSaveData (called by -MSET to parse 3DS extdata +MSET to parse 3DS extdata IDs for Data Management), the return value of the P9 internal function call to open a directory (when enumerating contents of the extdata directory) was not checked. Therefore, if the call fails, an @@ -874,7 +874,7 @@ dirname and take control of the ARM9, and thus, full control of the 3DS. ARM9 code execution (primary) None -11.17.0-X +11.17.0-X April 2022 August 7, 2023 zoogie @@ -882,7 +882,7 @@ dirname and take control of the ARM9, and thus, full control of the RSA signature padding checks The TWL_FIRM RSA sig padding check code used for all TWL RSA -sig-checks has issues, see here. The +sig-checks has issues, see here. The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem @@ -890,15 +890,15 @@ here because there's proper padding check code which is executed prior to this. None -9.5.0-X +9.5.0-X March 2015 -Yellows8 +Yellows8 -AMPXI:ValidateDSiWareSectionMAC AES keyslot reuse +{{% href "../AES_Registers" %}} title="wikilink">AES keyslot reuse When the input DSiWare section index is higher than , Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. @@ -912,15 +912,15 @@ this. This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc. See description. None -11.3.0-X +11.3.0-X March 15, 2015 December 29, 2015 -Yellows8 +Yellows8 -pxips9 AES keyslot +pxips9 AES keyslot reuse -This requires access to the This requires access to the ps:ps/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk). When an invalid key-type value is passed to any of the PS commands, @@ -931,46 +931,46 @@ continue to do crypto with whatever AES keyslot was selected before the PS command was sent. Reusing the previously used keyslot, for crypto with PS. None -11.3.0-X +11.3.0-X Roughly the same time(same day?) as firmlaunch-hax. December 29, 2015 -Yellows8 +Yellows8 firmlaunch-hax: FIRM header ToCToU This can't be exploited from ARM11 userland. During FIRM launch, the only FIRM header the +{{% href "../FIRM" %}} title="wikilink">FIRM launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data. With 9.5.0-22 the address of this FIRM +{{% href "../9.5.0-22" %}} title="wikilink">9.5.0-22 the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00. ARM9 code execution -9.5.0-22 +9.5.0-22 -2012, 3 days after 2012, 3 days after Yellows8 started Process9 code RE. -Yellows8 +Yellows8 Uninitialized data output for (PXI) command replies PXI commands for various services(including some here and many +{{% href "../Filesystem_services_PXI" %}} title="wikilink">here and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error. Certain ARM11 service commands have this same issue as well. None -9.3.0-X +9.3.0-X ? -Yellows8 +Yellows8 -FSPXI +FSPXI OpenArchive SD permissions Process9 does not use the exheader ARM9 access-mount permission flag for SD at all. This would mean ARM11-kernelmode code / fs-module @@ -979,13 +979,13 @@ for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway. None -9.3.0-X +9.3.0-X 2012 -Yellows8 +Yellows8 -AMPXI:ExportDSiWare export path Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. @@ -998,14 +998,14 @@ NUL-terminator to the end of the buffer. "nand:/" etc. This isn't really useful since the data which gets written can't be controlled. None -9.5.0-22 +9.5.0-22 April 2013 -Yellows8 +Yellows8 -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 @@ -1021,12 +1021,12 @@ SD .bin files. 11.10.0-X April 2013 -Yellows8 +Yellows8 seedminer: movable.sed keyY vulnerable to brute-force Half of the movable.sed keyY's 128 bits are leaked through the LFCS, which +{{% href "../Nandrw/sys/LocalFriendCodeSeed_B" %}} title="wikilink">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 @@ -1077,57 +1077,57 @@ execution. zoogie -Gamecard_Services_PXI unchecked REG_CTRCARDCNT transfer-size The u8 REG_CTRCARDCNT transfer-size parameter for the Gamecard_Services_PXI +{{% href "../Gamecard_Services_PXI" %}} title="wikilink">Gamecard_Services_PXI read/write CTRCARD commands is used as an index for an array of u16 -values. Before 5.0.0-X this u8 +values. Before 5.0.0-X this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case). Out-of-bounds read for a value which gets written to a register. -5.0.0-X +5.0.0-X 2013? -Yellows8 +Yellows8 -PXI cmdbuf buffer +PXI cmdbuf buffer overrun -The Process9 code responsible The Process9 code responsible PXI communications didn't verify the size of the incoming command before writing it to a C++ member variable. Probably ARM9 code execution -5.0.0-11 +5.0.0-11 March 2015, original timeframe if any unknown -plutoo/Yellows8/maybe +plutoo/Yellows8/maybe others(?) -PXIAM:ImportCertificates (See also this) +{{% href "../Application_Manager_Services" %}} title="wikilink">this) When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes -are copied). Starting with 5.0.0-X, the total combined size of the input data must be <=0x2800. ARM9 code execution -5.0.0-X +5.0.0-X May 2013 -Yellows8 +Yellows8 -PS RSA +PS RSA commands buffer overflows pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM @@ -1136,18 +1136,18 @@ SignRsaSha256 also has a buf overflow, but this isn't exploitable. The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses svcBreak. +{{% href "../SVC" %}} title="wikilink">svcBreak. ARM9 code execution -5.0.0-X +5.0.0-X 2012 -Yellows8 +Yellows8 -PXI pxi_id bad +PXI pxi_id bad check -The Process9 code responsible for The Process9 code responsible for PXI communications read pxi_id as a signed char. There were two flaws:

Maybe ARM9 code execution -3.0.0-5 +3.0.0-5 March 2015, originally 2012 for the first issue at least -plutoo, Yellows8, maybe +plutoo, Yellows8, maybe others(?) @@ -1177,9 +1177,9 @@ others(?) Summary Description Successful exploitation result -Fixed in FIRM system +Fixed in FIRM system version -Last FIRM system version this +Last FIRM system version this flaw was checked for Timeframe this was discovered Discovered by @@ -1187,15 +1187,15 @@ flaw was checked for -CFG9_SYSPROT9 bit1 not set by Kernel9 Old versions of Kernel9 never set bit1 of CFG9_SYSPROT9. This leaves the 0x10012000-region unprotected +{{% href "../OTP_Registers" %}} title="wikilink">0x10012000-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.

-

From 3.0.0-X this was fixed by +

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 @@ -1205,17 +1205,17 @@ 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 +{{% href "../NCSD" %}} title="wikilink">NCSD Header, it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw. -Dumping the OTP +Dumping the OTP area. Decrypting New3DS sector 0x96 keyblock. -3.0.0-X +3.0.0-X February 2015 -plutoo, Normmatt +plutoo, Normmatt independently @@ -1231,9 +1231,9 @@ independently Summary Description Successful exploitation result -Fixed in FIRM system +Fixed in FIRM system version -Last FIRM system version this +Last FIRM system version this flaw was checked for Timeframe this was discovered Discovered by @@ -1241,7 +1241,7 @@ flaw was checked for -svcUnbindInterrupt double free +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 @@ -1252,36 +1252,36 @@ inside a singleton static object after having its refcount increased by 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 This was "fixed" on 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-X (only on +11.14.0-X (only on retail units) -11.14.0-X +11.14.0-X 2019 -TuxSH, maybe +TuxSH, maybe others -svcKernelSetState op=3 could +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-X, +

Starting from 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-X -11.14.0-X +11.14.0-X +11.14.0-X 2019 -TuxSH +TuxSH -svcMapProcessMemory can map +svcMapProcessMemory can map the NULL page svcMapProcessMemory's destination VA is unchecked.

By passing a big enough "size" parameter, an attacker can map chunks @@ -1289,9 +1289,9 @@ 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-X +11.14.0-X 2020 -TuxSH +TuxSH Resource limit use-after-free @@ -1301,24 +1301,24 @@ 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 svcGetResourceLimit +

Calling 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-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-X, anyway). +{{% href "../11.14.0-46" %}} title="wikilink">11.14.0-X, anyway). Arm11 kernel code execution -None (although near impossible to exploit on None (although near impossible to exploit on 11.14.0-X) -11.14.0-X +11.14.0-X 2020 -TuxSH +TuxSH -svcSetProcessIdealProcessor +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 @@ -1328,41 +1328,41 @@ gets incremented,later the function check if the KProcess->mem_type won't meet any condition and return the error 0xD9001BEA without decrement the reference count. It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. -Before 11.2.0-X: +Before 11.2.0-X: reference count overflow and therefore use-after-free. -11.6.0-X +11.6.0-X November 2, 2017 -st4rk +st4rk -svcGetThreadList process +svcGetThreadList process reference leak When given a valid process handle (including 0xFFFF8001), svcGetThreadList forgets to decrement the -reference count of the underlying KProcess instance, after having finished using it. -Before 11.2.0-X: +Before 11.2.0-X: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable -11.3.0-X +11.3.0-X April 3, 2017 -TuxSH +TuxSH kernelhax via gspwn Originally the kernel didn't initialize CFG11_GPUPROT. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM. Entire FCRAM+AXIWRAM R/W. -3.0.0-X +3.0.0-X February 7, 2017 -plutoo, Yellows8 partly +plutoo, Yellows8 partly fasthax @@ -1372,8 +1372,8 @@ is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call. See description. -11.3.0-X -11.3.0-X +11.3.0-X +11.3.0-X May 2016 nedwill @@ -1391,9 +1391,9 @@ takeover can be done too(actual stack buffer overflow can trigger), etc. See description. None -11.3.0-X +11.3.0-X November 26, 2016 -Yellows8 +Yellows8 Using IPC input buffers as output buffers @@ -1405,12 +1405,12 @@ with this.

Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx". See description. None -11.3.0-X +11.3.0-X November 2016 -Yellows8 +Yellows8 -SVC table too small +SVC table too small The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the @@ -1420,18 +1420,18 @@ SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable. None -11.3.0-X +11.3.0-X 2012 Everyone -svcBackdoor (0x7B) +svcBackdoor (0x7B) This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control. See description -11.0.0-X +11.0.0-X (deleted) @@ -1442,27 +1442,27 @@ SVC-access-control. This is completely different from the kernelmode-code-execution vuln described in the below separate entry.

-

When updating the kernel global PID counter under 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 +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 +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 +{{% href "../11.2.0-35" %}} title="wikilink">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 Access to all services, ControlMemory on any given mem-region. None -11.3.0-X +11.3.0-X 2012 maybe? @@ -1473,14 +1473,14 @@ valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero. ARM11 kernel-mode code execution -11.2.0-X -11.2.0-X +11.2.0-X +11.2.0-X 2016 -nedwill, nedwill, derrek -0xEFF00000 / 0xDFF00000 ARM11 kernel virtual-memory The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size @@ -1491,13 +1491,13 @@ this never seems to be used after that, however. This is never unmapped either. None -11.3.0-X +11.3.0-X memchunkhax2.1 -Nintendo's fix for memchunkhax2 in Nintendo's fix for memchunkhax2 in 10.4.0-X did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation. derrek's original 32c3 presentation for memchunkhax2 commented that a @@ -1505,19 +1505,19 @@ GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably. ARM11 kernel code execution -11.0.0-X, via the new 11.0.0-X, via the new memchunkhdr MAC which prevents modifying memchunkhdr data with DMA. -11.0.0-X +11.0.0-X -derrek, +derrek, aliaspider memchunkhax2 When allocating a block of memory, the "next" pointer of the memchunkhdr is accessed without being checked after being mapped to userland. This allows a race condition, where the process can change the next pointer just before it's accessed. By @@ -1525,11 +1525,11 @@ pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. ARM11 kernel code execution -10.4.0-X (partially, see +10.4.0-X (partially, see memchunkhax2.1) -10.4.0-X +10.4.0-X -derrek +derrek heaphax @@ -1540,11 +1540,11 @@ allocate RW memory over any part of the NS system module, which is enough to take it over. Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet. -11.0.0-X, via the new 11.0.0-X, via the new memchunkhdr MAC which prevents modifying memchunkhdr data with DMA. -11.0.0-X +11.0.0-X April 2015 ? smea @@ -1554,14 +1554,14 @@ memchunkhdr data with DMA. allowing for takeover. Code execution with access to all of NS's privileges. (including downgrading) -10.1.0-X -10.1.0-X +10.1.0-X +10.1.0-X April 2015 ? smea AffinityMask/processorid validation -With 10.0.0-X the +With 10.0.0-X the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are @@ -1577,7 +1577,7 @@ identical. The original code with the first 3 did the following:

In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.

-

The svcCreateThread changes with The svcCreateThread changes with 10.0.0-X definitely did fix a security issue.