Homebrew SigHax Updates and Discussion Thread

[KevinX8]

so essentially the arm7 is clocked to match the exact core of the gba (which is why games could never do anything else like savestates in nintendos version) also its possible as mgba user-11 emulates the gba core which is the same as the nds arm7

No I mean for natively playing ds wifi enabled games and gba, arm 7 emulation is not possible

 

[metroid maniac]

So the 3ds has 3 cpus in it from 3 generations not 2 like the BS on their own hardware page and Wikipedia

If you count the multiple ARM11 cores as different CPUs, then it's four on O3DS or six on N3DS.
If not, well... they all reside on one SoC so I guess you only have a single APU

 

[MarioMasta64]

No I mean for natively playing ds wifi enabled games and gba, arm 7 emulation is not possible

im talking about how the arm7 core of the gba is emulated not the ds as the ds was more powerful

 

[metroid maniac]

The inner mechanisms of the 3DS are an enigma

All the legacy hardware is incredibly useful though, you must admit.

 

[The Catboy]

All the legacy hardware is incredibly useful though, you must admit.

It's something, but seriously makes one wonder just how much they crammed into this poor system.

 

[KevinX8]

im talking about how the arm7 core of the gba is emulated not the ds as the ds was more powerful

No I mean it wouldn't have been necessary to have a real arm 7 chip if the arm 11 chip was located in such a place the arm 9 could treat it like one. The gba arm 7 chip is only running half the speed the ds one is, not much more pwerful

 

[MarioMasta64]

No I mean it wouldn't have been necessary to have a real arm 7 chip if the arm 11 chip was located in such a place the arm 9 could treat it like one. The gba arm 7 chip is only running half the speed the ds one is, not much more pwerful

im talking about how mGBA runs as it runs in userland arm11

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

im talking about how mGBA runs as it runs in userland arm11

anyways goodnight threads i shall return

 

[KevinX8]

It's something, but seriously makes one wonder just how much they crammed into this poor system.

If they only crammed in a n64 chip it would have been perfect XD
@MarioMasta64 yeah it's not really surprising considering how much of an age gap they have heck the 3ds is not so much a potato, the n3ds can emulate nds games meh which shows its not all just smoke and mirrors

 

[MarioMasta64]

If they only crammed in a n64 chip it would have been perfect XD
@MarioMasta64 yeah it's not really surprising considering how much of an age gap they have heck the 3ds is not so much a potato, the n3ds can emulate nds games meh which shows its not all just smoke and mirrors

even twl-loader using k9 / k11 is able to emulate the nds to a very nigh extent so emulation is not much of a problem, its the implementation and recompiling for a new console (and indeed)

 

[smileyhead]

It is useful if you want to install stuff like a custom OS on the 3DS.

Does this mean stuff like custom ROMs on Android?

 

[KevinX8]

Does this mean stuff like custom ROMs on Android?

Yes this is essentially cracking the 3ds open like the raspberry pi. Custom roms can already be done thought so that's not new

Sent from my LG-D855 using Tapatalk

 

[MarioMasta64]

Does this mean stuff like custom ROMs on Android?

sort of, yes. however we only have access to te bootloader meaning the entire system would have to be rebuilt from the bottom up

 

[KevinX8]

even twl-loader using k9 / k11 is able to emulate the nds to a very nigh extent so emulation is not much of a problem, its the implementation and recompiling for a new console (and indeed)

Twl loader is not an emulator... It's a nds loader it literally uses twl nand to work

Sent from my LG-D855 using Tapatalk

 

[MarioMasta64]

Yes this is essentially cracking the 3ds open like the raspberry pi. Custom roms can already be done thought so that's not new

Sent from my LG-D855 using Tapatalk

yet we still cant figure out the media codecs for raspberry pi xD so we use kodi and omxplayer

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

Twl loader is not an emulator... It's a nds loader it literally uses twl nand to work

Sent from my LG-D855 using Tapatalk

i see so its a flashcart on sd card basically... i know there was an emulator for it i dont exactly remember the name... maybe it was 3DeSMumE then?

 

[KevinX8]

yet we still cant figure out the media codecs for raspberry pi xD so we use kodi and omxplayer

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


i see so its a flashcart on sd card basically... i know there was an emulator for it i dont exactly remember the name... maybe it was 3DeSMumE then?

Yeah that's it, runs like shit on o3ds gets you some 20 fps currently on the n3ds, nothing playable yet

Sent from my LG-D855 using Tapatalk

 

[MarioMasta64]

Yeah that's it, runs like shit on o3ds gets you some 20 fps currently on the n3ds, nothing playable yet

Sent from my LG-D855 using Tapatalk

yea ive tried it... imma just stick to r4 till i get this 3ds modded for twl-loader

 

[TheOverseer]

Alright, so, let's talk about Sighax. I'm curious about it, and even more curious after Safehax being released. From what I read, Sighax allows for just about the earliest possible code execution, and is even able to dump the OTP. I read this is because it actually executes before ARM9Kernel.

So, considering all this, I will post my thoughts on a more...everyday device model of how this probably works. Please do not consider this information, I am merely asking the more experienced members of the community if it's correct.

From what I read, the concept (posted earlier in this thread) works by introducing a hacked signature that results in an error in signing where it instead compares against the correct key in memory, granting instant verification.

Considering the bootloader is where this error is contained though, you can probably piece together where and how execution is gained.

I'm guessing the way it works is, in normal systems, you have bootloader stages. The bootrom would load first, of course, and then 1st Stage. 1st is decrypted by the bootloader. At this point is likely when the signing trick is implemented, resulting in a verified signature. This would mean that, theoretically, you would get code execution at the earliest possible point, barring a flawed bootrom design where the bootrom parses files that are not read only and exploitable. (I don't think it does.)

