Line 1: |
Line 1: |
− | == boot0 == | + | == Undefined instruction/abort exception handler backed by RAM not cleared on reset == |
− | {| class="wikitable sortable" border="1"
| + | 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 [[boot1]]. |
− | |-
| |
− | ! Summary
| |
− | ! Description
| |
− | ! Successful exploitation result
| |
− | ! Discovered
| |
− | ! Discovered by
| |
− | |-
| |
− | | 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 [[boot1]].
| |
− | | Code execution under ARM7 boot0
| |
− | | {{SortableMonth|Jun|2016}}
| |
− | | {{User|Nocash}}, Normmatt, dark_samus, ApacheThunder (first successful exploit: {{User|PoroCYon}}, March 2021)
| |
− | |}
| |
− | == boot1 ==
| |
− | {| class="wikitable sortable" border="1"
| |
− | |-
| |
− | ! Summary
| |
− | ! Description
| |
− | ! Successful exploitation result
| |
− | ! Fixed in boot1 version
| |
− | ! Discovered
| |
− | ! Discovered by
| |
− | |-
| |
− | | 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.
| |
− | | Code execution under boot1
| |
− | | Unfixed
| |
− | | {{SortableMonth|Aug|2017}}
| |
− | | {{User|Nocash}}
| |
− | |}
| |
| | | |
− | == System Menu == | + | Discovered in June 2016 by {{User|Nocash}}, Normmatt, dark_samus, ApacheThunder (first successful exploit: {{User|PoroCYon}}, March 2021) |
− | {| class="wikitable sortable" border="1"
| + | |
− | |-
| + | == Poor [[System Menu]] [[TMD]] size check == |
− | ! Summary
| + | [[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. |
− | ! Description
| + | |
− | ! Successful exploitation result
| + | Discovered in August 2017 by {{User|Nocash}} |
− | ! Discovered
| + | |
− | ! 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 [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. |
− | | 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 [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.
| + | Discovered in January 2010 by Datel, and {{User|blasty}} by reverse engineering Datel's [[Action Replay]] |
− | | Code execution under any DS game with overlays.
| |
− | | {{SortableMonth|Jan|2010}}
| |
− | | Datel, {{User|blasty}} (by reverse engineering [[Action Replay]])
| |
− | |}
| |