Homebrew SigHax Updates and Discussion Thread

[proflayton123]

sorry i meant safe firm and i have bricked the recovery partion several times on my phone but always fix it by reflashing the recovery

It may be similar concept but not the same process

 

[tunip3]

its the end part i confuse

--------------------- MERGED ---------------------------

It may be similar concept but not the same process

i know

--------------------- MERGED ---------------------------

its the end part i confuse

--------------------- MERGED ---------------------------


i know

Never meant to mean that it isn't easily update-able, just that they might not do it. Otherwise, it would have been updated long ago to patch the bugs Native FIRM had, such as firmlaunch-hax. And I doubt Nintendo devs are stupid enough to forget about updating SAFE firm to fix bugs Native FIRM had. Also my point about SAFE firm being a fallback and by updating it, its exposed to bricking is still valid.

if you remove the power while updating on wiiu you brick

 

[gamesquest1]

I'm sure they could have just had a 2 stage update, update normal firm, reboot, and the new native firm will check if safe firm is already updated, if not it updates safe firm, that way your never left without a functional firm partition

they probably just overlooked the issue trying to rush out the band aid fix

 

[Selver]

Spoiler: My previous thoughts

Well, I guess most of the post is accurate, except for a few bits in the final brute-forcing section.

Maybe I'll writeup a replacement for that one section sometime. I'll just post some raw thoughts, which are not guaranteed to be correct....

• cannot choose target ASN.1 data ahead of time with only pubkey; must search random data that (after exponentiation) happens to result in the desired ASN.1 data
• normally, because hash embedded in the ASN.1 data is validated to match target, this is cryptographically sound
• boot9 doesn't modify most ARM9 nor ITCM (based on known bug that doesn't clear RAM on boot, filling with predefined pattern, checking after (presumably A9LH) boot -- based on SciresM comments)
• The location of Z is very likely 0x1000A040 (SHA_HASH register)
• The location of X is in the 16k starting at 0xFFF00000 (DTCM)
• RSA signature is aligned on 16-byte boundary (heuristic) ... only 1024 possible target values remain

S == FIRM header's signature
E,N == RSA public key
S^E mod N == the resulting ASN.1 structure

What matters is getting the pointer / offset value to overflow and point to the SHA_HASH register at 0x1000A040.
FIRM_HEADER is stored at address 0x01FFBB00 (3dbrew.org, check who added this info)?
(Hash would normally be at 0x01FFBC00)?
So... want to have ASN.1 data that meets the following criteria?

Define the final offset as the offset of the length field, for the field that boot9 would identify as the hash, plus that field's own length value.
(33c3 @ xx:xx, Derrek indicated first thing boot9 does is parse the hash...)
The final offset may need to be equal to 0x0E00E440 (0x01FFCB00 + 0x0E00E440 == 0x1000A040).

Thus, would need to check the above for random values R, after doing R^E mod N...
Nasty stuff. Computationally intense, even with optimized maths. Boot9 pseudo-code would help reduce false positive rates. Actual Boot9 addresses used might eliminate false positives?

6 months using 10 cores... that's amazingly good!

@SciresM, would like your thoughts on an intermediate step, for those without Boot9 access yet...


