How does the 11.2 arm9 exploit work? "For Dummies"

Discussion in '3DS - Flashcards & Custom Firmwares' started by Swiftloke, Jan 16, 2017.

  1. Swiftloke

    Swiftloke Hwaaaa!

    Jan 26, 2015
    United States
    Note: This was patched on 11.4.
    Great, you all have gotten your piracy 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?
    A disclaimer
    Another disclaimer
    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.
    (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.(!)
    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**.
    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!
    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.
    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.
    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, May 21, 2017
  2. Pacheko17

    Pacheko17 かっこい男の子

    Jan 31, 2015
    Somewhere in the south
    This is really helpful! Nice thread! :yay:
    NoNAND likes this.
  3. jtvjan

    jtvjan Member

    Dec 7, 2014
    Your post and the linked blog post were both very interesting and an overall good read. Good job! (o_o)b
    Last edited by jtvjan, Jan 17, 2017
  4. GerbilSoft

    GerbilSoft GBAtemp Addict

    Mar 8, 2012
    United States
    Nintendo intentionally doesn't update SAFE_MODE_FIRM in order to provide a recovery environment in case an update fails. (This happened with 5.0.0-11.) This leaves them with a conundrum:
    • Push a SAFE_MODE_FIRM update and risk bricking systems if it fails.
    • Leave SAFE_MODE_FIRM as-is, keeping the system vulnerable.
    Last edited by GerbilSoft, Jan 17, 2017 - Reason: +_FIRM
    MrJason005, maorninja and jtvjan like this.
  5. Imacaredformy2ds

    Imacaredformy2ds Smartass

    Nov 17, 2016
    I can actually more or less understand this
    Good fucking job Mr. PK Love
    Rilaction likes this.
  6. Swiftloke

    Swiftloke Hwaaaa!

    Jan 26, 2015
    United States
    Sounds like you don't understand something? I take that seriously... What is it you're not getting?
    Also, is there any interest for A9LH For Dummies? I did a write-up a couple months ago and never finished it...
    jtvjan likes this.
  7. Vieax

    Vieax Advanced Member

    Feb 24, 2017
    Nice thread :toot:

    — Posts automatically merged - Please don't double post! —

    would be nice if you would post that :) !
    I really like your posts because im intrested af in 3ds hacking.
  8. windhazard

    windhazard GBAtemp Fan

    Mar 23, 2016
    Can you elaborate what Nintendo patched on 11.3 that fixed SAFE_MODE_FIRM's vulnerability and avoid bricking risk at the same time? Or will we just brick now if an update fails?
  9. gamesquest1

    gamesquest1 Nabnut

    GBAtemp Patron
    gamesquest1 is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    Sep 23, 2013
    I'm sure they could easily install the main firm, verify the installation and then continue to install the updated safe firm or if they wanted to be extra cautious they could just update normal firm, reboot the system then have the 11.3 automatically install safe firm after the first reboot
    Last edited by gamesquest1, Mar 1, 2017
  10. GerbilSoft

    GerbilSoft GBAtemp Addict

    Mar 8, 2012
    United States

    11.3 doesn't update SAFE_MODE_FIRM. Instead, they added a check to prevent SAFE_MODE_FIRM from being launched from most user titles except 0xF802A (some repair cartridge?) and the Home Menu.
  11. adrifcastr

    adrifcastr GBAtemp Advanced Maniac

    Sep 12, 2016
    If you need to know anything, you can PM me and I can explain it in german
    Vieax likes this.
  12. Dysproh

    Dysproh Member

    Dec 30, 2016
    United States
    I have been wondering how this works. Thanks for writing this out.