DSi system flaws - Revision history

PoroCYon at 20:14, 1 February 2026

2026-02-01T19:14:13Z

← Older revision		Revision as of 22:14, 1 February 2026
Line 48:		Line 48:
	\|-		\|-
	\| [[Stage2]] header RSA signature padding not checked properly		\| [[Stage2]] header RSA signature padding not checked properly
	\| [[Stage1]] uses the SWI RSA_Decrypt_Unpad routine to verify the RSA signature of the [[stage2]] header. However, it does not check the return value of this function. This will make stage1 use ~~zero-initialized~~ memory as the plaintext RSA message for signatures with improper padding. ~~However~~, due to the specific structure of this RSA message, this will quickly be caught by stage1.		\| [[Stage1]] uses the SWI RSA_Decrypt_Unpad routine to verify the RSA signature of the [[stage2]] header. However, it does not check the return value of this function. This will make stage1 use uninitialized memory as the plaintext RSA message for signatures with improper padding. Normally, this memory is all-zeros, and due to the specific structure of this RSA message, this will quickly be caught by stage1. However, given that GCD private keys have been leaked (see below), it is in theory possible to use a signature from a gamecart to boot from [NAND] or [NVRAM].
	\|		\|
	\|		\|
	\| 2022		\| 2022 / 2024?
	\|		\| November 2023 / February 1st, 2026
	\| {{User\|PoroCYon}}		\| Originally {{User\|PoroCYon}} / TuxSH for the implications of the GCD private keys being known.
	\|-		\|-
	\| [[stage1]] hash verification code is vulnerable to fault injection		\| [[stage1]] hash verification code is vulnerable to fault injection
	\| The [[stage1]] code that verifies the first two SHA1 hashes in the RSA signature appendix (the header hash and the "hash of hashes" redundancy hash) is constructed in such a way that they can be both bypassed with a single injected fault. This makes it possible to exploit both bootroms using a a modchip		\| The [[stage1]] code that verifies the first two SHA1 hashes in the RSA signature appendix (the header hash and the "hash of hashes" redundancy hash) is constructed in such a way that they can be both bypassed with a single injected fault. This makes it possible to exploit both bootroms using a modchip
	\|		\|
	\|		\|
	\| 2022		\| 2022
	\| nov/dec 2023, see [https://media.ccc.de/v/37c3-11736-nintendo_hacking_2023_2008 37c3 talk]		\| nov/dec 2023, see [https://media.ccc.de/v/37c3-11736-nintendo_hacking_2023_2008 37c3 talk]
			\|-
			\| Gamecart (GCD) boot private keys included in Gigaleaks
			\| With private keys you can generate valid RSA signatures, and thus use an "ntrboot-style" flashcart to gain code execution without any real exploit.
			\|
			\|
			\| Dec 2023/Jan 2024
			\| July 2024
			\| asie?
	\|}		\|}

Davidbeh: Linked to source for overlay checking flaw

2025-06-21T15:42:47Z

Linked to source for overlay checking flaw

← Older revision		Revision as of 19:42, 21 June 2025
Line 103:		Line 103:
	\| January 2010		\| January 2010
	\|		\|
	\| Datel, and {{User\|blasty}} by reverse engineering Datel's [[Action Replay]]		\| Datel, and {{User\|blasty}} by [https://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/ reverse engineering] Datel's [[Action Replay]]
	\|}		\|}

	== Applications ==		== Applications ==
	Flaws in this category pertain to applications launched by [[System Menu]]. See also [[DSi exploits]].		Flaws in this category pertain to applications launched by [[System Menu]]. See also [[DSi exploits]].

PoroCYon: /* Hardware */

2024-01-01T21:34:19Z

Hardware

← Older revision		Revision as of 00:34, 2 January 2024
Line 54:		Line 54:
	\|		\|
	\| {{User\|PoroCYon}}		\| {{User\|PoroCYon}}
			\|-
			\| [[stage1]] hash verification code is vulnerable to fault injection
			\| The [[stage1]] code that verifies the first two SHA1 hashes in the RSA signature appendix (the header hash and the "hash of hashes" redundancy hash) is constructed in such a way that they can be both bypassed with a single injected fault. This makes it possible to exploit both bootroms using a a modchip
			\|
			\|
			\| 2022
			\| nov/dec 2023, see [https://media.ccc.de/v/37c3-11736-nintendo_hacking_2023_2008 37c3 talk]
	\|}		\|}

