Hacking 'Why can't I dump my OTP from emuNAND?' And other good a9lh questions

[Swiftloke]

Arm9LoaderHax is the ultimate 3DS Hax. With it, you get instant full system control, even before the kernel loads, so you can do almost anything you want. This is even more powerful than a kernel exploit as most system protections haven't been loaded yet.
However, it's extremely complicated, especially the setup process. That's why I'm creating this Q&A thread to answer a few common questions about this exploit.

Q: Why can't I dump my OTP on firmware >2.1?
A: In versions 1.0 to 2.2, Nintendo decided to keep the OTP area locked by the kernel, presumably under the assumption that hackers would never get kernel control. When 3.0 was being developed, someone on the security team wised up* and realized that hackers would, eventually, get kernel control. That employee's answer was CFG_SYSPROT9.

Q: What's CFG_SYSPROT9?
A: CFG_SYSPROT9 is a configuration register that runs immediately after boot. In versions 1.0 to 2.2, it was only used to lock the arm9 bootrom. However, in versions 3.0 and beyond, it's also used to lock the OTP. We can't just unlock the OTP region, as this config can't be set again while the console is running.

Q: Why can't I use arm9loaderhax to get my OTP if I lose it?
A: Though arm9loader runs immediately after boot, it, unfortunately, runs RIGHT AFTER CFG_SYSPROT9. Therefore, we just missed the cutoff.

Q: Say, why not use version 2.2?
A: It's not exploitable using any known kernel exploit.

Q: Wait, so what kernel exploit did we use on 2.1?
A: It's called 2xrsa, and if anyone would give me some info on it I would appreciate it. No, 3dbrew didn't help.

Q: How do we dump the OTP on 2.1?
A: Because Nintendo kept the OTP region locked via the arm9 kernel by taking over the kernel with the kernel exploit 2xrsa, we can dump the OTP.

Q: How does arm9loaderhax work?
A: Black magic.**

Q: Why can't I dump my OTP from emuNAND?
A: This is a very good question. So the OTP region is locked by CFG_SYSPROT9 right? So why wouldn't downgrading emuNAND to 2.1 work? Here's why: While we boot emuNAND, emuNAND doesn't lock the OTP region. Right? Right. But it doesn't need to, because by the time we got code execution and booted emuNAND, the OTP was already locked by sysNAND. So why not just dump the emuNAND's OTP? Think about that for a minute.***

*Apparently for the only time ever.
**Go watch the 32c3 conference. It's really out of my league to explain anyway.
***If we dumped the OTP along with the rest of emuNAND, we could just extract it from the emuNAND file. Furthermore, if we could dump the OTP for emuNAND, we could just dump it period and skip the whole process.

Anyway, I hope this answered a few questions about arm9loaderhax.
*Insert closing here*
Thanks to @Asia81, @ScarletKohaku & @SomeGamer for some cleanup!
(Requesting a mod to correct the space in the 'this' in the poll and move the thread to the tutorial question.)

 

[Scarlet]

Nice idea, but try to format it a little nicer. Maybe making the questions bold, or putting some white space in. Just things that make it easier to read and less a wall of text.

 

[Swiftloke]

Nice idea, but try to format it a little nicer. Maybe making the questions bold, or putting some white space in. Just things that make it easier to read and less a wall of text.

Done. Thanks!

 

[BloodRose]

Because of you I now want to see the 32c3 presentation

It's here BTW if anybody is interested: https://events.ccc.de/congress/2015/Fahrplan/events/7240.html

 

[Vappy]

I'm 98% sure the exploit used is "PS RSA commands buffer overflows" listed below here http://3dbrew.org/wiki/3DS_System_Flaws#Process9 (I've lost my IRC logs from when b1l1s was talking about it, so 2% doubt. ) The "2x" part of the name just refers to the exploit working for 2.x FIRM, which there was no public implementation for prior to b1l1s writing this.

 

[SomeGamer]

-snip-

Now that's why I voted for the third option.

 

[Asia81]

Edited...

 

[Swiftloke]

Now that's why I voted for the third option.