Is it correct that the signed file that is fakesigned is the equivalent to the Stage 1 Bootloader? Which is probably ARM9Loader or something similar? The idea behind this is that there is a chain of trust established in many devices. So the bootrom doesn't verify the home menu, an ARMLoader of some kind would.

So, if this is true, and our code actually replaces ARM9Loader, and not the HomeMenu, wouldn't this A: Allow a setup like BootMii, and B: Still allow for easy upgrading by using Sighax to place a signed ARM9Loader replacement that acts as "BootMii", but also as Firm Protection, allowing it to, just as A9LH does, ignore system calls to write to Native_FIRM, so you could system upgrade as normal? While also allowing (if implemented) ARM9 Binary Launches through the custom ARM9 Loader?

And if all this is possible, couldn't you also continue to allow custom home menus, as the chain of trust is now broken, and signatures related to Home Menus could also be ignored?

Once again, this is just theory, and me trying to understand what you could do.

But, theoretically, if you could replace the first bootloader, as this seems to do, anything is possible. If you could dump ARM9Loader, you could theoretically understand how it calls the next stage 2, and boot normally after Sighax loads, right?

 

[gkoelho]

And if all this is possible, couldn't you also continue to allow custom home menus, as the chain of trust is now broken, and signatures related to Home Menus could also be ignored?

Once again, this is just theory, and me trying to understand what you could do.

But, theoretically, if you could replace the first bootloader, as this seems to do, anything is possible. If you could dump ARM9Loader, you could theoretically understand how it calls the next stage 2, and boot normally after Sighax loads, right?

Yes you could, theoretically, install a custom home menu and many stuff, but that would require a entire new code to be added to the bootloader. Sighax as it is now its just a Signature verification exploit to allow the bootloader to jump to our desired function. The current state doesnt offer a lot much than dumping the bootrom. But this can change quickly after some bootroms are made public and people start working on it(If anyone is going to really).

 

[metroid maniac]

Is it correct that the signed file that is fakesigned is the equivalent to the Stage 1 Bootloader? Which is probably ARM9Loader or something similar? The idea behind this is that there is a chain of trust established in many devices. So the bootrom doesn't verify the home menu, an ARMLoader of some kind would.

There's only really two steps that can really be called a bootloader.
On the O3DS, the bootrom just directly loads the firmware (FIRM/NFIRM/NATIVE_FIRM) and then NFIRM runs parallel to userland software like the home menu until the console is switched off or it firmlaunches into another mode (e.g. TWL_FIRM/AGB_FIRM for backwards compatibility). In this case you essentially have a simple single stage bootloader.
The N3DS made a few changes. Nintendo wanted to block emunands, so they implemented a stronger layer of encryption around NFIRM so that it became impossible to load an NFIRM for a newer firmware version after the console is already done booting. For some reason they weren't able to change the bootrom at all to account for the new layer of encryption, so they basically had to insert arm9loader into the boot sequence in place of NFIRM. The bootrom executes arm9loader blindly, thinking it's just NFIRM. Arm9loader loads the keys for decrypting the real NFIRM from the secret NAND sector using the OTP hash, then disables the OTP permanently until hard reboot and runs NFIRM. Note that arm9loader doesn't care at all if it's running on a N3DS or O3DS, it only needs access to the NAND keys.
So here you have a two stage bootloader, with the bootrom and then arm9loader.

Process9, the component of NFIRM which runs in the ARM9 userland, verifies the signatures of all the titles that are loaded. So this is the component which verifies the home menu along with whatever else you run on the system.

So, if this is true, and our code actually replaces ARM9Loader, and not the HomeMenu, wouldn't this A: Allow a setup like BootMii, and B: Still allow for easy upgrading by using Sighax to place a signed ARM9Loader replacement that acts as "BootMii", but also as Firm Protection, allowing it to, just as A9LH does, ignore system calls to write to Native_FIRM, so you could system upgrade as normal? While also allowing (if implemented) ARM9 Binary Launches through the custom ARM9 Loader?

Both a9lh and sighax allow a setup like Bootmii. You can gain total code execution before the system fully loads. Under a9lh arm9loader is tricked into running your own code instead of NFIRM, and under sighax the bootrom is tricked into running your own code instead of NFIRM/arm9loader. The difference is pretty minimal.
a9lh (and sighax) itself doesn't implement FIRM protection. That's a feature of your CFW, which patches Kernel9 and Process9. Sighax and a9lh would both get installed to the NFIRM partition on your NAND so the same FIRM protection would protect them both.
And your a9lh or sighax installation will likely work the same way, just loading an external arm9 payload from CTRNAND or the SD card so that you don't have to keep dangerously tampering with the NFIRM partition. Although you could embed whatever code you wanted to straight into the hack. Some novel stuff like 3DSafe or ShadowNAND has done that.

And if all this is possible, couldn't you also continue to allow custom home menus, as the chain of trust is now broken, and signatures related to Home Menus could also be ignored?

You could already have custom home menus with a9lh. Heck, you could even do it with earlier hacks like menuhax if you only wanted to have a custom emunand home menu. The system simply doesn't reach the point where it verifies the Home Menu signature before it gets hacked, and signature verification becomes disabled.

But, theoretically, if you could replace the first bootloader, as this seems to do, anything is possible. If you could dump ARM9Loader, you could theoretically understand how it calls the next stage 2, and boot normally after Sighax loads, right?

We already understood how arm9loader executes NFIRM, since this was exploited to enable a9lh. We've also known how NFIRM is launched in general since the very first CFWs were released.

 

[TheMynx]

So, why is Sighax such a big thing? A9LH can do nearly everything Sighax can do. What's the advantage of Sighax over A9LH? I don't understand honestly.