Homebrew SigHax Updates and Discussion Thread

  • Thread starter Thread starter adrifcastr
  • Start date Start date
  • Views Views 532,049
  • Replies Replies 3,813
  • Likes Likes 43
Could it be a $salt for a sha256?

i.e. once you obtain the sha256 from the bootrom & run it against the $salt you'll see the 'password' used when making the hash
There is nothing to suggest it's a salt since derrek didn't say he salted his hashes suggesting they are the real deal no '' passwords'' also why would a random member have personal access to derreks hashes? If your interested I ran it through a binary convertor decimal convertor text convertor but nothing of interest so it thosent seem to be a blatant message, maybe just a cryptic one

Sent from my LG-D855 using Tapatalk
 
Also @addi33 your hex number isn't a valid hash type, it's 196 bits and isn't even. This leads me to believe it might actually be the key to something, where did you find if anyway?

Sent from my LG-D855 using Tapatalk
googled "3ds bootrom dumped" and actually thats the same as derrek had on his powerpoint
 
cc104565e72b9b2b71b0cb7202ffd18e.jpg

And here I thought we where onto something, it's just a valid SHA 256 checksum, the member just couldn't fit all of it in his title

Sent from my LG-D855 using Tapatalk
 
So since this is a new thing, can we split this into two avenues?

Like a tutorial for people who want to just get free videogames.

And a tutorial for people who want to turn their 3DS into a palm pilot or whatnot.
You can go ahead and create a thread to show people how to get free games and you'll get your ass banned faster than you can ''happy new year''
 
googled "3ds bootrom dumped" and actually thats the same as derrek had on his powerpoint
Your missing 309C399BF28166F so it is 64characters i.e. sha256

Only mentioned salt as saw a post that 49 seemed to be a salt character limit

*ninja'd - I knew the 49 was a limit of something
 
Last edited by HyperT,
just relealized that my knowledge about the bootroms isnt as high as I had expected.

to everyone else, yes relealized is an existing word.
Also I just relealised the 3ds those have two bootroms, one from each cpu but the arm 11 cpu's bootrom isn't used until after arm 9's is started making it inferior lol

Sent from my LG-D855 using Tapatalk
 
  • Like
Reactions: adrifcastr
Your missing 309C399BF28166F so it is 64characters i.e. sha256

Only mentioned salt as saw a post that 49 seemed to be a salt character limit

*ninja'd - I knew the 49 was a limit of something
Yup me being the leader of the shitpost sending squad I should have known lol

Sent from my LG-D855 using Tapatalk
 
Your missing 309C399BF28166F so it is 64characters i.e. sha256

Only mentioned salt as saw a post that 49 seemed to be a salt character limit

*ninja'd - I knew the 49 was a limit of something
You me being the leader of the shitpost sending squad I should have known lol

Sent from my LG-D855 using Tapatalk
 
The Linux PoC is running natively, not within the 3DS OS. It requires A9LH (or 9.2) to run properly. (There's an experimental memchunkhax2 version that doesn't take over the ARM9, which is probably very unstable.)