Arm9LoaderHax is the ultimate 3DS Hax. With it, you get instant kernel control, even before the kernel loads, so you can do almost anything you want.
However, it's extremely complicated, especially the setup process. That's why I'm creating this Q&A thread to answer a few common questions about this exploit.

Q: Why can't I dump my OTP on firmware >2.1?
A: In versions 1.0 to 2.2, Nintendo decided to keep the OTP area locked by the kernel, presumably under the assumption that hackers would never get kernel control. When 3.0 was being developed, someone on the security team wised up* and realized that hackers would, eventually, get kernel control. That employee's answer was CFG_SYSPROT9.

Q: What's CFG_SYSPROT9?
A: CFG_SYSPROT9 is a configuration register that runs immediately after boot. In versions 1.0 to 2.2, it was only used to lock the arm9 bootrom. However, in versions 3.0 and beyond, it's also used to lock the OTP. We can't just unlock the OTP region, as this config can't be set again while the console is running.

Q: Why can't I use arm9loaderhax to get my OTP if I lose it?
A: Though arm9loader runs immediately after boot, it, unfortunately, runs RIGHT AFTER CFG_SYSPROT9. Therefore, we just missed the cutoff.

Q: Say, why not use version 2.2?
A: It's not exploitable using any known kernel exploit.

Q: Wait, so what kernel exploit did we use on 2.1?
A: It's called 2xrsa, and if anyone would give me some info on it I would appreciate it. No, 3dbrew didn't help.