Pk11: /* Applications */ Underscore to space

2022-12-20T02:21:34Z

Applications: Underscore to space

← Older revision		Revision as of 05:21, 20 December 2022
Line 100:		Line 100:

	== Applications ==		== Applications ==
	Flaws in this category pertain to applications launched by [[System Menu]]. See also [[~~DSi_exploits~~]].		Flaws in this category pertain to applications launched by [[System Menu]]. See also [[DSi exploits]].

PoroCYon at 19:34, 19 December 2022

2022-12-19T18:34:05Z

← Older revision		Revision as of 21:34, 19 December 2022
Line 48:		Line 48:
	\|-		\|-
	\| [[Stage2]] header RSA signature padding not checked properly		\| [[Stage2]] header RSA signature padding not checked properly
	\| [[Stage1]] uses the SWI RSA_Decrypt_Unpad routine to verify the RSA signature of the [[stage2]] header. However, it does not check the return value of this function. This will make stage1 use zero-initialized memory as the plaintext RSA message. However, due to the specific structure of this RSA message, this will quickly be caught by stage1.		\| [[Stage1]] uses the SWI RSA_Decrypt_Unpad routine to verify the RSA signature of the [[stage2]] header. However, it does not check the return value of this function. This will make stage1 use zero-initialized memory as the plaintext RSA message for signatures with improper padding. However, due to the specific structure of this RSA message, this will quickly be caught by stage1.
	\|		\|
	\|		\|

PoroCYon: sorry, I demonstrated knowing of this issue on december 13 in the melonDS discord :p

2022-12-19T18:31:59Z

sorry, I demonstrated knowing of this issue on december 13 in the melonDS discord :p

← Older revision		Revision as of 21:31, 19 December 2022
Line 45:		Line 45:
	\| 2022		\| 2022
	\| December 19, 2022		\| December 19, 2022
	\| {{User\|Yellows8}}		\| {{User\|Yellows8}}, {{User\|PoroCYon}}
			\|-
			\| [[Stage2]] header RSA signature padding not checked properly
			\| [[Stage1]] uses the SWI RSA_Decrypt_Unpad routine to verify the RSA signature of the [[stage2]] header. However, it does not check the return value of this function. This will make stage1 use zero-initialized memory as the plaintext RSA message. However, due to the specific structure of this RSA message, this will quickly be caught by stage1.
			\|
			\|
			\| 2022
			\|
			\| {{User\|PoroCYon}}
	\|}		\|}

Yellows8: /* Hardware */

2022-12-19T18:05:53Z

Hardware

← Older revision		Revision as of 21:05, 19 December 2022
Line 37:		Line 37:
	\|		\|
	\| Theorized to be possible by {{User\|PoroCYon}} in 2021, first successful exploit by stuckpixel and Normmatt early November 2022, then exploited successfully two weeks later again by {{User\|PoroCYon}}.		\| Theorized to be possible by {{User\|PoroCYon}} in 2021, first successful exploit by stuckpixel and Normmatt early November 2022, then exploited successfully two weeks later again by {{User\|PoroCYon}}.
			\|-
			\| [[Stage2]] binary load region not validated
			\| [[Stage1]] doesn't validate the the load address/size for [[Stage2]] binaries. If all RSA / hash checks pass and the binary were located in memory used by [[Stage1]], this would allow running code under the context of [[Stage1]]. This is currently useless due to RSA however.
			This is somewhat similar to [https://www.3dbrew.org/wiki/3DS_System_Flaws 3DS] bootROM issues, however 3DS does attempt validation at least.
			\|
			\|
			\| 2022
			\| December 19, 2022
			\| {{User\|Yellows8}}
	\|}		\|}

Yellows8: Import an issue from 3dbrew.

2022-12-19T17:44:24Z

Import an issue from 3dbrew.

@@ Line 10: / Line 10: @@
 !  Public disclosure timeframe
 !  Discovered by
 |-
 | Undefined instruction/abort exception handler backed by RAM not cleared on reset

Yellows8: Use wiki tables.

