On 2.1, the OTP isn't blocked. That's why you can extract it.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.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
No, the sysnand would've locked it out...
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.On 2.1, the OTP isn't blocked. That's why you can extract it.
RIPSadly not everyone is experienced to know..
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?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
yep, thats the one, sysnand locks it and throws away the keyOh! 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?
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.On 2.1, the OTP isn't blocked. That's why you can extract it.
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 otpI 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 :/
Mr. @gamesquest1 http://gbatemp.net/threads/why-cant-i-dump-my-otp-from-emunand-and-other-good-a9lh-questions.422212/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
Correct.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.
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
Mind you get source of this?afaik the current a9lh afaik uses the 8.x nativefirm as it gives them the most room for payloads or something
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 XDMind you get source of this?
I can explain a9lh if it's necessary, but stage1 and stage2 payloads are not based in any firm.
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.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".