DSiBrew

DSi system flaws: Difference between revisions

← Older edit
Use wiki tables.
PoroCYon (talk | contribs)
81 edits
No edit summary
 
(7 intermediate revisions by 4 users not shown)
Line 10: Line 10:
!  Public disclosure timeframe
!  Public disclosure timeframe
!  Discovered by
!  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
| Undefined instruction/abort exception handler backed by RAM not cleared on reset
Line 26: 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}}, {{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 68: Line 111:
| 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]].
Retrieved from "https://dsibrew.org/wiki/DSi_system_flaws"