Changes

6 bytes added ,  19:24, 18 December 2022
m
Line 7: Line 7:  
== ARM7 ROM controls lockout of both boot ROMs ==
 
== 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.
+
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.
    
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}}.
75

edits