2022-12-19T17:34:08Z

Use wiki tables.

@@ Line 1: / Line 1: @@
-== Undefined instruction/abort exception handler backed by RAM not cleared on reset ==
+= Hardware =
-Much like the 3DS boot0, some of the DSi's exception handlers are backed by RAM which isn't immediately cleared on a reset. Using fault injection, it is possible to cause an undefined instruction exception before the clearing happens, making the CPU jump to code remaining in RAM from the previous boot cycle. This only works on the ARM7, as on the ARM9, it is backed by main memory, which is only initialized by [[stage2]].
+{| class="wikitable" border="1"
-Discovered in June 2016 by {{User|Nocash}}, Normmatt, dark_samus, ApacheThunder (first successful exploit: {{User|PoroCYon}}, March 2021)
+= Software =
-== ARM7 ROM controls lockout of both boot ROMs ==
+{| class="wikitable" border="1"
-After the execution of both boot ROMs, and right before jumping to stage2, the ARM7 locks out both boot ROMs using the SCFG registers, while the ARM9 waits for this lockout (as a synchronization mechanism). By using the above exploit to take control of the ARM7, it is possible to, in the exploit payload, mimic the ARM7 ROM execution such that it performs all the loading steps, but "forgets" to lock out the ROMs. By then injecting <i>another</i> glitch, it is possible to break the ARM9 out of the waiting loop, booting the system into the System Menu (or Unlaunch) with both boot ROMs still enabled, allowing one to dump the ARM9 boot ROM.
+== System Menu ==
-Theorized to be possible by {{User|PoroCYon}} in 2021, first successful exploit by stuckpixel and Normmatt early November 2022, then exploited successfully two weeks later again by {{User|PoroCYon}}.
+{| class="wikitable" border="1"
-== Poor [[System Menu]] [[TMD]] size check ==
+== Applications ==
-[[boot1]] loads the System Menu's TMD for verification and loading, and it attempts to check the size. However, instead of checking if <code>size > capacity</code>, it checks if <code>size > size</code>, which is always false, resulting in a buffer overflow.
+Flaws in this category pertain to applications launched by [[System Menu]]. See also [[DSi_exploits]].

PoroCYon: /* ARM7 ROM controls lockout of both boot ROMs */ formatting syntax fix

2022-12-18T17:24:07Z

ARM7 ROM controls lockout of both boot ROMs: formatting syntax fix

← Older revision		Revision as of 20:24, 18 December 2022
Line 7:		Line 7:
	== ARM7 ROM controls lockout of both boot ROMs ==		== ARM7 ROM controls lockout of both boot ROMs ==

	After the execution of both boot ROMs, and right before jumping to stage2, the ARM7 locks out both boot ROMs using the SCFG registers, while the ARM9 waits for this lockout (as a synchronization mechanism). By using the above exploit to take control of the ARM7, it is possible to, in the exploit payload, mimic the ARM7 ROM execution such that it performs all the loading steps, but "forgets" to lock out the ROMs. By then injecting ~~_another_ fault~~, it is possible to break the ARM9 out of the waiting loop, booting the system into the System Menu (or Unlaunch) with both boot ROMs still enabled, allowing one to dump the ARM9 boot ROM.		After the execution of both boot ROMs, and right before jumping to stage2, the ARM7 locks out both boot ROMs using the SCFG registers, while the ARM9 waits for this lockout (as a synchronization mechanism). By using the above exploit to take control of the ARM7, it is possible to, in the exploit payload, mimic the ARM7 ROM execution such that it performs all the loading steps, but "forgets" to lock out the ROMs. By then injecting <i>another</i> glitch, it is possible to break the ARM9 out of the waiting loop, booting the system into the System Menu (or Unlaunch) with both boot ROMs still enabled, allowing one to dump the ARM9 boot ROM.

	Theorized to be possible by {{User\|PoroCYon}} in 2021, first successful exploit by stuckpixel and Normmatt early November 2022, then exploited successfully two weeks later again by {{User\|PoroCYon}}.		Theorized to be possible by {{User\|PoroCYon}} in 2021, first successful exploit by stuckpixel and Normmatt early November 2022, then exploited successfully two weeks later again by {{User\|PoroCYon}}.