Homebrew [RELEASE] OTPHelper - OTP dumping & downgrade helper

[d0k3]

Oh I'm sure it did. I've been using the old guide with CN and manually doing everything and wanted to give this new guide and OTP a try.

I'm just confused about the firm part. I downgraded to 9.2 (checked with downgraderchecker) and had no missing titles/extra/mismatched. Used emuNAND9 to create an emuNAND. Booted into that emuNAND and ran TinyFormat to unlink it. Booted to emuNAND again, did a system update to bring emuNAND from 9.2 to 10.7.

Then kept following the guide. Just not sure where FIRM0 mismatch came from, waiting on the IRC to see any responses. Should I just update sysNAND and downgrade again?

Try #3dshacks on https://www.rizon.net/ - these guys know more about the whole process than I do. And check Plailects guide for the update (it is in there now), he describes what you have to do in there.

EDIT, you're already on IRC, sorry. Well, checkout Plailects guide now. And I think you have to run tinyFormat twice (unsure, though).

 

[Krude]

Got my hands on a fresh N3DS on 9.9.0 today, immediately went to downgrade to 9.2. This was the first time i got a partial downgrade (got the gray "please power off the 3DS" error after just a couple installed CIAs) and it took me about 80 restarts to get the memchunkhax2 exploit running after that again.
Hours later, the downgrade to 9.2 finished without problems on the second attempt and i immediately set up (emuNAND9) and downgraded emuNAND to 2.1. Then used the "one click setup" in OTP Helper v0.81.

Of note here is that i have a "dedicated" SD card for getting OTP and setting up A9LH (this was the 4th 3DS i set up A9LH on), and the EmuNAND on it was formatted for large size (1888MB) with a different emuNAND still on it, while the N3DS in question had a 1280MB chip. Cloning sysNAND into it (via E9) without reformatting worked fine, downgrading to 2.1 worked fine, and the One Click Setup reported all validation stages as Cleared on all steps (before and after unbricking and after cloning to sys).

Even with the messy, interrupted 9.9->9.2 downgrade, all stage validations checked out.

 

[Deleted User]

Try #3dshacks on https://www.rizon.net/ - these guys know more about the whole process than I do. And check Plailects guide for the update (it is in there now), he describes what you have to do in there.

EDIT, you're already on IRC, sorry. Well, checkout Plailects guide now. And I think you have to run tinyFormat twice (unsure, though).

Yea, that's why I mentioned it earlier someone had wanted me to run Tinyformat again.

In any case, I injected the Firm.bin for 2.1 into emuNAND. However doing the NAND validation options after still said failed.
Though if I try OCS now, it has SUCCESS on all validation stages 107/107.

 

[d0k3]

Yea, that's why I mentioned it earlier someone had wanted me to run Tinyformat again.

In any case, I injected the Firm.bin for 2.1 into emuNAND. However doing the NAND validation options after still said failed.
Though if I try OCS now, it has SUCCESS on all validation stages 107/107.

Downgrade validation actually includes NAND validation, so if Downgrade validation passes, NAND validation does, too. Show me your log!

 

[Deleted User]

Downgrade validation actually includes NAND validation, so if Downgrade validation passes, NAND validation does, too. Show me your log!

Whoops attached to wrong thread -.-

You selected "EmuNAND FIRM0 Inject".
This feature writes to the EmuNAND.
Doing this is potentially dangerous!

If you wish to proceed, enter:
<Left>, <Right>, <Down>, <Up>, <A>

(B to return, START to reboot)

Using EmuNAND @ 26C000/000000
Encrypting & Injecting FIRM, size (MB): 4
Use arrow keys and <A> to choose a file
firm.bin
Opening firm.bin ...
EmuNAND FIRM0 Inject: succeeded!

Press B to return, START to reboot.

You selected "EmuNAND FIRM1 Inject".
This feature writes to the EmuNAND.
Doing this is potentially dangerous!

If you wish to proceed, enter:
<Left>, <Right>, <Down>, <Up>, <A>

(B to return, START to reboot)

Using EmuNAND @ 26C000/000000
Encrypting & Injecting FIRM, size (MB): 4
Use arrow keys and <A> to choose a file
firm.bin
Opening firm.bin ...
EmuNAND FIRM1 Inject: succeeded!

Press B to return, START to reboot.

Using EmuNAND @ 26C000/000000
NAND is not downgraded or still bricked
Validate EmuNAND Downgrade: failed!

Press B to return, START to reboot.

 

[d0k3]

Whoops attached to wrong thread -.-

Just try OCS again, should be fine.

 

[Deleted User]

Just try OCS again, should be fine.

Yea that's what I mentioned, I ran OCS after the failure notificaiton, but everything looked good on OCS with SUCCESS on validations. It's just in the process of unbricking. I haven't heard anything on IRC, but what would cause the FIRM0 failure? (botched downgrade?) Sorry so many questions, just trying to get a grasp and learn.

 

[d0k3]

Yea that's what I mentioned, I ran OCS after the failure notificaiton, but everything looked good on OCS with SUCCESS on validations. It's just in the process of unbricking. I haven't heard anything on IRC, but what would cause the FIRM0 failure? (botched downgrade?) Sorry so many questions, just trying to get a grasp and learn.

