Hacking [REQUEST] A CFW That Can Run 2.1.0

[Urbanshadow]

no not the payloads, but from what i read they need at least one valid FIRM partition to pass bootup leaving firm0 corrupt to get their payload setup, agian i am nowhere near fully understanding exactly how all that black magic works its just how i had interpreted stuff, i could potentially be way off the mark and full of crap XD

Ok so you are refering to the FIRM1 partition used to garbage-jump into stage1. In that case it wouldn't matter since as the name implies, that partition is decrypted into (useful) garbage. OTP is already locked before a9lh arrives anyway, so it doesn't matter to what config you might change.

What it's possible but not worthy in time and profit is the boot of 2.1 emunands, though.

 

[gamesquest1]

Ok so you are refering to the FIRM1 partition used to garbage-jump into stage1. In that case it wouldn't matter since as the name implies, that partition is decrypted into (useful) garbage. It doesn't matter if it's 8 or 2.1, not a single instruction would make sense. If the 8 one has more room for working, thats cool.

oh yeah i forgot the key store is messed up at that point....so what exactly locks the OPT, wouldnt it be FIRM, in which case if a CFW was made that could boot with the 2.1 FIRM under a9lh would that not mean the OTP is left open afaik the boot sequence was just signature checking then running FIRM seeing as a9lh runs before firm (or atleast it only loads garbage firm at that point) doesn't that then mean that we have jumped in before OTP is locked, or is something else ran before FIRM that locks the OTP

(sorry for all this stuff i like to try get my facts straight, i appreciate your explanations )

 

[Urbanshadow]

oh yeah i forgot the key store is messed up at that point....so what exactly locks the OPT, wouldnt it be FIRM, in which case if a CFW was made that could boot with the 2.1 FIRM under a9lh would that not mean the OTP is left open afaik the boot sequence was just signature checking then running FIRM seeing as a9lh runs before firm (or atleast it only loads garbage firm at that point) doesn't that then mean that we have jumped in before OTP is locked, or is something else ran before FIRM that locks the OTP

(sorry for all this stuff i like to try get my facts straight, i appreciate your explanations )

Don't quote me on this but the one in charge of decryption of the native_firm is the bootrom. Whether the OTP is or not locked before the native_firm execution should be bootrom's business. It may have a firm version check which somehow skips otp lock but no one knows for sure.

You can find advanced info on the crypto system here. (I can remove the link if asked to)

 

[Swiftloke]

No, CFG_SYSPROT9 runs before firm jumping, which to my knowledge means FIRM isn't involved at all.

 

[gamesquest1]

No, CFG_SYSPROT9 runs before firm jumping, which to my knowledge means FIRM isn't involved at all.

ok, so what part of downgrading to 2.1 means this no longer happens? from 3dbrew it would suggest this is done by native_firm itself

NATIVE_FIRM sets CFG_SYSPROT9 bit 1 to disable the OTP area

https://www.3dbrew.org/wiki/CONFIG_Registers

so if theoretically a a9lh cfw was able to boot under the 2.1 firm OTP would be left unlocked

now as other have already said i know this is all kinda pointless i was just hoping to confirm/verify some of my understanding of how a9lh works a bit better now assuming what i just said is true, would a9lh itself be able to patch native_firm so it doesnt set CFG_SYSPROT9 bit 1

 

[Swiftloke]

ok, so what part of downgrading to 2.1 means this no longer happens? from 3dbrew it would suggest this is done by native_firm itself

https://www.3dbrew.org/wiki/CONFIG_Registers

so if theoretically a a9lh cfw was able to boot under the 2.1 firm OTP would be left unlocked

now as other have already said i know this is all kinda pointless i was just hoping to confirm/verify some of my understanding of how a9lh works a bit better now assuming what i just said is true, would a9lh itself be able to patch native_firm so it doesnt set CFG_SYSPROT9 bit 1

