Hacking [REQUEST] A CFW That Can Run 2.1.0

[Skyshadow101]

Never even thought of that :o SysNAND would have locked out the OTP before even running the emunand.
You have to be on sysnand <=2.1

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

 

[Deleted member 381889]

What would be cool and useless to everybody except me, would be an a9lh cfw for booting 2.1...

 

[proflayton123]

No, the sysnand would've locked it out...

Sadly not everyone is experienced to know..

 

[Deleted member 381889]

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

But sysNAND locks the OTP before you boot emuNAND! You can't bypass it like that! Just because the emuNAND is on 2.1 doesn't mean the sysNAND magically forgets that it locked the otp and just lets you stride in, grab it, get in your car and leave.

Sadly not everyone is experienced to know..

RIP

 

[gamesquest1]

basically during the 4.x+ boot sequence the OTP is locked, its not unlocked again until a full reboot so soft-rebooting from 4.x+ into 2.1 emunand means the OTP is still locked out as no full reset happened

 

[Thelostrune]

Get hardmod and develop your own CFW for it lmoa

 

[Skyshadow101]

basically during the 4.x+ boot sequence the OTP is locked, its not unlocked again until a full reboot so soft-rebooting from 4.x+ into 2.1 emunand means the OTP is still locked out as no full reset happened

Oh! I see, since the console is still on 9.2, for say, the Emunand can't extract it since the Sysnand has locked it out?

 

[Urbanshadow]

Try a cart update to break out of 2.1 literally any version over 9.0 and lower than 11.0 will do better than 2.1.

On the CFW topic, it's never gonna work. Let's say you somehow manage to get OTP dumped and a9lh installed with a 2.1 sysnand. You'll wan't to try to boot into it. Well you can't. I'm afraid no CFW has support fot the 2.1 nand offsets. Then you'll want to disable signatures on 2.1 since you are not getting a free pass into hbl. For those two things you'll need a decrypted 2.1 FIRM. Not gonna happen, but let's say you get it decrypted somehow. Once decrypted you should reverse engineer the firm to understand what nand offsets a 2.1 ctrnand has, find how to disable signatures in a firm that low (not really as hard as it looks, really) and then fork a well documented CFW with a9lh support and trick it into booting 2.1 without signatures.

If that doesn't feel like a long thing to do, just after that you'll want to find a way across it to install a title that allows you to hbl that low. Perhaps hbl_launcher will do, but most probably it wont. So even with everything, you could find the work was for "nothing". (In the process you blessed the people with the capacity of booting 2.1 emunands).

 

[gamesquest1]

Oh! I see, since the console is still on 9.2, for say, the Emunand can't extract it since the Sysnand has locked it out?

yep, thats the one, sysnand locks it and throws away the key

 

[moghedien]

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

Basically the way that EmuNAND works is that it uses the SysNAND to boot but then redirects to your EmuNAND partition. So the SysNAND will lock OTP and then start up your EmuNAND. So even if your EmuNAND is 2.1 the OTP will still be locked by the time you get there.
Although it would be nice to be able to boot to the 2.1 EmuNAND just to verify that it's working correctly before you flash it to SysNAND.

 

[Swiftloke]

Mr @Skyshadow101 http://gbatemp.net/threads/why-cant-i-dump-my-otp-from-emunand-and-other-good-a9lh-questions.422212/

 

[Deleted member 381889]

I was just about to ask if someone could make an "a9lh" which prevents the locking of the otp, but then I realised that happens before a9lh loads :/

 

[gamesquest1]

I was just about to ask if someone could make an "a9lh" which prevents the locking of the otp, but then I realised that happens before a9lh loads :/

does it though? afaik the otp locking happens from FIRM, which iirc a9lh hijacks, so idk, maybe it would be possible, but you would need the advice of a actual dev.....then again its kinda not that interesting of a prospect seeing as by that point you must have already downgraded to 2.1 to get your otp the first time, plus i seem to remember they switched to using the 8.1 FIRM to gain more space for payloads or something like that so yeah it would be nothing more than a novelty for silly people who dont keep backups of their otp

 

