Homebrew SigHax Updates and Discussion Thread

  • Thread starter Thread starter adrifcastr
  • Start date Start date
  • Views Views 532,224
  • Replies Replies 3,813
  • Likes Likes 43
I wasn't talking about FIRM, and I was more saying the general premise of sighax and fake signing FIRM gives us access to exploit a system no matter what firmware it's on. i.e. hacking 11.4 consoles without arm9 or arm11 kernel via hardmod.
If you use a hardmod you can just replace FIRM directly with a patched version since the FIRM from the FIRM partitions are parsed by boot9. You will not however be able to, let's say, perform a firmlaunch at runtime from a non vulnerable FIRM to load a FIRM that is "signed" with Sighax

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

How do you explain Gateway working perfectly fine on every firmware up to 11.2? There was some kind of change in 11.3 that wrote to firm on opening the home menu.
I think what he meant was that Gateway payload/firmware does not prevent APIs to overwrite the FIRM partitions (which presumably is very bad and very risky while running a9lh)
 
  • Like
Reactions: OrGoN3
Luma patches FIRM to skip the signature checks, the official unmodified FIRM do check for signatures and (from 0.14) are not vulnerable to Sighax.
Boot9 signature checks are only performed at boot9 runtime and not later, therefore unless you can modify elements parsed by boot9 directly (FIRM, NCSD headers...) you will not be able to make use of the Sighax vulnerability in boot9, this means unless you modify the SPI flash, the NAND or run a FIRM through NTR at boot time, you will not be able to use Sighax to exploit consoles on latest firmwares.
You do realize 0.14 is firmware 1.0.0. The only reason 11.4 requires hardmod is that we don't have arm9 kernel access. It has nothing to do with firmware checking signatures.
Obviously you can't just install without hardmod when you don't have an arm9 exploit
 
Last edited by TheCyberQuake,
  • Like
Reactions: OrGoN3
You do realize 0.14 is firmware 1.0.0. The only reason 11.4 requires hardmod is that we don't have arm9 kernel access. It has nothing to do with firmware checking signatures.
Yes, I do realize 0.14 is 1.00 while 0.13 is the factory FIRM, and yes 0.14 FIRM does check for FIRM signatures during firmlaunch and whatnot. You do realize what I am saying is you can't magically expect Sighax to give you said arm9 kernel access (or anything else really) on latest firmware (unless you do replace FIRM with a patched version directly on CTRNAND of course).
 
  • Like
Reactions: OrGoN3
How do you explain Gateway working perfectly fine on every firmware up to 11.2? There was some kind of change in 11.3 that wrote to firm on opening the home menu.

Uh, no, it's that gateway boots an old native firm and home menu updated minimum kernel required version in 11.2...so gw fails to boot new home menu with old native firm. There is no "write to firm on home menu open code" whatsoever.
 
  • Like
Reactions: OrGoN3
Yes, I do realize 0.14 is 1.00 while 0.13 is the factory FIRM, and yes 0.14 FIRM does check for FIRM signatures during firmlaunch and whatnot. You do realize what I am saying is you can't magically expect Sighax to give you said arm9 kernel access (or anything else really) on latest firmware (unless you do replace FIRM with a patched version directly on CTRNAND of course).
I must have misunderstood you.
I don't know why you assumed I ever said it gives us arm9 in latest firmware.
As I stated in my original reply to you:
I was more saying the general premise of sighax and fake signing FIRM gives us access to exploit a system no matter what firmware it's on. i.e. hacking 11.4 consoles without arm9 or arm11 kernel via hardmod.
 
  • Like
Reactions: OrGoN3
To sum things up, in laymans' term "sighax" is about crafting a "signature" which works because of loose padding restrictions in the ASN.1 structure allow for the signature's hash (present in the header) to overlap with the calculated hash stored by boot9 in memory.
 
  • Like
Reactions: OrGoN3 and peteruk
Uh, no, it's that gateway boots an old native firm and home menu updated minimum kernel required version in 11.2...so gw fails to boot new home menu with old native firm. There is no "write to firm on home menu open code" whatsoever.
Why was a9lh lost, and not just failed to boot? People using older versions of Luma and ReiNAND that weren't updated for this requirement just booted to black screens, no loss of a9lh.
 
  • Like