This is a problem with the downgrade, causing FIRM not to or only partially to be written. You're most likely not at fault for this, at the moment, we have no idea what causes it, and it is rare. OTPHelper can detect it though, as see, and fixing it is not that difficult.

 

[Deleted-369620]

Could one of you guys tell me what I did wrong? Do I need to inject the FIRM.bin in emunand and resume one clic setup?

 

[Deleted User]

Thanks for the info. I've done 6 A9LH/OTP's using the old guide where using the individual dumps using the padgens and manually moving the header into the bricked emuNAND. Glad OTP caught that

In any case, OCS went fine and now on 2.1 and got the OTP. Thanks so much!

 

[d0k3]

Could one of you guys tell me what I did wrong? Do I need to inject the FIRM.bin in emunand and resume one clic setup?

This looks completely broken. Better start fresh from your downgraded EmuNAND. And maybe use another SD card or at least format this one and start from scratch?

 

[Deleted-369620]

This looks completely broken. Better start fresh from your downgraded EmuNAND. And maybe use another SD card or at least format this one and start from scratch?

already tried that 2 time always greeted with that same message, i'll try a third SD card
EDIT: Is the original 4gb enough space?

 

[d0k3]

already tried that 2 time always greeted with that same message, i'll try a third SD card
EDIT: Is the original 4gb enough space?

If the original 4GB one is enough depends on your3DS NAND size, chances are it is not.

Anyways, you say you tried it with at least two different SD cards by now? And what happens everytime is, you run OCS, the first downgrade validation passes, the unbricker does its work, the second downgrade validation fails miserably (tbh, I've never seen it fail that bad). My best bet is on a faulty SD card reader / writer in your 3DS console. There were rare cases in the past where such faulty SD card readers temporarily lost access to the SD card, which looks to be excactly what is happening for you. For other people, this could be solved by using another SD card, but you already tried two different ones.

Have you solved it now? Know that, with faulty hardware (if my assumption is correct) you are at a bigger risk than others but you can still try try running the steps manually (= no OCS): auto-unbrick, then validate downgrade (if it fails, reboot, restart OTPHelper), clone EmuNAND to SysNAND, validate downgrade on SysNAND (if it fails restore a 9.x backup).

 

[Deleted-369620]

If the original 4GB one is enough depends on your3DS NAND size, chances are it is not.

Anyways, you say you tried it with at least two different SD cards by now? And what happens everytime is, you run OCS, the first downgrade validation passes, the unbricker does its work, the second downgrade validation fails miserably (tbh, I've never seen it fail that bad). My best bet is on a faulty SD card reader / writer in your 3DS console. There were rare cases in the past where such faulty SD card readers temporarily lost access to the SD card, which looks to be excactly what is happening for you. For other people, this could be solved by using another SD card, but you already tried two different ones.

Have you solved it now? Know that, with faulty hardware (if my assumption is correct) you are at a bigger risk than others but you can still try try running the steps manually (= no OCS): auto-unbrick, then validate downgrade (if it fails, reboot, restart OTPHelper), clone EmuNAND to SysNAND, validate downgrade on SysNAND (if it fails restore a 9.x backup).

Haven't solved it yet but will try some more, btw do you mean work here? "(if it fails, reboot, restart OTPHelper)"

 

[d0k3]

Haven't solved it yet but will try some more, btw do you mean work here? "(if it fails, reboot, restart OTPHelper)"

No, I meant if it fails. At this point only your EmuNAND is affected, so this is no trouble. My assumption is that the SD card reader went on strike at this point, so a reboot might solve it. I also assume that this only happens with large write operations (such as the auto unbricker). Instead of rebooting, you could also try [SELECT] to temporarily unmount your SD card and restart / remount it again.

One other thing to try is to check the SD card (on PC, via chkdsk) after failure.

 

[Deleted-369620]

No, I meant if it fails. At this point only your EmuNAND is affected, so this is no trouble. My assumption is that the SD card reader went on strike at this point, so a reboot might solve it. I also assume that this only happens with large write operations (such as the auto unbricker). Instead of rebooting, you could also try [SELECT] to temporarily unmount your SD card and restart / remount it again.

One other thing to try is to check the SD card (on PC, via chkdsk) after failure.

Ok i'll check the disk but why does it always fail at the same point?

 

[d0k3]

Ok i'll check the disk but why does it always fail at the same point?

It fails after the unbricking feature, which is a large write operation. I assume this is the reason. There are no other write operations (to the SD card) in the process after this, so there is hope you can still finish it.

 

[Deleted-369620]

It fails after the unbricking feature, which is a large write operation. I assume this is the reason. There are no other write operations (to the SD card) in the process after this, so there is hope you can still finish it.

The verification succeeded when I unblocked it on my computer, all the validation stage's say success can I now flash it to the NAND?

 

[d0k3]

The verification succeeded when I unblocked it on my computer, all the validation stage's say success can I now flash it to the NAND?

Yup, but be extra careful, alright? You do have faulty hardware there. Clone EmuNAND -> SysNAND, then manually validate the downgrade on SysNAND. If it says it is okay you can reboot.

 

[Deleted-369620]

Yup, but be extra careful, alright? You do have faulty hardware there. Clone EmuNAND -> SysNAND, then manually validate the downgrade on SysNAND. If it says it is okay you can reboot.

otherwise I put my sysnand backup back on the sd and restore?