DSi system flaws: Difference between revisions

(6 intermediate revisions by 4 users not shown)

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

|-

| [[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}}, {{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 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 / 2024?

| November 2023 / February 1st, 2026

| Originally {{User|PoroCYon}} / TuxSH for the implications of the GCD private keys being known.

|-

| [[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 modchip

|

| 2022

| 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?

|}

Line 79:

Line 111:

| 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 ==

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

@@ 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}}.
+|-
+| [[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}}, {{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 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 / 2024?
+| November 2023 / February 1st, 2026
+| Originally {{User|PoroCYon}} / TuxSH for the implications of the GCD private keys being known.
+|-
+| [[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 modchip
+|
+|
+| 2022
+| 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?
 |}
@@ Line 79: / Line 111: @@
 | 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 ==
-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]].