Hacking Dumping OTP with A9LH

[bobfacemoo]

Okay so I know it's not possible but I got thinking a little, this has probably been suggested already. I lost my OTP (out of plain stupidity). I don't want to uninstall, downgrade, etc. I have shadownand installed as well as Luma but well if anything comes out that needs OTP I can't get it. But my point is, could we possibly downgrade to 2.1 on A9LH (I know it won't boot but we'll have it on system firmware 2.1) and then OTPHelper be made into an Arm9 payload? The OTP won't be locked out so could we dump it like this?

 

[Just3DS]

I think it is possible to downgrade and boot 2.1 firmware without any patches using A9LH but that still requires a sort of seperate AL9H payload that can actually boot it. The thing is that I don't think someone will be that motivated to do for free as it is not much in demand.

PS. It has to boot 2.1 firmware directly so that OTP area access doesn't get disabled.

 

[Sumea]

Does A9LH boot actually lock out OTP? I mean yeah it is based on 8.1 firm I think so probably but if not, there could be just a a9lh bin for redumping your OTP.

as it stands for now; it does not seem you need the OTP much after succesfully installing A9LH since any updates can be made without your OTP so...

 

[gkoelho]

Does A9LH boot actually lock out OTP? I mean yeah it is based on 8.1 firm I think so probably but if not, there could be just a a9lh bin for redumping your OTP.

as it stands for now; it does not seem you need the OTP much after succesfully installing A9LH since any updates can be made without your OTP so...

OTP is locked by the bootloader, which runs way before any code can be executed, so no chance. You need to be on 2.x at max to get your otp again, no other way.

 

[Goombi]

Allow me to try a comprehensive explanation of why that won't work.

The boot sequence is: Power on > Bootrom (> ARM9Loader, New3DS only) > NATIVE_FIRM.
OTP is locked by setting the CFG_SYSPROT9 bit (which can only be unset by a hardware reboot). Once this bit is set, reading the OTP will give you zeroes.
On O3DS, this bit is set at the beggining of the ARM9 binary in the NATIVE_FIRM. <2.1 NATIVE_FIRM are not setting the CFG_SYSPROT9 bit.
On N3DS, it is set by the ARM9 Loader, which is a normal firm viewed from the bootrom (only doing some checks before decrypting and giving code execution to the real firmware). It always sets the CFG_SYSPROT9 bit.

A9LH is exploiting bad checks in the ARM9 Loader (= only exists for >8.1 firms). But too bad, it is triggered AFTER the CFG_SYSPROT9 bit is set. We have the same problem as with the suggestions of 2.1 emuNAND, once locked, that's over. Loading a 2.1 FIRM from A9LH serves no purpose (and will certainly won't work without many changes).

What Sumea said is very true: for now (who knows in the future), OTP is only used for *FIRST INSTALL* A9LH and only work for the console it was dumped from. You might want be sure you want to get that OTP, it has no use for A9LH'd consoles today.

 

[thisisallowed]

Allow me to try a comprehensive explanation of why that won't work.

The boot sequence is: Power on > Bootrom (> ARM9Loader, New3DS only) > NATIVE_FIRM.
OTP is locked by setting the CFG_SYSPROT9 bit (which can only be unset by a hardware reboot). Once this bit is set, reading the OTP will give you zeroes.
On O3DS, this bit is set at the beggining of the ARM9 binary in the NATIVE_FIRM. <2.1 NATIVE_FIRM are not setting the CFG_SYSPROT9 bit.
On N3DS, it is set by the ARM9 Loader, which is a normal firm viewed from the bootrom (only doing some checks before decrypting and giving code execution to the real firmware). It always sets the CFG_SYSPROT9 bit.

A9LH is exploiting bad checks in the ARM9 Loader (= only exists for >8.1 firms). But too bad, it is triggered AFTER the CFG_SYSPROT9 bit is set. We have the same problem as with the suggestions of 2.1 emuNAND, once locked, that's over. Loading a 2.1 FIRM from A9LH serves no purpose (and will certainly won't work without many changes).

What Sumea said is very true: for now (who knows in the future), OTP is only used for *FIRST INSTALL* A9LH and only work for the console it was dumped from. You might want be sure you want to get that OTP, it has no use for A9LH'd consoles today.

The old firms did set the CFG_SYSPROT9 bit, but only for the ARM9 bootloader.

 

[Swiftloke]

Totally not shameless advertising, but an explanation as why this is impossible can be found here: http://gbatemp.net/threads/why-cant-i-dump-my-otp-from-emunand-and-other-good-a9lh-questions.422212/

 

[Inochi.no.Zenmai]

Ihave a few questions about this

One of the 3DS on my sig is missing the OTP. I bought it already hacked.

1. Isn't it possible to just downgrade the console to 2.1, getting the OTP, then flashing a NAND backup of 11.0?

2. Assuming it is not possible because Luma 3DS doesn't launch older sysNAND firmwares, I read recently Luma got the possibility to boot older firmwares (but I think only >5.0). So, support for 2.x could be added? People who missed their OTP could downgrade and get it anytime, then flash a backup again to the latest firmware with Hourglass9/Decrypt9

3. If Luma can't do it, maybe another CFW specifically designed for this could work?

I know OTP is no use for someone with A9LH already installed, but we might want to have this available for the ones who doesn't have the file. We don't what could come later that needs the OTP.

 

[TheCyberQuake]

Totally Not Shameless Advertisingtm

Fixed xD

 

[GothicIII]

You can use safea9lhinstaller to uninstall a9lh and restore a nand-backup from 2.1/downgrade again to get otp. After you dumped it you can restore your current nand backup with a9lh.

 

[Goombi]

I have a pure theorical question. Uninstalling A9LH simply restore FIRM partitions right? But it does not changes other titles. So could updated sysNAND result in a franken firmware with NVer and CVer showing "Ver. 11.0.0-33E" but still have an exploitable firm?

 

[SomeGamer]

I have a pure theorical question. Uninstalling A9LH simply restore FIRM partitions right? But it does not changes other titles. So could updated sysNAND result in a franken firmware with NVer and CVer showing "Ver. 11.0.0-33E" but still have an exploitable firm?

Wouldn't cryptofixing still be needed if that was the case?

 

[gkoelho]

I have a pure theorical question. Uninstalling A9LH simply restore FIRM partitions right? But it does not changes other titles. So could updated sysNAND result in a franken firmware with NVer and CVer showing "Ver. 11.0.0-33E" but still have an exploitable firm?

I may be worng, but I do believe process9 will check for Native_Firm in that case, which will result on something less than 11.0.