Difference between revisions of "DSi system flaws"

From DSiBrew
Jump to navigation Jump to search
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
== boot1 ==
+
= Hardware =
−
{| class="wikitable sortable" border="1"
+
Flaws in this category pertain to the underlying hardware that powers the DSi. This includes [[Stage1]], [[AES_Engine]], etc.
 +
 
 +
{| class="wikitable" border="1"
 +
!  Summary
 +
!  Description
 +
!  Fixed with hardware model/revision
 +
!  Newest hardware model/revision this flaw was checked for
 +
!  Timeframe this was discovered
 +
!  Public disclosure timeframe
 +
!  Discovered by
 +
|-
 +
| [[AES_Engine]] allows partial key overwrite
 +
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the key-generator function.
 +
This applies to the keyX/keyY too.
 +
 
 +
The 3DS TWL AES engine is also [https://www.3dbrew.org/wiki/3DS_System_Flaws affected].
 +
|
 +
|
 +
| 2011
 +
|
 +
| {{User|Yellows8}}
 +
|-
 +
| Undefined instruction/abort exception handler backed by RAM not cleared on reset
 +
| 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]].
 +
|
 +
|
 +
| June 2016
 +
|
 +
| {{User|Nocash}}, Normmatt, dark_samus, ApacheThunder (first successful exploit: {{User|PoroCYon}}, March 2021)
 
|-
 
|-
 +
| 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 <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.
 +
|
 +
|
 +
| 2021-2022
 +
|
 +
| 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 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.
 +
|
 +
|
 +
| 2022
 +
|
 +
| {{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]
 +
|}
 +
 +
= Software =
 +
== Stage2 ==
 +
Flaws in this category pertain to [[Stage2]]. There is no known updated version of Stage2 post-launch.
 +
 +
{| class="wikitable" border="1"
 
!  Summary
 
!  Summary
 
!  Description
 
!  Description
−
!  Successful exploitation result
+
!  Fixed with system version
−
!  Fixed in boot1 version
+
!  Newest system version this flaw was checked for
−
!  Discovered
+
!  Timeframe this was discovered
 +
!  Public disclosure timeframe
 
!  Discovered by
 
!  Discovered by
 
|-
 
|-
−
| Poor [[System Menu]] [[TMD]] size check
+
| Poor [[System Menu]] [[TMD]] size check
−
| [[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.
+
| [[Stage2]] 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.
−
| Code execution under boot1
+
| None
−
| Unfixed
+
|  
−
| {{SortableMonth|Aug|2017}}
+
| August 2017
−
| {{User|Nocash}}
+
|  
 +
| {{User|Nocash}}
 
|}
 
|}
  
−
== Nintendo SDK ==
+
== System Menu ==
−
Note that this refers to the common code in every game, NOT any leaked contents. Please keep leaked contents off this wiki.
+
Flaws in this category pertain to [[System Menu]].
  
−
{| class="wikitable sortable" border="1"
+
{| class="wikitable" border="1"
−
|-
 
 
!  Summary
 
!  Summary
 
!  Description
 
!  Description
−
!  Successful exploitation result
+
!  Fixed with system version
−
!  Discovered
+
!  Newest system version this flaw was checked for
 +
!  Timeframe this was discovered
 +
!  Public disclosure timeframe
 
!  Discovered by
 
!  Discovered by
 
|-
 
|-
−
| Overlays are not verified when they are loaded.
+
| DS games are not patched to verify overlays
−
| While the System Menu checks all cartridge overlays to prevent unauthorized software, no such check exists when the overlays are actually loaded. By changing the overlay after it is checked, it is possible to run arbitrary code.
+
| While the System Menu checks all cartridge overlays to prevent unauthorized software, no such check exists when the overlays are actually loaded, despite an [https://wiibrew.org/wiki/MIOS MIOS]-like patcher being possible to implement. By changing the overlay after it is checked, it is possible to run arbitrary code.
−
| Code execution under any cart game with overlays.
+
|  
−
| {{SortableMonth|Jan|2010}}
+
|  
−
| Datel, {{User|blasty}} (by reverse engineering [[Action Replay]])
+
| January 2010
 +
|  
 +
| Datel, and {{User|blasty}} by reverse engineering Datel's [[Action Replay]]
 
|}
 
|}
 +
 +
== Applications ==
 +
Flaws in this category pertain to applications launched by [[System Menu]]. See also [[DSi exploits]].

Latest revision as of 23:34, 1 January 2024

Hardware

Flaws in this category pertain to the underlying hardware that powers the DSi. This includes Stage1, AES_Engine, etc.

Summary Description Fixed with hardware model/revision Newest hardware model/revision this flaw was checked for Timeframe this was discovered Public disclosure timeframe Discovered by
AES_Engine allows partial key overwrite After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the key-generator function.

This applies to the keyX/keyY too.

The 3DS TWL AES engine is also affected.

2011 Yellows8
Undefined instruction/abort exception handler backed by RAM not cleared on reset 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. June 2016 Nocash, Normmatt, dark_samus, ApacheThunder (first successful exploit: PoroCYon, March 2021)
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 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. 2021-2022 Theorized to be possible by PoroCYon in 2021, first successful exploit by stuckpixel and Normmatt early November 2022, then exploited successfully two weeks later again by 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 3DS bootROM issues, however 3DS does attempt validation at least.

2022 December 19, 2022 Yellows8, 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 for signatures with improper padding. However, due to the specific structure of this RSA message, this will quickly be caught by stage1. 2022 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 37c3 talk

Software

Stage2

Flaws in this category pertain to Stage2. There is no known updated version of Stage2 post-launch.

Summary Description Fixed with system version Newest system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe Discovered by
Poor System Menu TMD size check Stage2 loads the System Menu's TMD for verification and loading, and it attempts to check the size. However, instead of checking if size > capacity, it checks if size > size, which is always false, resulting in a buffer overflow. None August 2017 Nocash

System Menu

Flaws in this category pertain to System Menu.

Summary Description Fixed with system version Newest system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe Discovered by
DS games are not patched to verify overlays While the System Menu checks all cartridge overlays to prevent unauthorized software, no such check exists when the overlays are actually loaded, despite an MIOS-like patcher being possible to implement. By changing the overlay after it is checked, it is possible to run arbitrary code. January 2010 Datel, and blasty by reverse engineering Datel's Action Replay

Applications

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

Retrieved from "https://dsibrew.org/w/index.php?title=DSi_system_flaws&oldid=2099907"