Well, feel free to be happy!This is just the greatest 3DS news I've heard so far. I can't believe I missed this.
Well, feel free to be happy!This is just the greatest 3DS news I've heard so far. I can't believe I missed this.
I think I saw this sort of post before.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?
we dont know when something will pop upCan we get a sighax clock (like new years)?
Sent from my SM-G935W8 using Tapatalk
boot 9 basically disconnects from the rest of the console, by switching the pins its connected to offKind 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?
would be funny if you added a month everytime someone asksDont worry i made a countdown untill the release: https://www.timeanddate.com/countdown/launch?p0=764&iso=39990313T00&year=3999&month=3&day=13&hour=0&min=0&sec=0&msg=Sighax release&ud=1
It actually doesnt allow me to make it a year longer. This is close to the cap.would be funny if you added a month everytime someone asks
wonder if there would be a hardmod-like way around that...boot 9 basically disconnects from the rest of the console, by switching the pins its connected to off
no.wonder if there would be a hardmod-like way around that...
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?
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.
read OPSo, what's the deal right now?
A few questions:
Is boot9 publicly dumped, what is with the SafeSigHax installer, and anything else I missed