Hacking [WIP] KARL3DS - Kernel access on N3DS via Ninjhax + Loadcode

[Just3DS]

Well, bootrom operates only on hard-boots, so i suppose this has to be an hardware attack in the arm9 ram...
The question is now : have Wulfy successfully exploited it?

It's a discovery, not sure if it has been so far tested/proved to be exploitable.
The problem is that the change is done DURING boot process (bootrom execution), so while it seems like a flaw it is not of much use I think... as when you going to write in RAM you would already be in firmware which means the point is already been pointed to bootrom, so triggering a reboot would not execute from RAM, it would execute bootrom itself. This requires a hardware-based exploit aka. Side-channel Attack

 

[Dazzozo]

Reboots are very silly and broken.

 

[capito27]

Reboots are very silly and broken.

i do have a question for the KARL group, is there any chance that this new bootrom vulnerability could lead to 9.6+ emunand support on N3DS ?

 

[motezazer]

First, I would like to thank WulfyStylez for making public this incredible hax.
Each morning, I actualize the Recent Changes, and then I see this... wow.
From a dev perspective, it's 10000 times more useful than releasing KARL3DS.

To everyone that don't understand this hax, I will try to explain what I understood.
First, there is a special register, called SYSPROT9, that is set-only (once you set a bit, you can't clear it) and that protect bootrom/OTP registers.
The only way to clear it is a hard reboot.
BUT, in a hard reboot, bootroms are launched again, and will re-enable SYSPROT9.
It's a chicken-and-egg loop that can be only broken by exploiting the bootrom.

The hax exploit two hardware vulnerabilities :
The first is that the RAMs/ARM9 memory are NOT cleared at hard reboots (it should).
The second is that the ARM9 bootrom does not immediatly relocate the ARM9 exception vectors to itself. So, for a (very quick) time, the ARM9 exception vectors point to the ARM9 memory... that we control!

The tricky part : the exception vectors are triggered by a fault. So we must inject a fault. It's easy if we have code execution, but we don't have code execution.
So we can't inject a fault with software means. Let's inject it with hardware means!

If the fault is injected within the short time window that is exploitable, the processor will jump to the RAM and execute our code.
It will execute our code BEFORE any bits of SYSPROT9 are set!
Finally, our code has to dump the parts protected by SYSPROT9.

 

[WhoAmI?]

OMG! I hope someone does dump bootrom , even though I don't entirely know what that'll mean for the 3DS HB scene or whatevs. Would making bootrom public, make the console more at risk of providing a *free* means of piracy on later firmware? I dunno. No piracy debates plz.

 

[motezazer]

OMG! I hope someone does dump bootrom , even though I don't entirely know what that'll mean for the 3DS HB scene or whatevs. Would making bootrom public, make the console more at risk of providing a *free* means of piracy on later firmware? I dunno. No piracy debates plz.

It was discovered in February 2014 by derrek, so I do think that bootrom was dumped/all New 3DS only keys were generated.
Yes, this flaw will allow latest emuNAND on New 3DS!

 

[MrJason005]

It was discovered in February 2014 by derrek, so I do think that bootrom was dumped/all New 3DS only keys were generated.
Yes, this flaw will allow latest emuNAND on New 3DS!

Flaw in New 3DS's emuNAND? Huh?
What is going on?

 

[motezazer]

Flaw in New 3DS's emuNAND? Huh?
What is going on?

The bootrom flaw allow one to dump the OTP registers of a New 3DS.
This allow to generate ALL New 3DS only keys (past, present or future).

 

[capito27]

The bootrom flaw allow one to dump the OTP registers of a New 3DS.
This allow to generate ALL New 3DS only keys (past, present or future).

thank god it didn't went public back in 2014, otherwise it whould have been fixed on N3ds

 

[motezazer]

I am so disgusted I can't exploit it myself, as I don't have the hardware to do this...

 

[Idaho]

Ok so once bootrom is dumped we still need to find exploits in it right? And then we could possibly directly flash CFWs or maybe any kind of OS to NAND or maybe even boot from SD? Am I right?

 

[motezazer]

Ok so once bootrom is dumped we still need to find exploits in it right? And then we could possibly directly flash CFWs or maybe any kind of OS to NAND or maybe even boot from SD? Am I right?

No. (There is no exploits in it.)

 

[Idaho]

No. (There is no exploits in it.)

So what's the point? Also I can't believe there's nothing exploitable.

 

[motezazer]

So what's the point? Also I can't believe there's nothing exploitable.

Bootrom is small, and you can't alter its flow. It's normal there is now flaw in it (well, except this one).
The exploit that allow dumping the bootrom and the OTP registers is very useful.
I aleready explained why dumping the OTP registers is good, now I will explain why dumping the bootrom is good : keys, keys, keys, keys...

 

[capito27]

Bootrom is small, and you can't alter its flow. It's normal there is now flaw in it (well, except this one).
The exploit that allow dumping the bootrom and the OTP registers is very useful.
I aleready explained why dumping the OTP registers is good, now I will explain why dumping the bootrom is good : keys, keys, keys, keys...

just wondering, are the OTP keys console specific ? or some are also global ?

 

[motezazer]

just wondering, are the OTP keys console specific ? or some are also global ?

OTP registers are console-unique. It can be used to generate the global New 3DS only keys.
It's surely somehow encrypted/obfuscated and surely contains console-unique keys.
If that's the case, it's the bootrom that decrypts it (another reason to dump the bootrom).

 

[gamesquest1]

just wondering, are the OTP keys console specific ? or some are also global ?

well the rom/save encryption stuff would be the same across all consoles, but there should also be the console specific key, but tbh with this being a hardware hack, its more useful for dumping keys to be re-used, i.e for 9.6 ncch decryption in emunand where the system didn't generate the new keys on bootup as its not actually updated really......long story short, it doesnt mean any new avenues for hacking, except maybe trying to discover a bootrom flaw/exploit, although there my not be any, but it does pretty much cripple nintendo's "ADD MOARR KEYS!" mentality for blocking emunand etc on the n3DS

 

[Idaho]

Bootrom is small, and you can't alter its flow. It's normal there is now flaw in it (well, except this one).
The exploit that allow dumping the bootrom and the OTP registers is very useful.
I aleready explained why dumping the OTP registers is good, now I will explain why dumping the bootrom is good : keys, keys, keys, keys...

Will we ever see a way to directly boot into a CFW or anything similar?

 

[motezazer]

Will we ever see a way to directly boot into a CFW or anything similar?

If someone leaks Nintendo private keys, yes.
But this event has a probability of 0.000000000000000000000000000000000001% to happen.

 

[Idaho]

If someone leaks Nintendo private keys, yes.
But this event has a probability of 0.000000000000000000000000000000000001% to happen.

So our only chance would be to have some haxx to automatically launch itself once the 3DS is totally booted?