[Swiftloke]

does it though? afaik the otp locking happens from FIRM, which iirc a9lh hijacks, so idk, maybe it would be possible, but you would need the advice of a actual dev

Mr. @gamesquest1 http://gbatemp.net/threads/why-cant-i-dump-my-otp-from-emunand-and-other-good-a9lh-questions.422212/

 

[Urbanshadow]

Basically the way that EmuNAND works is that it uses the SysNAND to boot but then redirects to your EmuNAND partition. So the SysNAND will lock OTP and then start up your EmuNAND. So even if your EmuNAND is 2.1 the OTP will still be locked by the time you get there.
Although it would be nice to be able to boot to the 2.1 EmuNAND just to verify that it's working correctly before you flash it to SysNAND.

Correct.

Just to add more info: Plailect's guide advises you to downgrade your emunand because it's easier to gain every permission and it doesn't matter if it fails, you can restore it anytime. The thing is 2.1 Native firm will always crash booting from a cfw because: 1) we don't know where in the native firm the nand offsets are to redirect them to sd. 2) we don't know where in the ctrnand the execution entrypoint is. So it can't be effectively booted by a CFW. But if we restore it to sysnand, well, that's another bussiness because the system can decrypt the native firm and vanilla-run the firm "perfectly".

EDIT: I may have a hinch on something that might get you to hbl in 4.1 without CFW. But that would be long to implement and without barely any profit to this scenario.

 

[gamesquest1]

Mr. @gamesquest1 http://gbatemp.net/threads/why-cant-i-dump-my-otp-from-emunand-and-other-good-a9lh-questions.422212/

as much as that kinda answers it for the current a9lh implementations, 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 the 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.....again as i said previously its a kinda pointless en devour and doesn't serve much purpose, i was just wondering from a technical perspective

 

[Jiro2]

What we *actually* need is a CFW that can run everything below 9.2. Not because of the OTP, but because right now, if you have firmware less than 9.x, the process of updating to 9.x is an array of "different firmware and browser requires different versions of rxtools, but this browser only works if you update the non-browser part of the firmware, and also, 5.x doesn't work and you have to use 4.x or 6.x, and if you started out on really low firmware you can't update directly from that...."

If you could run one CFW on everything, the instructions would just be "load the CFW files, use the browser if there is one (if not, use mset), and you can update".

 

[Urbanshadow]

afaik the current a9lh afaik uses the 8.x nativefirm as it gives them the most room for payloads or something

Mind you get source of this?

I can explain a9lh if it's necessary, but stage1 and stage2 payloads are not based in any firm afaik.

 

[gamesquest1]

Mind you get source of this?

I can explain a9lh if it's necessary, but stage1 and stage2 payloads are not based in any firm.

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

 

[moghedien]

Correct.

Just to add more info: Plailect's guide advises you to downgrade your emunand because it's easier to gain every permission and it doesn't matter if it fails, you can restore it anytime. The thing is 2.1 Native firm will always crash booting from a cfw because: 1) we don't know where in the native firm the nand offsets are to redirect them to sd. 2) we don't know where in the ctrnand the execution entrypoint is. So it can't be effectively booted by a CFW. But if we restore it to sysnand, well, that's another bussiness because the system can decrypt the native firm and vanilla-run the firm "perfectly".

Yes, you can restore EmuNAND at any time but you can't really know 100% that it was installed properly until you flash it to SysNAND and then find out the home menu crashes shortly after boot (that's what happened to one of my N3DS, although the new versions of PlaiSysUpdater/OTPHelper probably would have prevented that). And just because current CFW can't boot 2.1 EmuNAND doesn't mean it's not possible, it would just take a ton of work, probably more then it's worth.