Homebrew SigHax Updates and Discussion Thread

  • Thread starter Thread starter adrifcastr
  • Start date Start date
  • Views Views 531,957
  • Replies Replies 3,813
  • Likes Likes 43
What about underclocking the CPU to increase the time window for performing the hardware exception trigger and/or undervolting/fluctuations to encourage the CPU to start making mistakes and either start leaking info, getting false-positive checks or corrupting its init til something jumps somewhere it isn't supposed to?
 
What about underclocking the CPU to increase the time window for performing the hardware exception trigger and/or undervolting/fluctuations to encourage the CPU to start making mistakes and either start leaking info, getting false-positive checks or corrupting its init til something jumps somewhere it isn't supposed to?
I think I saw this sort of post before.
 
lol it always gets released when we stop paying attention to the threads, well vita is going to get some attention from me now :-D 4 modded 3ds and one bricked one patiently waiting...
 
Kind of a noobish question, I'm sure a lot of people here know more about this than me, but if the boot9 physically disables access to the protected part of itself, why not remove the part of the system it uses to block it?
 
Kind of a noobish question, I'm sure a lot of people here know more about this than me, but if the boot9 physically disables access to the protected part of itself, why not remove the part of the system it uses to block it?
boot 9 basically disconnects from the rest of the console, by switching the pins its connected to off
 
But if it disconnects itself, it must reconnect itself at some point before the system is turned on again. Would it be possible to intercept it then?

How the arm9 Bootrom is being dumped:


ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.

Since RAM isn't cleared on boot, one can immediately start execution of their own code here to dump bootrom, OTP, etc. The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.

This requires *very* *precise* timing for triggering the hardware fault.
 
Last edited by adrifcastr,
How the arm9 Bootrom is being dumped:

ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.

Since RAM isn't cleared on boot, one can immediately start execution of their own code here to dump bootrom, OTP, etc. The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.

This requires *very* *precise* timing for triggering the hardware fault.

No sticky fingers with that :)
 
So, what's the deal right now?

A few questions:

Is boot9 publicly dumped, what is with the SafeSigHax installer, and anything else I missed
 

Site & Scene News

Popular threads in this forum