Difference between revisions of "DSi system flaws"
Hallowizer (talk | contribs) m (Replaced with exploit sections due to the small number of exploits) |
(ARM9 ROM dump mechanism) |
||
| Line 1: | Line 1: | ||
== Undefined instruction/abort exception handler backed by RAM not cleared on reset == | == 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 [[ | + | |
| + | 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]]. | ||
Discovered in June 2016 by {{User|Nocash}}, Normmatt, dark_samus, ApacheThunder (first successful exploit: {{User|PoroCYon}}, March 2021) | Discovered in June 2016 by {{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 _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. | ||
| + | |||
| + | 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}}. | ||
== Poor [[System Menu]] [[TMD]] size check == | == Poor [[System Menu]] [[TMD]] size check == | ||
Revision as of 19:20, 18 December 2022
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.
Discovered in June 2016 by 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_ 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.
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.
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 size > capacity, it checks if size > size, which is always false, resulting in a buffer overflow.
Discovered in August 2017 by Nocash
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.
Discovered in January 2010 by Datel, and blasty by reverse engineering Datel's Action Replay