The A9LH environment is not running from within the 3DS OS. The original FIRM is needed in order to pass the signature check (though obviously that won't be needed anymore), and then an exploit in arm9loader is used to jump into custom code. While it does technically load FIRM, it isn't used when running an A9LH payload, e.g. Decrypt9WIP and Hourglass9.

Luma3DS reloads FIRM from the CTRNAND partition manually, then applies patches and starts FIRM.

The various A9LH payloads are effectively their own mini OSes. They don't use the 3DS OS at all.

Obviously you'd need to reimplement all of the 3DS system services if you went for a full OS reimplementation. The point is it's *doable* now with A9LH, not that it's easy to do.
Okay I forgot about the possibility of basically jumping to custom code. Either way it's not exactly a full 3DS OS replacement.

The current custom Firmwares are based on patchcode. And they do use the actual 3DS OS but patch sections. I wouldn't call this a new miniOS.
If you weren't using the 3DS OS at all you would have to reimplement the system services as you said.
How can the 3DS "cfws" not use the 3DS OS at all if they are not actually reimplement everything and don't run standalone?
So these 2 sentences don't really go together.

Nothing is impossible, but still.
2F88744FEED717856386400A44BBA4B9CA62E76A32C715D4F is the key
My title is the hash of the bootrom. Not the key.
And it's stripped because the title has a 50 character cap.
So if I wanted to provide the bootrom I would for
1: not have enough space in the title.
2: surely get banned for providing this on here.
 
Last edited by Zan',
Okay I forgot about the possibility of basically jumping to custom code. Either way it's not exactly a full 3DS OS replacement.

The current custom Firmwares are based on patchcode. And they do use the actual 3DS OS but patch sections. I wouldn't call this a new miniOS.
If you weren't using the 3DS OS at all you would have to reimplement the system services as you said.
How can the 3DS "cfws" not use the 3DS OS at all if they are not actually using the 3DS OS?
So these 2 sentences don't really go together.

Nothing is impossible, but still.

People seem to forget this way to much. Right now we only have patchs enabled(which in fact can do almost everything) But is not the same as having custom code from boot. It for sure is a not needed work, but one could make a usage of sighax that is indeed superior to any a9lh.
 
People seem to forget this way to much. Right now we only have patchs enabled(which in fact can do almost everything) But is not the same as having custom code from boot. It for sure is a not needed work, but one could make a usage of sighax that is indeed superior to any a9lh.
Of course patching sections of something given is not the same as providing the whole things.
But it's actually true you could use A9LH to run a different OS from A9LH on boot.
It would just be slower than directly from BootROM.
If you only run the FIRM to get the sig verification and then run a payload into actual custom code. (And no the CFWs are only partial custom code. The launching of titles etc. Is, but the actual "cfw" part is the default 3DS cfw and FIRM with patches applied)
Technically SigHax would not be needed.

From this standpoint all SigHax has over A9LH is the boot speed and that it's possibly safer. (And maybe easier to install)
(It also gives you options to prevent stuff from being locked by Arm9 - i.e. OTP)
Everything else can indeed already be done.
(@GerbilSoft I think I may have misunderstood what you tried to say before)
 
Last edited by Zan',
Of course patching sections of something given is not the same as providing the whole things.
But it's actually true you could use A9LH to run a different OS from A9LH on boot.
It would just be slower than directly from BootROM.
If you only run the FIRM to get the sig verification and then run a payload into actual custom code. (And no the CFWs are only partial custom code. The launching of titles etc. Is, but the actual "cfw" part is the default 3DS cfw and FIRM with patches applied)
Technically SigHax would not be needed.

From this standpoint all SigHax has over A9LH is the boot speed and that it's possibly safer. (And maybe easier to install)
(It also gives you options to prevent stuff from being locked by Arm9 - i.e. OTP)
Everything else can indeed already be done.
(@GerbilSoft I think I may have misunderstood what you tried to say before)
similar to how when with the wii update the bootmii was later added to boot2 (similar to a9lh) rather than boot1 (similar to bootrom)
 
Of course patching sections of something given is not the same as providing the whole things.
But it's actually true you could use A9LH to run a different OS from A9LH on boot.
It would just be slower than directly from BootROM.
If you only run the FIRM to get the sig verification and then run a payload into actual custom code. (And no the CFWs are only partial custom code. The launching of titles etc. Is, but the actual "cfw" part is the default 3DS cfw and FIRM with patches applied)
Technically SigHax would not be needed.

From this standpoint all SigHax has over A9LH is the boot speed and that it's possibly safer. (And maybe easier to install)
(It also gives you options to prevent stuff from being locked by Arm9 - i.e. OTP)
Everything else can indeed already be done.
(@GerbilSoft I think I may have misunderstood what you tried to say before)

And what about the space for code? im curious of a comparasion of al9h vs sighax mostly because I was thinking that sighax could take the space of the sd-less al9h with better features and hell more space than just the firm hashes. Would be nice to see.
 
similar to how when with the wii update the bootmii was later added to boot2 (similar to a9lh) rather than boot1 (similar to bootrom)
Possibly. I honestly never cared for Wii hacking so unless I look that up I will just have to take that as true.

And what about the space for code? im curious of a comparasion of al9h vs sighax mostly because I was thinking that sighax could take the space of the sd-less al9h with better features and hell more space than just the firm hashes. Would be nice to see.
The FIRM payload has a size limit for A9LH, but this can be used to run (If I am not mistaken) basically any size code, from SD.
It is then only limited by 3DS hardware limit.
For SigHax this could probably be written straight to FIRM and be loaded from BootROM instead of the payload in Arm9 which only runs after Arm9 FIRM execution.
So SigHax could be used for a more size SDLess A9LH. However we can already use the NAND chip to store the necessary A9LH stuff (and it doesn't take that much space) to run SDLess A9LH.
The minimum free space (small chip o3ds) is still over 10MB, which we are not even close to using.

Either way SigHax is very unlikely to get to the public until a bootrom is made available (To the Dev's at least).
And the process to get it to dump is extremely precise. (And hard... and unstable)

SigHax also doesn't allow to validly sign the Firm which some people seem to not understand. It's exploiting the signature verification of the bootrom that basically woeks by creating a signature that ends up passing a pointer to the expected result. Making it compare something with itself which always checks out.
Therefore the last 4 Bytes are static for this signature. Everything that needs to be created is the first part of the signature, which has to be set up in a way that the verification doesn't fail early.
Even with access Bootrom it would take a couple of days to forge a workin signature.

P.S.: I also didn't sleep since last year, so if there are major mistakes, please just correct them.
 
Bootrom is independent of arm9 its just bootrom

No, each CPU in the 3DS has a bootrom. What good is a piece of code if it's not executed anywhere?
I think the ARM9 has three of them actually - for CTR, TWL and NTR mode although in the latter two modes it's more often called a BIOS.
 

Site & Scene News

Popular threads in this forum