Per my previous thoughts (quoted above), one needs essentially random data (FIRM header's signature, after exp/mod) to be "sufficiently" valid ASN.1 to cause the overflow in offset to cause the memcmp() operation to use the same pointer. Current efforts are stymied from lack of Boot9, to validate the expected results "on paper".

Stepping back, perhaps abuse multiple flaws to gets a "SigHAX minor", in order to get Boot9 access?

Here's more random thoughts:

GIVEN:
You already have a replacement FIRM compiled and ready to load, that will dump Boot9, and know the hash it would generate during validation by Boot9 (but obviously not the right signature to use)

THEN:
1. For existing FIRM header, do exp/mod to get example of "REAL" ASN.1
2. Based on 33c3 presentation, "first thing [boot9] tries to do is parse the padding" ... aka find the hash
3. Rather than attempting to find a signature that becomes sufficiently valid ASN.1 AND points specifically to the SHA register....
4. Find a signature that is sufficiently valid ASN.1 and points anywhere that Boot9 can access (preferably 4-byte aligned)
5. Determine the final offset of that signature's ASN.1 data, modulo 64
6. Determine the final offset of real firm's ASN.1 data, modulo 64 (known)
7. This tells you the delta offset (modulo 64) for how to align things in the next step....

PROCESS:
0. Boot 3DS normally, get full control of ARM9
1. Write the replacement FIRM that will dump Boot9
2. fill all memory with the SHA256 of that replacement FIRM
3. Reboot -- Note the system bug that fails to clear memory on boot!
4. Boot9 loads FIRM header, parses signature, gets a pointer to "random" memory location...
5. From step #1, that random memory location now contains your controlled SHA256 hash, not the SHA256 from the header (which cannot be controlled)
6. Signature check passes
7. your replacement FIRM loads, before Boot9 access is disabled, and Boot9 code is dumped
NOTE: repeat up to 64 times, offsetting step 2 by one byte each time, if don't trust the ASN.1 offset steps. May as well, given the relative difficulty...

VALUE:
Some may not have Boot9 dumped yet.
Above reduces the search space for a signature, from a single allowable value, to a MUCH larger subset of allowed values.
Although it takes two boots (and maybe a hardmod, and preferably using hardmod to change FIRM back and forth),
it appears this should provide access to Boot9 at a much lower search cost than the full SigHAX, without needing to use timing-sensitive and unreliable glitching

Thus, giving greater Boot9 exposure, which would unblock the ability to search / validate
(on paper) the full SigHAX value.


Thoughts?

 

[Deleted User]

My thoughts on this are:Will we need to uninstall a9lh in order to install sighax,or will we be able to keep both.

 

[metroid maniac]

My thoughts on this are:Will we need to uninstall a9lh in order to install sighax,or will we be able to keep both.

Yes. Both are installed to the FIRM partitions.

 

[TimX24968B]

Yes. Both are installed to the FIRM partitions.

which question did you say yes to?

 

[metroid maniac]

which question did you say yes to?

Will we need to uninstall a9lh in order to install sighax

 

[zoogie]

I would assume you would simply just overwrite the a9lh installation on firm0 with sighax + cfw firm. Then probably do the same on firm1 for the sake of redundancy.

 

[The Catboy]

My thoughts on this are:Will we need to uninstall a9lh in order to install sighax,or will we be able to keep both.

Chances are we will have to remove A9LH and honestly once sighax is installed, there's no reason to keep A9LH. It's basically the same as when A9LH replaced MenuHAX.

 

[metroid maniac]

I would assume you would simply just overwrite the a9lh installation on firm0 with sighax + cfw firm. Then probably do the same on firm1 for the sake of redundancy.

IMO it makes more sense to leave a clean FIRM in FIRM1 for safety.

Chances are we will have to remove A9LH and honestly once sighax is installed, there's no reason to keep A9LH. It's basically the same as when A9LH replaced MenuHAX.

I doubt there'll be a significant difference between a9lh or sighax. They'll only differ in ease of installation and have no other reason to switch between them.

 

[SciresM]

Thoughts?

-We do not know which ASN.1 length field to overflow. Thus this is, again, pointless.

-Boot9 cannot be dumped via sighax (only boot11 can).

 

[The Catboy]

IMO it makes more sense to leave a clean FIRM in FIRM1 for safety.



I doubt there'll be a significant difference between a9lh or sighax. They'll only differ in ease of installation and have no other reason to switch between them.

Let me rephrase that. Once you have sighax installed there's no reason for 2 different booting methods to be on the same system.

 

[Deleted User]

Chances are we will have to remove A9LH and honestly once sighax is installed, there's no reason to keep A9LH. It's basically the same as when A9LH replaced MenuHAX.

That's how I figured it would be.Then all your unlegit cia's won't show up until you get sighax installed after the a9lh uninstall.

 

[Selver]

-We do not know which ASN.1 length field to overflow. Thus this is, again, pointless.
-Boot9 cannot be dumped via sighax (only boot11 can).

Thank you once again, SciresM. Even though I am saddened that my ideas are dead-ends, it saves me lots of time.

 

[Platinum Lucario]

I have a question. Since sighax is quite similar to installation as arm9loaderhax, won't we need an entry point for those who don't have sighax installed? I know Nintendo won't be able to patch sighax (due to the instructions being hardcoded to the CPU), but won't they be able to patch the entry points into installing the exploit (like what they did with fasthax)?

 

[zoogie]

I have a question. Since sighax is quite similar to installation as arm9loaderhax, won't we need an entry point for those who don't have sighax installed? I know Nintendo won't be able to patch sighax (due to the instructions being hardcoded to the CPU), but won't they be able to patch the entry points into installing the exploit (like what they did with fasthax)?

Yeah they could certainly block entry points, but what's really hard to get is nand write access. Even k11 doesn't have access to that. DSiware does, however, and that's probably what they'll try to block or mitigate next.

 

[the assaf]

Yeah they could certainly block entry points, but what's really hard to get is nand write access. Even k11 doesn't have access to that. DSiware does, however, and that's probably what they'll try to block or mitigate next.

Wasn't they blocked dsiware hand access in 11.3?

 

[Platinum Lucario]

Wasn't they blocked dsiware hand access in 11.3?

They patched dsiwarehax, and because it's patched, it prevents earlier Home Menu versions than NATIVE_FIRM version from booting.

 

[adrifcastr]

Yeah they could certainly block entry points, but what's really hard to get is nand write access. Even k11 doesn't have access to that. DSiware does, however, and that's probably what they'll try to block or mitigate next.

yeah but k9 has. and the rumors to an arm11 khexploit are around, so basically we just need that and then safefirmlaunchhax to get arm9 access