https://github.com/yellows8/firm_payload_bootstrap
there you go, somebody did it. according to yls8 not a lot of initialization is needed, if any at all
Last edited by Wolfvak,
Homebrew SigHax Updates and Discussion Thread
- Thread starter adrifcastr
- Start date
- Views 470,078
- Replies 3,813
- Likes 43
there you go, somebody did it. according to yls8 not a lot of initialization is needed, if any at all
Sighax is an exploit in the signature check of the bootrom, so the the bootrom thinks its properly signed. I know its not realy properly signed, but its enougth for the bootrom to load it.
We do not even have one implementation of sighax, so its true, nobody has gone this route yet.
Also it will still be a bit faster, because instead of loading 2 firm partitions, and decrypting one arm9binary and jump after some garbage code to our payload loaded when the bootrom read the firm0 Partition, we will simply load 1 firm partiton, where the arm9binary will be our armloaderhax binary loader.
this loader could then do, what the arm9loader does normaly, but without the encryption of the arm9 firm binary.
plus, i heard that the a9lh firm payload has a size restriction of the largest firm binary. Maybe that can change with this Sighax and new payload options could become available.
The stage1 a9lh payload is pretty tiny, like 2KB big. I think the max size for that payload is pretty tiny since it has to be smaller than the difference between FIRM0 and FIRM1, something like 5KB.
The stage2 payload is substantially larger at about 10KB. I believe this payload is installed to the slack space in one of the FIRM partitions. 3dsafe is the only example I've seen of a novel usage of this payload.
So what's the status it's released or what cause I see a lot of people fighting over which is the master race cfw and only one guy say we even have one yet to use with sighax
Sent from my LG-D855 using Tapatalk
Sent from my LG-D855 using Tapatalk
All people who do have access to SigHax did the work in private and individually.
(Unless they were give the necessary things by someone, who did the work)
It is not simply not publicly released (except some tools, that are unusable on it's own).
People just like to come up with ideas, even though they have no clue how it works and don't plan to do any work to get to this point.
- Joined
- Nov 14, 2016
- Messages
- 124
- Trophies
- 0
- Age
- 23
- Location
- Littleroot Town
- Website
- www.pokemon.com
- XP
- 101
- Country
Addi33, please consider the following updates:
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.
This normally results in an address (pointer) to the SHA-256 hash that's embedded in the ASN.1 encoded signature.
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)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.
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:
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.
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);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)
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)
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 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.
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.
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.
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).
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.
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.
Last edited by Selver,
Fantastic writeup. What sort of hardware do you need to start bruteforcing this then, just a NAND-modded console hooked up to an RPi? I sure hope the details of this post are enough to catch the attention of some curious devs.
Found this browsing pastebin: http://pastebin.com/EJHk9ceU not sure if it helps anyone but seems cool never the less.
- Joined
- Jan 11, 2016
- Messages
- 6,032
- Trophies
- 1
- Age
- 24
- Location
- 日本
- Website
- www.facebook.com
- XP
- 3,214
- Country
Thank you, metroid maniac.
The hardware for brute-forcing this is rather simple, at least for those with basic electrical engineering or computer engineering background, maybe for more hardware-focused computer science also. One example setup:
1. A 3DS console, with hardmod for NAND (at least CLK, DAT0, and CMD) and I2C extension port
2. Raspberry Pi or other micro-controller
Basic concept:
- The I2C port is used to reboot the console
- The I2C port is also used to snoop on 3DS I2C traffic, allowing detection of a successful boot vs. failed boot
- The NAND CLK/DAT0/CMD links to the microcontroller must be transparent (or disconnected) during boot
- When the boot is determined to have failed verification (based on I2C traffic), then:
- Switch the CLK/DAT0/CMD pins to RPi control
- Use the CLK/DAT0/CMD pins to manually send write command to the NAND, with updated L' in the ASN.1 signature.
- Switch the CLK/DAT0/CMD pins back to RPi control
- Reboot the console (branch to step 1)
- Else, boot will have appeared to succeed, so investigate if repeatable with same values.
Does this make sense?
--------------------- MERGED ---------------------------
Well, it depends what was hashed. But, YES, if it was actually valid, then this could be used to bypass the attempts to boot on the physical 3DS, and just muck with the header until a matching hash was found. Hashing corrupted sectors (corrupted in manner to find SigHAX value) is much less work than actually hooking up to a console and having it boot each one.
The question is... what differentiates this from a random value someone posted as a prank? Has anyone reputable claimed this as a correct hash of a SigHAX?
The person the hash is from was asked for a hash of the Signature.
It is apparently hashed with an unknown salt and therefore it's pretty much useless.
The explanation to do this was what you said here:
Last edited by Zan',
I don't think anyone who would have sighax would also be so inept when it comes to sharing a hash as proof.
I think someone would if it was in the context of people talking about bruteforcing a valid signature within 2 days.
Sharing a hash is more than enough to make all steps to verify if the generated signature is valid unnecessary, because you can replace it with hashing whatever you generated and simply checking against the given hash. Generating, hashing and checking if 2 hashes are equal can be done in less than a second.
If he calculates with 7 seconds for each Signature he could the go with - let's say the least possible - 1 second for each. (More likely to be 100+ hashes per second)
It makes a HUGE difference.
Why do you think noone has shared a hash to the public, or a signature, or a bootROM even though we know multiple people who do have it.
Nothing else was done. Shared something useless instead of sharing nothing.
It was not meant for the public and was just to kind of troll by insufficiently fulfilling a unspecific request.
Sharing a hash is more than enough to make all steps to verify if the generated signature is valid unnecessary, because you can replace it with hashing whatever you generated and simply checking against the given hash. Generating, hashing and checking if 2 hashes are equal can be done in less than a second.
If he calculates with 7 seconds for each Signature he could the go with - let's say the least possible - 1 second for each. (More likely to be 100+ hashes per second)
It makes a HUGE difference.
Why do you think noone has shared a hash to the public, or a signature, or a bootROM even though we know multiple people who do have it.
Nothing else was done. Shared something useless instead of sharing nothing.
It was not meant for the public and was just to kind of troll by insufficiently fulfilling a unspecific request.
Last edited by Zan',
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.
Last edited by SciresM,
damn SciresM in my thread. But anyways, thank you for clearing this up, i have updated the OP.
Similar threads
