Homebrew SigHax Updates and Discussion Thread

adrifcastr

Well-Known Member
OP
Member
Joined
Sep 12, 2016
Messages
2,038
Trophies
0
XP
1,947
Country
Germany
CURRENT STATUS:
9/11/17

NTRBoot for R4igoldcc,ARDS(EZ),ARDSI

08/12/17

NTRBoot is released

08/04/17
3ds.guide / https://3ds.guide/updating-to-boot9strap

06/04/17

Boot9Strap updated 1.2

Happy Birthay to meee...

04/16/17

@Aurora Wright has added SigHax support to the Latest Release of Luma3ds (7.0)
  • Added unverified New3DS SigHax support (it should work fine, though).

04/11/17
EVERYONE WHO HAS A STOCK 3DS/N3DS/2DS DO NOT UPDATE TO 11.4 since it breaks UDSploit and safehax. Go to 3ds.guide and install arm9loaderhax, which you can then use to upgrade to SigHax once we have prot_boot9.bin Thanks.


04/05/17
Best place to check the progress on dumping prot_boot9.bin is twitch


02/27/17 @d0k3 made the SafeSigHaxInstaller Repository Public Available
DO NOT TRY TO USE THIS. IT WON'T WORK CORRECTLY WITHOUT BOOT9
858ae16b-2b36-49d1-80d1-e463e85c4b0a.jpg
EVERYONE STOP SPAMMING ON HEDGE'S TWITTER AND ASKING ABOUT BOOT9. IT IS DONE WHEN IT IS DONE! ™
02/21/17 @hedgeberg is on it to dump boot9! Yay! #Pray4Greg
C3uja7NWAAABV9o.jpg
Twitter user @hedgeberg seems to be on it to dump boot9
(This does not mean that anyone should spam/shitpost on his Twitter Acc)
Jesus.

No. No. No.
Just...no.

We know, a priori, from derrek & co that their estimate for the time to brute force the sighax signature using 10 CPUs and all the optimizations they could think of was 6 months.

We also know, via calculations on how fast we can do modular exponentiations on PC, this equates to about 2^50 signatures to check, using PERFECT code on PC.

This equates to 300 million years, at your claimed rate of ~10000 signatures/day.

The specifics of why your math is wrong is you're assuming generating the signatures to check takes zero time -- it takes a LOT of exponentiations to generate any signatures that even MIGHT be valid. ~16 bits for the 00 02 prefix, and then way more for the ASN.1 structure, since you're not overflowing the first length tag -- many of those must be valid, too, and we don't know which ones.

So, no, bruteforcing sighax is not possible without the bootroms.

@addi33 - Please update the OP to note that it's not possible, @Selver is wrong.
(Thanks to @SciresM on explaining that bruteforcing sighax is not possible without the bootroms!.)

Q: Did Derrek disclose enough to brute-force SigHAX?
A: Yes, it is extremely likely that SigHAX can be efficiently brute-forced, even without any access to the bootrom.
The RSA signature uses PKCS, including ASN.1 encoding of SHA-256 hash.
The bootrom adds the ASN.1 length field to a current pointer, to "find" the SHA-256 hash.
Code:
// Pseudo-code from derek's slides:
current offset + length = address of beginning of hash
//  X          + L      = Y
//
// Z == address of calculated hash for actual contents
// bool bIsValid = (0 == memcmp(Y, Z, 0x20)
This normally results in an address (pointer) to the SHA-256 hash that's embedded in the ASN.1 encoded signature.
The bootrom also causes a SHA256 hash of the actual contents of the FIRM image being loaded to be generated.
Thus, this SHA256 hash will also be stored in another location in memory.
Because these occur by bootrom (cold boot, same operations, same way, etc.), the operations always use the same memory locations.

Therefore, the following may now be realized, even without bootrom access of any sort:
X == "Current offset", a fixed address that is unknown
Y == "address of beginning of hash", a fixed address that is unknown
Z == "address of dynamically calculated hash", a fixed address that is unknown

