Note: This was patched on 11.4.
Great, you all have gotten yourpiracy A9LH on 11.2. Peter's dreams have come true as well So now the question is, how did you take over the arm9 processor with that "safehax" thing you downloaded?
All right, enough of this stupid disclaimer crap. Let's get to the good stuff.
Note: I highly recommend you check out my 11.0 downgrading thread to understand the 3DS' security system and my glossary of 3DS hacking terms to understand the terminology in this post before reading this.
The 9.2 arm9 exploit (firmlaunchhax)
Yes, this is important! To understand the 11.2 arm9 exploit we have to understand this one first since *spoilers* they're directly related.
Firmlaunching
(Before we get any further, I'd like to link this post which is where I got the info for firmlaunchhax from. Go give it a read after this post, it's a lot more in depth)
The 3DS can "soft reset" to changes modes. Good examples of this are launching extended memory mode or TWL_FIRM. This is accomplished by doing a "firmlaunch". Let's look at how it works.
-arm11 tells arm9 that it wants to perform a firmlaunch.
-arm9 tells arm11 to sit in an idle loop until it tells it what to do.
-arm9 resets. It begins to read out the FIRM header, which contains among other things the memory addresses both processors will jump to. arm9 begins to verify it.
-The verification passes.
-arm9 gives arm11 the memory address to jump to. arm11 begins executing code there.
-arm9 jumps to the specified memory address and begins executing code there.(!)
-Both processors continue to do whatever it was they were supposed to do.
The flaw
Wondering what that (!) was from earlier? That's what's wrong with the code.
What if the arm11 didn't wait for the arm9 to finish its tasks? What if, instead, it overwrote the memory address arm9 would use to somewhere we control? What if I stopped pretending this was theoretical?
What we do is patch the code that arm11 will jump to after the reset. (This is why we need arm11 kernel) Instead of waiting for arm9 to tell it what to do in an idle loop, arm11 instead waits for arm9 to verify the FIRM header, then overwrite the code address arm9 will jump to to code we control. (This is known as a Time of Check to Time of Use (ToCtToU)) Let's see what happens with firmlaunchhax.
-With arm11 kernel control, we copy a payload for arm9 to jump to later to memory.
-arm11 tells arm9 that it wants to perform a firmlaunch.
-arm9 tells arm11 to sit in an idle loop until it tells it what to do.
-arm11 does not sit in an idle loop. It instead waits for arm9 to finish verification of the FIRM header.
-arm9 resets. It begins to read out the FIRM header and begins to verify it.
-The verification passes.
-arm11 overwrites the memory address arm9 will jump to.
-arm9 gives arm11 the memory address to jump to. arm11 doesn't care.
-arm9 jumps to the our code.(!)
-Profit.
The vulnerable SAFE_FIRM (safehax)
So the 9.2 arm9 exploit is all well and good, but what's it got to do with 11.2? Firmlaunchhax was patched on version 9.5**.
SAFE_FIRM
This is the FIRM used for recovery mode. When you hold a button combo at boot, you can launch recovery mode in case something fucks up. In theory.
Anyway, the point is: it hasn't been updated since version 3.0!*** That means that every exploit that was patched after 3.0 still works under SAFE_FIRM: including firmlaunchhax!
Irony
First, something I didn't mention earlier because it didn't matter. During a normal firmlaunch, arm9 will check arm11 for a bit to see if everything is working right. This didn't matter earlier because once the firmlaunch was done we had control.
Let's take a look at the safehax takeover procedure:
-From arm11 kernel, we tell arm9 we want to do a firmlaunch. This is done to launch SAFE_FIRM- remember, firmlaunching is done to change modes!
-The normal firmlaunch procedure occurs, except we tell arm11 to disobey the idle loop instructions and instead carry on our code execution.
-arm9 checks arm11 to make sure everything is running OK. We pretend like everything is fine, and it eventually stops checking.
-We've got arm11 kernel control in SAFE_FIRM.
-The normal firmlaunchhax procedure occurs.
-Profit.
11.3 usage
On 11.3, this was in theory patched. A flag introduced on 11.3 is set unless the current title has a special ID (this is speculated to be a repair cartridge of some sort) or home menu. If this flag is set and the currently running app attempts to launch SAFE_FIRM, the console promptly crashes. This would in theory prevent safehax from being executed, as we can no longer launch SAFE_FIRM to take it over.
In theory. ;D
In practice, the value is also set shortly after a firmlaunch, but not immediately. Thus, we can gain control of arm11 kernel, perform the steps necessary to firmlaunch with control kept, then firmlaunch again into SAFE_FIRM. The flag isn't set, it works fine, and we profit.
This was fixed on 11.4 by having Process9 set the flag instead. Thus, much like downgrading, to bypass this we'd need to take over arm9, and there's no point in bothering by then.
Conclusion
I hope this helped you in your understanding of the 11.2 arm9 exploit. If there's anything that's missing or you don't understand, let me know
I'm so bad at conclusions I'm sorry
Also, thanks to TiniVi, the person who implemented Safehax, for proofreading this post and correcting several major errors I made.
*This is done so that it doesn't just jump to memory arm11 could mess with and potentially control arm9 with code it put there.
**The reason we used to downgrade to 9.2 is because it was memchunkhax (the 9.2 arm11 kernel exploit) that was patched on 9.3, and devs never updated firmlaunchhax to be able to use memchunkhax2, the arm11 kernel exploit that worked until 10.3 (a modified version, memchunkhax2.1 AKA "svchax" worked until 10.7)
***Technically on N3DS it was updated at version 8.1, but 8.1 was the first N3DS firm so my point still stands.
Great, you all have gotten your
I am not responsible for anything bad that comes out of you reading this thread. If, by gaining this knowledge, your 3DS breaks, you go insane, your hair randomly bursts into flames, or you cause thermonuclear war, and you point at me, I will laugh at you. That being said, if you appreciate this thread, or something good came out of it, leave me a like.
If you do not understand any particular part of this thread, I am doing something wrong. The intent here is for anybody to be able to understand the following material. If there is something you do not understand, please let me know and I will correct it.
Note: I highly recommend you check out my 11.0 downgrading thread to understand the 3DS' security system and my glossary of 3DS hacking terms to understand the terminology in this post before reading this.
The 9.2 arm9 exploit (firmlaunchhax)
Yes, this is important! To understand the 11.2 arm9 exploit we have to understand this one first since *spoilers* they're directly related.
Firmlaunching
(Before we get any further, I'd like to link this post which is where I got the info for firmlaunchhax from. Go give it a read after this post, it's a lot more in depth)
The 3DS can "soft reset" to changes modes. Good examples of this are launching extended memory mode or TWL_FIRM. This is accomplished by doing a "firmlaunch". Let's look at how it works.
-arm11 tells arm9 that it wants to perform a firmlaunch.
-arm9 tells arm11 to sit in an idle loop until it tells it what to do.
-arm9 resets. It begins to read out the FIRM header, which contains among other things the memory addresses both processors will jump to. arm9 begins to verify it.
-The verification passes.
-arm9 gives arm11 the memory address to jump to. arm11 begins executing code there.
-arm9 jumps to the specified memory address and begins executing code there.(!)
-Both processors continue to do whatever it was they were supposed to do.
The flaw
Wondering what that (!) was from earlier? That's what's wrong with the code.
What if the arm11 didn't wait for the arm9 to finish its tasks? What if, instead, it overwrote the memory address arm9 would use to somewhere we control? What if I stopped pretending this was theoretical?
What we do is patch the code that arm11 will jump to after the reset. (This is why we need arm11 kernel) Instead of waiting for arm9 to tell it what to do in an idle loop, arm11 instead waits for arm9 to verify the FIRM header, then overwrite the code address arm9 will jump to to code we control. (This is known as a Time of Check to Time of Use (ToCtToU)) Let's see what happens with firmlaunchhax.
-With arm11 kernel control, we copy a payload for arm9 to jump to later to memory.
-arm11 tells arm9 that it wants to perform a firmlaunch.
-arm9 tells arm11 to sit in an idle loop until it tells it what to do.
-arm11 does not sit in an idle loop. It instead waits for arm9 to finish verification of the FIRM header.
-arm9 resets. It begins to read out the FIRM header and begins to verify it.
-The verification passes.
-arm11 overwrites the memory address arm9 will jump to.
-arm9 gives arm11 the memory address to jump to. arm11 doesn't care.
-arm9 jumps to the our code.(!)
-Profit.
The vulnerable SAFE_FIRM (safehax)
So the 9.2 arm9 exploit is all well and good, but what's it got to do with 11.2? Firmlaunchhax was patched on version 9.5**.
SAFE_FIRM
This is the FIRM used for recovery mode. When you hold a button combo at boot, you can launch recovery mode in case something fucks up. In theory.
Anyway, the point is: it hasn't been updated since version 3.0!*** That means that every exploit that was patched after 3.0 still works under SAFE_FIRM: including firmlaunchhax!
Irony
First, something I didn't mention earlier because it didn't matter. During a normal firmlaunch, arm9 will check arm11 for a bit to see if everything is working right. This didn't matter earlier because once the firmlaunch was done we had control.
Let's take a look at the safehax takeover procedure:
-From arm11 kernel, we tell arm9 we want to do a firmlaunch. This is done to launch SAFE_FIRM- remember, firmlaunching is done to change modes!
-The normal firmlaunch procedure occurs, except we tell arm11 to disobey the idle loop instructions and instead carry on our code execution.
-arm9 checks arm11 to make sure everything is running OK. We pretend like everything is fine, and it eventually stops checking.
-We've got arm11 kernel control in SAFE_FIRM.
-The normal firmlaunchhax procedure occurs.
-Profit.
11.3 usage
On 11.3, this was in theory patched. A flag introduced on 11.3 is set unless the current title has a special ID (this is speculated to be a repair cartridge of some sort) or home menu. If this flag is set and the currently running app attempts to launch SAFE_FIRM, the console promptly crashes. This would in theory prevent safehax from being executed, as we can no longer launch SAFE_FIRM to take it over.
In theory. ;D
In practice, the value is also set shortly after a firmlaunch, but not immediately. Thus, we can gain control of arm11 kernel, perform the steps necessary to firmlaunch with control kept, then firmlaunch again into SAFE_FIRM. The flag isn't set, it works fine, and we profit.
This was fixed on 11.4 by having Process9 set the flag instead. Thus, much like downgrading, to bypass this we'd need to take over arm9, and there's no point in bothering by then.
Conclusion
I hope this helped you in your understanding of the 11.2 arm9 exploit. If there's anything that's missing or you don't understand, let me know
I'm so bad at conclusions I'm sorry
Also, thanks to TiniVi, the person who implemented Safehax, for proofreading this post and correcting several major errors I made.
*This is done so that it doesn't just jump to memory arm11 could mess with and potentially control arm9 with code it put there.
**The reason we used to downgrade to 9.2 is because it was memchunkhax (the 9.2 arm11 kernel exploit) that was patched on 9.3, and devs never updated firmlaunchhax to be able to use memchunkhax2, the arm11 kernel exploit that worked until 10.3 (a modified version, memchunkhax2.1 AKA "svchax" worked until 10.7)
***Technically on N3DS it was updated at version 8.1, but 8.1 was the first N3DS firm so my point still stands.
Last edited by Swiftloke,
