Full Guide Release!

https://plailect.github.io/OTP/

All regions now supported!

If you appreciate this guide and the work I put into maintaining it, I accept donations through both Bitcoin and PayPal.

If you felt like the guide helped you out then I'd really appreciate it! If I get enough I may buy a 2DS for testing hardware stuff so I don't break another N3DS.

If the guide didn't help you out then I'm really sorry about that

 

[Ekaitz]

Still afraid to try that guide. It's clear and seems to work well but editing the nand backup is not something I like very much lol.
I'll do the first steps and I will see if I flash it to sysnand a day or another.

 

[dkabot]

Still afraid to try that guide. It's clear and seems to work well but editing the nand backup is not something I like very much lol.
I'll do the first steps and I will see if I flash it to sysnand a day or another.

It's not really "editing" the contents of the NAND backup in the usual way.
It's just switching the encryption to what 2.1 uses, so that it can actually be booted.

 

[Ekaitz]

Yes, I understood that thanks to the "abstract" section of the guide but you know, we do not have any way to check if everything went ok and I'm afraid of flashing something that will be corrupted/bricked so for the moment, I'm still avoiding the flash. I'll probably do it anyway a day.

 

[hunter2008]

I have fallow this tut on sysnand 9.0 and I have generate the otp.bin (256byte) is that yet the correct otp.bin for Arm9loaderhax or must i Do this with sysnand 9.2?

 

[FR0ZN]

I have fallow this tut on sysnand 9.0 and I have generate the otp.bin (256byte) is that yet the correct otp.bin for Arm9loaderhax or must i Do this with sysnand 9.2?

All good ... only 1.0.0 - 2.1.0 decides if you get your OTP or not, everything else not important.

 

[hunter2008]

All good ... only 1.0.0 - 2.1.0 decides if you get your OTP or not, everything else not important.

Thanks for fast answer

 

[Agent Moose]

I successfully downgraded to 2.1 from 9.2 on O3DS and got my OTP after hours of work. It took awhile, but it will be worth it once more stuff comes out of arm8loaderhax.

 

[TR_mahmutpek]

I successfully downgraded to 2.1 from 9.2 on O3DS and got my OTP after hours of work. It took awhile, but it will be worth it once more stuff comes out of arm8loaderhax.

arm8loaderhax?!?! İts too EPİC lol

 

[Agent Moose]

heh, woooops I think everyone knows what I mean

 

[kedest]

Still in doubt about all this. Downgrading is somewhat scary. Is the OTP really really tightly locked down in 2.1+? As in: we can be absolutely sure to never be able to extract it under a higher firmware, or is it perhaps theoretically possible that a new exploit will be found some day?

 

[FenrirWolf]

It's quite improbable that a new way would be discovered. Not even A9LH itself runs early enough to prevent the OTP from being locked down on systems updated beyond 2.1.

 

[Jarmenti]

I just did both my new3ds's (no hardmods) without a hitch!.. thanks for the guide. It's just tedious w/ all the nand backups and restores, but way worth it IMO.

 

[DogParty]

I just generated the xorpads and made back ups of my NANDs but I didn't move the cia's to the /Updates/ folder. I can't imagine how those files are used in generating/backing up the xorpads/NANDs but I thought I'd ask if I really need to go back and redo everything before continuing. Lord knows step 1 takes awhile. Thanks!

 

[Classicgamer]

I just generated the xorpads and made back ups of my NANDs but I didn't move the cia's to the /Updates/ folder. I can't imagine how those files are used in generating/backing up the xorpads/NANDs but I thought I'd ask if I really need to go back and redo everything before continuing. Lord knows step 1 takes awhile. Thanks!

If you can't see why it matters you shouldn't be doing this. Follow the guide if you don't want to brick.

 

[dkabot]

I just generated the xorpads and made back ups of my NANDs but I didn't move the cia's to the /Updates/ folder. I can't imagine how those files are used in generating/backing up the xorpads/NANDs but I thought I'd ask if I really need to go back and redo everything before continuing. Lord knows step 1 takes awhile. Thanks!

The updates folder is used for sysupdater later when you downgrade the EmuNAND to 2.1.
As for why it's in step I, who knows

 

[DogParty]

If you can't see why it matters you shouldn't be doing this. Follow the guide if you don't want to brick.

Thanks for your condescending response, it's truly helpful. eye_roll.gif

The updates folder is used for sysupdater later when you downgrade the EmuNAND to 2.1.
As for why it's in step I, who knows

That's what I figured, thanks! I'm gonna wait for another confirmation (or for all of my SD files to back up before potentially regenerating the files again) before proceeding.

 

[Classicgamer]

Thanks for your condescending response, it's truly helpful. eye_roll.gif

Idk...you're given a guide to help you...why not follow it? When the health of your system depends on it why not go step by step?

 

[Plailect]

It's quite improbable that a new way would be discovered. Not even A9LH itself runs early enough to prevent the OTP from being locked down on systems updated beyond 2.1.

Read the abdtract, there is a 9.6 method but it requu

Still in doubt about all this. Downgrading is somewhat scary. Is the OTP really really tightly locked down in 2.1+? As in: we can be absolutely sure to never be able to extract it under a higher firmware, or is it perhaps theoretically possible that a new exploit will be found some day?

Read the abstract, there is a 9.6 method but it requires soldering to the i2c and a hardmod.

 

[piratesephiroth]

I think the guide could be improved. I don't see a reason for deleting all the files in the SD, for example.
It should only be advised in bold text that the user should delete a previous "updates" folder, because it would cause bricks and failed downgrades.

Also it would be nice to dump the FIRM0 and FIRM1 partition from your original emuNAND and then dump again from your downgraded emuNAND, to make sure they're different and you got it right.

 

[Selver]

One Time Programmable. It's the unique thing of your console. It should contain things like your console unique keys. However, it's encrypted with a key we don't know. It's decrypted by the bootROM.

Out of curiosity, are you (the inclusive "all you who have investigated this" you) actually sure that the bootrom decrypts this data, or is it simply a theory, or ????.

Spoiler: Minimum BootROM capabilities

It appears that the BootROM does the following:

1. Validate signature of sector 0 (partition tables, etc.)
2. Load Firm0 partition into fixed memory space
3. Validate signature of loaded Firm0
4. If validated
   1. Setup exception handlers (could occur anytime prior to Firm0 launch)
   2. Branch to Firm0
5. Repeat once, but for Firm1 instead of Firm0

This minimum requires the bootrom to be able to validate the signature of (a) sector 0 and (b) firmware partition. The same key may be used for both, to reduce bootrom size requirements?

Has anyone determined the size of the bootrom and.or locked-out memory regions?