The bootrom then performs a 32-byte memory compare of addresses Y and Z to validate the hashes match, indicating valid firmware signature.
Code:
bool bIsValid = (0 == memcmp(Y, Z, 0x20)
L == "Length", an attacker-controlled value that, for real firmware, is a fixed value.
The attack modifies the ASN.1 encoded length (L'), such that X+L'=Y', where Y' == Z.
Thus, if one knows (e.g., via having the bootrom) the values of X and Z, calculation of L' is trivial.
When this value for L' is found, the 32-byte memory comparison to verify the firmware signature becomes:
Code:
bool bIsValid = (0 == memcmp(Y', Z, 0x20);
// which is the same as
// bool bIsValid = (0 == memcmp(Z, Z, 0x20);
Because the above is comparing a memory values to themselves, the comparison will always succeed and indicate a valid firmware signature.
This remains true no matter what the calculated value of Z (from the actual firmware contents) are.
However, because neither X nor Z are known without having the bootrom, one might think every potential value for L' would need to be checked for brute-forcing SigHAX. ASN.1 allows L' to theoretically be up to 127*8 bits of data (2^1016). This would obviously still be cryptographically strong.

But, what if one could reduce the problem space somewhat, and/or use heuristics to greatly speed the search?

Starting point:
L' == 2^(127*8) possible values (impractical)
SHA256 == 2^256 signature values (impractical)
The 3DS pointer size is 4 bytes (32-bit), so values of L' can only have 2^32 unique values (for the sake of computation).
Result:
Maximum search space for L' is 2^32 possible values (still impractical)
The hardware performs the hash on 4-byte aligned memory.
The hash is read from NAND, likely to at least 4-byte aligned memory.
The offset of the hash in the NAND data is also 4-byte aligned.
In other words, both the normal values for Y and Z are 4-byte aligned (lowest two bits zero), and the normal value for L is known.
Therefore, the low two bits needed in L' are known.

Result:
Reduces search space by factor of four.
The bootrom doesn't want to expose the calculated hash value in memory.
Therefore, the calculated hash value will be in tightly-coupled memory, and/or explicitly cleared after use.
3DBrew.org lists a section of memory as "ARM9-only internal memory (ARM7's internal regions are mapped here as well)."
3DBrew.org lists another section of memory as "Data TCM (Mapped during bootrom). Enabled at the time Boot9 jumps to FIRM, however Kernel9+arm9loader disables it."
3DBrew.org lists memory regions that Boot9 sets up as ITCM (128MB) / DTCM (16KB).
3DBrew.org lists memory region cleared on firmload failure (size == 0x3c70 bytes).
It is unlikely that either Y or Z will be on stack, but stack is also small and thus may be included in this search area.
0xFFF00000 0x00004000 ==> Data TCM (Mapped during bootrom). Enabled at the time Boot9 jumps to FIRM, however Kernel9+arm9loader disables it
0xFFF00000 0x00004000 ==> Early in Boot9, "Here the DTCM at 0xfff00000 size 0x4000 is cleared." -- only 16k!
0xFFF00230 0x00001890 ==> Early in Boot9, "This copies the initial DTCM data from the Boot9 data image into boot9, then it clears 0xFFF00230 - 0xFFF01AC0"
0x08000000 0x00100000 ==> ARM9-only internal memory (ARM7's internal regions are mapped here as well) -- 2^20
0x08000030 0x00000010 ==> Early in Boot9, "it then clears 0x08000030 size 0x10." -- shows the ARM9-only internal memory used by Boot9, and suggests allocations start at low addresses.

Result:
Most likely that ARM9-only internal memory is used for both Y and Z, which is only 2^20 possible addresses each.
Thus, L' would have at most 2^21 possible values to cover all combinations of Y and Z being in this memory region.
Memory allocations made close-in-time to each other, on a freshly-initialized system, will tend to have addresses that are similar (small differences).
X+L'=Y'=Z.
X is from an allocation where the NAND sector was read to.
Z is from an allocation used for the hardware hashing of the firmware data.

It's also possible that the allocation for the full FIRM (4MB total) is made between these allocations (small difference + 4MB).

Result:
Highest likelihood of values for L' will be small values (positive or negative), or small values + 4MB (positive or negative).

By applying various heuristics, the search space can be more effectively analyzed. One might even view the likely space as having only about 2^14 possible values that would need to be tested.

According to 3dbrew.org, the signatures are checked within 3 seconds of cold-boot.
A Raspberry Pi powered automation setup could therefore test a value for L' (including writing an updated L', cold-boot, and snooping for indications of successful boot) in approximately 7-8 seconds, allowing testing of over 10,000 values per day, fully automated.

This strongly suggests a single 3DS+RPi setup has a good chance to brute-force a SigHAX value for L' within a couple days.

As you can see, there's definitely enough details to enable brute-forcing of the SigHAX values.[/QUOTE]
(Thanks to @Selver for his fantastic writup on how to Bruteforce SigHax!)

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:

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

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.
(Thanks to @Zan' for his explanations on this!)
 
Last edited by The Catboy,

adrifcastr

Well-Known Member
OP
Member
Joined
Sep 12, 2016
Messages
2,038
Trophies
0
XP
1,947
Country
Germany
So... For the end user, what's the real benefit of this? What will this do that A9LH can't?
You will/can have a completely custom Firmware, that is unpatchable, you can literally really do everything, like some common things like bypassing the 300 titles or 40 dsiware titles, this is just 1 little thing that is possible with that, theres a whole bunch of more almost anything you couldn't do before.
 
Last edited by adrifcastr,

Zan'

2F88744FEED717856386400A44BBA4B9CA62E76A32C715D4F
Member
Joined
Oct 8, 2015
Messages
387
Trophies
0
Age
30
XP
251
Country
I am sorry to tell you, but you're incorrect with half of your post.

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.

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.

Otherwise someone could also get the bootrom in private and publicise a possible signature to sign firms with.

However we're not there yet.
 

RednaxelaNnamtra

Well-Known Member
Member
Joined
Dec 8, 2011
Messages
1,134
Trophies
0
XP
2,658
Country
Germany
You will/can have a completely custom Firmware, that is unpatchable, you can literally really do everything, like some common things like bypassing the 300 titles or 40 dsiware titles, this is just 1 little thing that is possible with that, theres a whole bunch of more almost anything you couldn't do before.
Why would we only able to do it with sighax? We are already loading our own firmware, but only a moment after the arm9loader, and this is only a modified version of the original firmware, because it would be to much work to reverse the complete firmware and rewrite it (we would need to implement everthing the games need to work on arm11, and the complete communication between the arm9 and the arm11).
The only advantages I see are, that we now have more space available for the payload, and that we don't need the otp to install it (so no <3.0 downgrade).
Also it should be possible to dump the otp after sighax got installed, since the otp normaly is locked by the firmware/arm9loader very early in boot.

This is at least my understanding of the situation
 

adrifcastr

Well-Known Member
OP
Member
Joined
Sep 12, 2016
Messages
2,038
Trophies
0
XP
1,947
Country
Germany
Why would we only able to do it with sighax? We are already loading our own firmware, but only a moment after the arm9loader, and this is only a modified version of the original firmware, because it would be to much work to reverse the complete firmware and rewrite it (we would need to implement everthing the games need to work on arm11, and the complete communication between the arm9 and the arm11).
The only advantages I see are, that we now have more space available for the payload, and that we don't need the otp to install it (so no <3.0 downgrade).
Also it should be possible to dump the otp after sighax got installed, since the otp normaly is locked by the firmware/arm9loader very early in boot.

This is at least my understanding of the situation

Because of the Bootroms. With arm9loaderhax you can't read any boot image basically, thats what the bootroms do. If you exploit them to read an unofficial firmware you can do anything you want. ARM9LOADERHAX just launches the arm9loaderhax.bin from your SD Card, thats all it does.
 
  • Like
Reactions: Wizardkoer

RednaxelaNnamtra

Well-Known Member
Member
Joined
Dec 8, 2011
Messages
1,134
Trophies
0
XP
2,658
Country
Germany
Because of the Bootroms. With arm9loaderhax you can't read any boot image basically, thats what the bootroms do. If you exploit them to read an unoficcial firmware you can do anything you want. ARM9LOADERHAX just launches the arm9loaderhax.bin from your SD Card, thats all it does.
I know that, but we are already launching our own code, and we are getting control over the hardware (arm9 and arm11) early in boot (after arm9loader). Because of this we are already able to do everything we want.
This means, with Sighax we would be able to directly load our own code as firmware, instead of placing it as arm9loaderhax.bin on the sd-card.
 
  • Like
Reactions: Mrrraou

Zan'

2F88744FEED717856386400A44BBA4B9CA62E76A32C715D4F
Member
Joined
Oct 8, 2015
Messages
387
Trophies
0
Age
30
XP
251
Country
Because of the Bootroms. With arm9loaderhax you can't read any boot image basically, thats what the bootroms do. If you exploit them to read an unofficial firmware you can do anything you want. ARM9LOADERHAX just launches the arm9loaderhax.bin from your SD Card, thats all it does.
Okay to clear this up.
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.

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 ro 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.

SigHax DOES NOT let you bypass the 300 title limit or any other limits UNLESS your cfw does this. AND technically these patches can also be applied via A9LH. No difference.
 
Last edited by Zan',

adrifcastr

Well-Known Member
OP
Member
Joined
Sep 12, 2016
Messages
2,038
Trophies
0
XP
1,947
Country
Germany
Okay to clear this up.
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.

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 ro 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.

SigHax DOES NOT let you bypass the 300 title limit or any other limits UNLESS your cfw does this. AND technically these patches can also be applied via A9LH. No difference.

mind if I add this to the OP?
 
  • Like
Reactions: CaptainSwag101
Joined
Aug 21, 2016
Messages
3,010
Trophies
2
Age
23
XP
3,875
Country
United States
Hello everyone, I decided to make a thread to Discuss and stay up do date to anything that has to do with SigHax. Right Now this thread seems not needed but I will constantly Update the OP to anything new relatet to SigHax. For know until we get any further Information this will just be a Discussion Thread.

What exactly is SigHax?
SigHax 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. But you will probably need it to install SigHax when it is released.

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.X.

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.

Thanks to @Zan' for Correcting my OP
i know its a bit of a dumbass mive to think about some of this stuff so early but which do you think sounds better, ccfw(completely custom firmware) or fcfw(fully custom firmware) :/
 
General chit-chat
Help Users
  • No one is chatting at the moment.
    KenniesNewName @ KenniesNewName: Heartland, Bread Cranberry Orange, 32 Ounce https://a.co/d/hu6QB8a lul fartland bread