Q: How do we dump the OTP on 2.1?
A: Because Nintendo kept the OTP region locked via the kernel [which one? 11 or 9? I'm not sure] by taking over the kernel with the kernel exploit 2xrsa, we can dump the OTP.

Q: How does arm9loaderhax work?
A: Black magic.**

Q: Why can't I dump my OTP from emuNAND?
A: This is a very good question. So the OTP region is locked by CFG_SYSPROT9 right? So why wouldn't downgrading emuNAND to 2.1 work? Here's why: While we boot emuNAND, emuNAND doesn't lock the OTP region. Right? Right. But it doesn't need to, because by the time we got code execution and booted emuNAND, the OTP was already locked by sysNAND. So why not just dump the emuNAND's OTP? Think about that for a minute.***

*Apparently for the only time ever.
**Go watch the 32c3 conference. It's really out of my league to explain anyway.
***If we dumped the OTP along with the rest of emuNAND, we could just extract it from the emuNAND file. Furthermore, if we could dump the OTP for emuNAND, we could just dump it period and skip the whole process.

Anyway, I hope this answered a few questions about arm9loaderhax.
*Insert closing here*

--------------------- MERGED ---------------------------

Better.
Quote me and copy the BB code, then edit your first post

Appreciated @SomeGamer and applied @Asia81. Now if you could snip that post it would be nice.
Also @Asia81 I managed to get that screenshot up.

 

[frosty5689]

I would change the title to something most people seem to be asking about "A9LH vs. Menuhax?" and have a section dedicated explaining pros/cons. I haven't see anyone ask why they can't dump OTP from EmuNAND 2.1 yet...

 

[Temarile]

Nice! Thanks!

 

[Swiftloke]

Nice! Thanks!

Like, comment, subscribe! Wait, that's not right.

 

[Temarile]

Like, comment, subscribe! Wait, that's not right.

Haha
Maybe you can add some stuff about updated sysnand mode and having Emunand or not. And perhaps pros/cons (if there are any ) because a lot of topics with those questions get opened every day.

 

[Urbanshadow]

Q: Why can't I dump my OTP from emuNAND?
A: This is a very good question. So the OTP region is locked by CFG_SYSPROT9 right? So why wouldn't downgrading emuNAND to 2.1 work? Here's why: While we boot emuNAND, emuNAND doesn't lock the OTP region. Right? Right. But it doesn't need to, because by the time we got code execution and booted emuNAND, the OTP was already locked by sysNAND. So why not just dump the emuNAND's OTP? Think about that for a minute.***

***If we dumped the OTP along with the rest of emuNAND, we could just extract it from the emuNAND file. Furthermore, if we could dump the OTP for emuNAND, we could just dump it period and skip the whole process.

Sorry to burst the bubble, but if OTP was dumpable without unlocking or inside the nand itself we won't make you guys risk your sysnand's in a 2.1 downgrade. Specially N3DS.

As you said, by the time a9lh arrives otp is locked. No matter what your emunand version is. Sysnand's CFG_SYSPROT9 already locked it. The only way to affect CFG_SYSPROT9 to avoid it locking OTP is by a downgrade of the sysnand's firm, because we don't have code execution before CFG_SYSPROT9 but we are lucky enough to have a CFG_SYSPROT9 version that won't lock OTP.

Sadly, that low firm requires a low version of pretty much every title. Hence the full system downgrade.

There's also a way to unlock the OTP in versions over 2.1 with some bruteforcing in the system, but only for N3DS.

I happen to know how a9lh works so ask me if you need anything.

 

[RealityNinja]

There's also a way to unlock the OTP in versions over 2.1 with some bruteforcing in the system, but only for N3DS.

Indeed, there is a way to know the hash of the otp with the new 3ds... but you have to bruteforce the otp to know it, in order to install a9lh...
Bruteforce a 256 bytes password...
So, what is the fastest? A secure downgrade using emunand (ok, that's right, with about 102 titles to downgrade) or bruteforcing it?

 

[Urbanshadow]

Indeed, there is a way to know the hash of the otp with the new 3ds... but you have to bruteforce the otp to know it, in order to install a9lh...
Bruteforce a 256 bytes password...
So, what is the fastest? A secure downgrade using emunand (ok, that's right, with about 102 titles to downgrade) or bruteforcing it?

Given the unbelievable unability of some users to follow a guide step by step and actually understanding what are they doing, everything beyond "Press B to get bacon" is dangerous.

So, speed is actually beaten by realiability. And right now the a9lh installation is as reliable as it gets with the current methods.

 

[Swiftloke]

Given the unbelievable unability of some users to follow a guide step by step and actually understanding what are they doing, everything beyond "Press B to get bacon" is dangerous.

So, speed is actually beaten by realiability. And right now the a9lh installation is as reliable as it gets with the current methods.

Speaking of which...
http://gbatemp.net/threads/i-bricked-my-3ds.422181/

 

[RealityNinja]

Speaking of which...
http://gbatemp.net/threads/i-bricked-my-3ds.422181/

But what is the fastest between a bruteforce and a hardmod? XD
Edit: He had used a bad otp.bin; with a new 3DS, this would *never* have happened...

 

[Zan']

About the A9LH for OTP dumping.
From what I've gathered it would be possible with a specific setup.
So your Information woulf be correct if the System is above 3.0 having an according FIRM. Otherwise it's not.

So where exactly is the cutoff for OTP dumping?
OTP doesn't get locked by the Bootrom, but by the Arm9. We have access to the Arm9. So we can keep thinking about it.
WHEN is the OTP locked and WHAT is locking it.
Alright the easy answer would be "CFG_SYSPROT9 locks it before A9LH execution. Case closed"
But I want to go into this further.
Downgrading the System we introduce the OTP vulnerabilitx again.
How? By writing a old FIRM.
When does A9LH get executed? Well after the FIRM code is run... sadly.
You could say "Alright, easy. We just run A9LH before FIRM". This however isn't possible as of now and likely won't be unless we get access to the Bootrom.
BUT we know the OTP locking is FIRM specific. And we do have access to writing there. It won't be as easy as simply doing modifications due to validations. If it was A9LH would look different.
But using a VALID FIRM to do so would be possible.
Therefore:
Injecting 2.1 FIRM into a A9LH setup would give you the possibility to "Dump OTP through A9LH"
(Keep in mind cfw can't run 2.1 because of FIRM patches. So you will likely be unable to boot further into Homemenu with a 2.1 FIRM.
This is just so you could have a program creating a FIRM backup. Inject a valid 2.1 FIRM and restart. Then Dump OTP from Arm9 Payload and then reinject the FIRM backup and restart again.
Basically "dumping OTP" via A9LH)

 

[Swiftloke]

Tfw @raulpica likes your post