Reactions: OrGoN3
Why was a9lh lost, and not just failed to boot? People using older versions of Luma and ReiNAND that weren't updated for this requirement just booted to black screens, no loss of a9lh.
In addition according to most of these cases the mere act of loading sysNAND with gateway caused the removal of a9lh, not a firmware update.
 
No problem. It happened a while ago, but compatibility is lacking. And for some games to work you need a game with the same chip in your system.

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



That doesn't help at all. My question was how did us, the users on current firmware, install sighax if Ninty implemented a check for it? Or is that check only when the home menu loads up? Another user mentioned it was a different sighax vuln that they were referring to on that slide.
Then can we hope boot9 will add more compatibilities?



Sent from my SM-G9350 using Tapatalk
 
Uh, no, it's that gateway boots an old native firm and home menu updated minimum kernel required version in 11.2...so gw fails to boot new home menu with old native firm. There is no "write to firm on home menu open code" whatsoever.
, yeah afaik 11.3+ do indeed "fix" the firm partition at boot up leading to bricks on a a9lh n3ds or a updated stock system on a o3ds, this is just when booting, not even updating, there was several people who bricked after trying to even load up gw while having a 11.3+ sysnand, not just a failiure to boot, but the system actually ended up being updated or bricked simply for trying to boot 11.3+ Without firm protection in place
 
  • Like
Reactions: peteruk
I have already posted this question on an earlier post by me but only after I've edited it, so that might be the reason why there has been no answer yet because nothing popped up.
So here is my question:
I got 2 N3DSXL consoles. One had A9HL on it which has been updated to B9S (source console) and the other one was stock OFW on 11.4. I successfully got B9S on that system as well by following DSiWare game injection of the guide (target console).
@Plailect Why would I want to redo the system transfer after succeeding in DSiWare games injection) from target console back to source console? This is still unclear to me since I had installed Boot9Strap on the source console, so it is still there, isn't it? Using the source 3DS' microSD card, I can still access Godmode9. So where would be the point for the system to be transferred again? Is it possible to just reconfigure the target console by injecting FBI to H&S and then reinstalling needed cia titles (Luma updater 2, HBL etc.)?
Thanks for answering questions (I can wait a week, so there is no problem. It is just that I want to know why I would have to transfer back because after this transfer, the target console would have to be resetup like the source console would have to be now, right?

The reason one would want to system transfer back is that, after doing the first system transfer, the Source 3DS's NNID has been moved to the target 3DS. You restored the source 3DS from a backup, but Nintendo's servers still see the NNID as on the target 3DS so it is non-functional on the source 3DS. You can transfer back then restore from a backup to make it work once more.
 
  • Like
Reactions: hurrz
The reason one would want to system transfer back is that, after doing the first system transfer, the Source 3DS's NNID has been moved to the target 3DS. You restored the source 3DS from a backup, but Nintendo's servers still see the NNID as on the target 3DS so it is non-functional on the source 3DS. You can transfer back then restore from a backup to make it work once more.

hey plailect, is it normal that luma3ds Reboots the console when you exit System settings?

(im running luma 7.1 boot9strap)
 
I'm so confused right now. Following www.3ds.guide updating to boot9strap and it says secret_sector.bin is only for n3ds but I'm on the installer and it says file not found and stops the installation. Should I put the secret_sector.bin on my 3ds even though its an o3ds? I'm worried that it will mess something up so to confirm I came here
 
I'm so confused right now. Following www.3ds.guide updating to boot9strap and it says secret_sector.bin is only for n3ds but I'm on the installer and it says file not found and stops the installation. Should I put the secret_sector.bin on my 3ds even though its an o3ds? I'm worried that it will mess something up so to confirm I came here
You probably have SafeB9SInstaller v0.0.5. There's an update, v0.0.6, that eliminates the requirement for Old3DS.

It won't hurt anything if you have secret_sector.bin present when installing on an Old3DS, but it isn't needed.
 
  • Like
Reactions: Wind47
Ima just wait until the current A9LH luma doesn't work anymore before I switch. Probably clear up some issues anyway that people may encounter.
 

Site & Scene News

Popular threads in this forum