- Joined
- Jan 25, 2024
- Messages
- 5,658
- Points
- 38
- Age
- 38
- Location
- USA
- Website
- gameparadise.org
- Credits
- 97,093
What we have:
SafeSighaxInstaller by d0k3
bootstrap9 by Yellows8
bootstrap11 by Yellows8
CTR Firm Builder by Derrek
Boot9 Tools by Yellows8
Boot9 SHA-256? Hash: 2F88744FEED717856386400A44BBA4B9CA62E76A32C715D4F309C399BF28166F
Boot11 SHA-256? Hash: 74DAACE1F8067B66CC81FC307A3FDB509CBEDC32F903AEBE906144DEA7A07512
How the arm9 Bootrom is being dumped:
YOU SHOULD BETTER READ THIS FIRST:
SafeSighaxInstaller by d0k3
bootstrap9 by Yellows8
bootstrap11 by Yellows8
CTR Firm Builder by Derrek
Boot9 Tools by Yellows8
Boot9 SHA-256? Hash: 2F88744FEED717856386400A44BBA4B9CA62E76A32C715D4F309C399BF28166F
Boot11 SHA-256? Hash: 74DAACE1F8067B66CC81FC307A3FDB509CBEDC32F903AEBE906144DEA7A07512
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.
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.
He did not make any Bootrom Public.
hedgeberg and Greg the 2DS are using this method to dump the arm9 Bootrom which is known as boot9
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.
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.
He did not make any Bootrom Public.
hedgeberg and Greg the 2DS are using this method to dump the arm9 Bootrom which is known as boot9
YOU SHOULD BETTER READ THIS FIRST:
What exactly is SigHax?
SignatureHax, SigHax for short is a Bootrom Exploit revealed by Derrek at the 33c3.
What does that mean?
Since Derrek was able to dump the 3DS Bootroms and and to Exploit them we can now sign our own NAND images.
A bit more accurate?
If a bootrom was made public it could then be used to procede.
Then you'd be able to create a signature that ends up on a pointer to the check, which will compare itself with itself. (The actual sighax part) to sign firmwares with this manipulated signature.
Thats not accurate egnough! What can we do with SigHax then?
SigHax let's you exploit signature verification of the bootrom to basically run "unsigned" (well hax-signed) firmware.
This has to be written to the firm partition.
This means your patches would be done static directly to the FIRM and written to the device. This exploit effectively "skips" the signature checking.
Therefore it can run before otp disable etc.
It runs at pretty much the earliest state you can get it.
This will make it launch slightly faster than A9LH.
It is useful if you want to install stuff like a custom OS on the 3DS.
The disadvantage is, that's not as dynamic is A9LH due to it not being a payload on SD, that can easily be exchanged. (Unless your FIRM would load patches from sd. Which then wouldn't really make a lot of sense to use this exploit)
Therefore it's harder to update - basically like an A9LH update (not the payload but the actual FIRM write).
You risk bricking each time you write to the FIRM
Can this be Patched by Nintendo?
No. Since this is a Bootrom Exploit, it is literally unpatchable. Just a hardware revision could fix that.
So arm9loaderhax is obsolete then?
Basically Yes when SigHax is released. But better keep it, that will make the future Update to SigHax easier for you.
What are we actually doing with arm9loaderhax?
We currently patch the official firmware with A9LH and inject cfw code into it.
Then basically have "cfw".
This is done via a verification exploit of Arm9 and loads a payload AFTER arm9 is ran.
So since there will be SigHax it is safe to Update past 11.X when Nintendo releases System Updates then?
No. if you haven't installed arm9loaderhax to your 3DS System do NOT UPDATE past 11.3
For Now:
We are not yet able to do any of this.
Derrek did dump the bootrom and provided a simple explanation of how he did it.
He did not make the bootrom public though. Nor any of the code he used.
This means someone would have to develop code that exploits the Bootrom pointers and leads them to dumper code to dump the bootrom. Which is unstable and likely needs you to have a hardmod to trigger this very early exception without the chance of killing your device.
SignatureHax, SigHax for short is a Bootrom Exploit revealed by Derrek at the 33c3.
What does that mean?
Since Derrek was able to dump the 3DS Bootroms and and to Exploit them we can now sign our own NAND images.
A bit more accurate?
If a bootrom was made public it could then be used to procede.
Then you'd be able to create a signature that ends up on a pointer to the check, which will compare itself with itself. (The actual sighax part) to sign firmwares with this manipulated signature.
Thats not accurate egnough! What can we do with SigHax then?
SigHax let's you exploit signature verification of the bootrom to basically run "unsigned" (well hax-signed) firmware.
This has to be written to the firm partition.
This means your patches would be done static directly to the FIRM and written to the device. This exploit effectively "skips" the signature checking.
Therefore it can run before otp disable etc.
It runs at pretty much the earliest state you can get it.
This will make it launch slightly faster than A9LH.
It is useful if you want to install stuff like a custom OS on the 3DS.
The disadvantage is, that's not as dynamic is A9LH due to it not being a payload on SD, that can easily be exchanged. (Unless your FIRM would load patches from sd. Which then wouldn't really make a lot of sense to use this exploit)
Therefore it's harder to update - basically like an A9LH update (not the payload but the actual FIRM write).
You risk bricking each time you write to the FIRM
Can this be Patched by Nintendo?
No. Since this is a Bootrom Exploit, it is literally unpatchable. Just a hardware revision could fix that.
So arm9loaderhax is obsolete then?
Basically Yes when SigHax is released. But better keep it, that will make the future Update to SigHax easier for you.
What are we actually doing with arm9loaderhax?
We currently patch the official firmware with A9LH and inject cfw code into it.
Then basically have "cfw".
This is done via a verification exploit of Arm9 and loads a payload AFTER arm9 is ran.
So since there will be SigHax it is safe to Update past 11.X when Nintendo releases System Updates then?
No. if you haven't installed arm9loaderhax to your 3DS System do NOT UPDATE past 11.3
For Now:
We are not yet able to do any of this.
Derrek did dump the bootrom and provided a simple explanation of how he did it.
He did not make the bootrom public though. Nor any of the code he used.
This means someone would have to develop code that exploits the Bootrom pointers and leads them to dumper code to dump the bootrom. Which is unstable and likely needs you to have a hardmod to trigger this very early exception without the chance of killing your device.