Legit idea, patching out firm before a9lh, however it wouldn't work. Remember, before a9lh runs we're still running under signed code, which means any modifications would crash the console. (Excluding, of course, the garbage key store, which is ignored by the console until it's too late, and firm0, which is viewed by the system as potentially normal, and why firm1 exists) Though a9lh allows us to run unsigned code, it does not let us run unsigned code before it runs. Downgrading to 2.1, a firmware which does not lock the OTP, allows us to nab it, as 2.1 is signed and will boot normally. Very good question, I'll add it to my question thread.

 

[gold lightning]

wouldn't using the 2.1 FIRM as FIRM1 leave OTP unlocked (assuming my underrstanding of how a9lh works are correct), afaik the current a9lh afaik uses them 8.x nativefirm as it gives them the most room for payloads or something,but *could* it be possible to make a a9lh payload based around using the 2.1 native_firm as the firm1 meaning the OTP lock would be skipped.....

Among other things (like what has been mentioned), there is one huge issue with this. 2.1 is an O3DS firmware. And as such, it does not even have an arm9loader. Without an arm9loader, a9lh is impossible (obviously). 8.x is used because that is the oldest N3DS firm and it happens to be the smallest for that reason.

Another thing is that you mention doing this magic in FIRM1. I could be wrong, but I'm 99% sure FIRM0 actually pulls off locking the OTP before we get to our payloads. EDIT: I stand corrected. OTP is still locked before we even get to payloads on any FIRM that has an arm9loader though.

And before anyone not quite in the know asks, a9lh works on O3DS because we can (and do) inject a N3DS FIRM without the system throwing a fit (well... before our payloads prevent it from having real reasons to panic, that is).

 

[Swiftloke]

Among other things (like what has been mentioned), there is one huge issue with this. 2.1 is an O3DS firmware. And as such, it does not even have an arm9loader. Without an arm9loader, a9lh is impossible (obviously). 8.x is used because that is the oldest N3DS firm and it happens to be the smallest for that reason.

Another thing is that you mention doing this magic in FIRM1. I could be wrong, but I'm 99% sure FIRM0 actually pulls off locking the OTP before we get to our payloads.

And before anyone not quite in the know asks, a9lh works on O3DS because we can (and do) inject a N3DS FIRM without the system throwing a fit (well... before our payloads prevent it from having real reasons to panic, that is).

Right, because the code is still signed at that point.
As for firm0 locking the OTP, that's impossible, as with a9lh the OTP is still locked. And because a9lh has an unsigned firm0 that doesn't get executed, and firm1 is decrypted to point to our payload, that's impossible. I'm not sure how FIRM runs cfg_sysprot9 when it does.

 

[gamesquest1]

Among other things (like what has been mentioned), there is one huge issue with this. 2.1 is an O3DS firmware. And as such, it does not even have an arm9loader. Without an arm9loader, a9lh is impossible (obviously). 8.x is used because that is the oldest N3DS firm and it happens to be the smallest for that reason.

Another thing is that you mention doing this magic in FIRM1. I could be wrong, but I'm 99% sure FIRM0 actually pulls off locking the OTP before we get to our payloads.

And before anyone not quite in the know asks, a9lh works on O3DS because we can (and do) inject a N3DS FIRM without the system throwing a fit (well... before our payloads prevent it from having real reasons to panic, that is).

makes sense thanks for the explanation guess that clears that up

 

[Ricken]

On 2.1, the OTP isn't blocked. That's why you can extract it.

You aren't doing a full reboot when you launch EmuNAND from hbl, so the OTP is still locked from when SysNAND locked it. Before asking why we don't unlock the OTP when booting a 2.1 EmuNAND, also ask why we haven't done that on 9.2.

 

[Shadowhand]

Having a CFW that is able to run at 2.1 does not help with getting your OTP at all, since the region would probably be locked by the time you got to it (if emunand). At sysnand, you can boot regularly anyway.

 

[chaoskagami]

I'm only going to make this one post here for informational purposes:

Nintendo did a near 100% rewrite of NFIRM around 3.0, which is why there's no way to have CFW on 2.1. None of our RE work and patches are applicable to anything that old, because there's no shared code. There's little to no benefit to redoing RE on something that old, considering nobody should run something that old anyways.

It also wouldn't help with the OTP in the slightest. By the time you get to EmuNAND, you either booted SysNAND (and therefore locked otp) or you're already running a9lh (and therefore, already have the otp.)

 

[Pokéidiot]

Firmlaunch 2.1 FIRM would do but, CFG_SYSPROT9 can't be unset after set on boot. So, if someone get to perform this, OTP dumping would still be impossible.