TLDR on Switch Hacking (Entry-points, Firmware, Downgrading, Bans and More)

Discussion in 'Switch - Tutorials' started by PRAGMA, Jun 29, 2019.


    PRAGMA GBAtemp Addict

    Dec 29, 2015

    Most Homebrew does not know if you are on an ipatched console or not and assumes you have rcm access, as a result, some homebrew or its options may be unsafe on an ipatched unit.
    DO NOT USE AUTORCM UNDER ANY CIRCUMSTANCES ON AN IPATCHED UNIT, doing so will get you permanently bricked.

    • Me and anyone mentioned or linked to, is NOT responsible for anything going wrong.
      While every measure was taken to ensure the most protection for the users, you still assume all responsibility.
    • Please follow all instructions for anything mentioned or linked to by trusted users.
      Do NOT follow YouTube video tutorials ever as they get outdated faster than you think and exclude a lot of important steps or get them wrong.


    1. rcm: Tegra X1's Recovery Mode, which has an overflow exploit on the first revision units allowing unsigned code execution and isn't patchable with software updates.
    2. jig (rcm jig): Item to ground 2 pins together by bridging (usually pins 1 and 10) to cause the switch to assume joycon failure and enter rcm, this is often a small and cheap 3d printed item or paperclip
    3. injector (payload injector): Device that connects to the switch's USB port or pads to send a payload through the rcm stack using the overflow flaw.
    4. payload (rcm payload): This is a compiled executable file meant to be run through rcm via a RCM stack smasher like TegraRcmSmasher
    5. ipatched unit: A Nintendo Switch unit that has patched the Tegra X1's Recovery Mode against unsigned code execution
    6. emmc: The System's Storage, with storage up to 32GB
    7. nand: System files stored on the eMMC chip
    8. warm boot: An entry point that gets done after the boot process by software, typically by manually doing stuff (e.g. 3DS's ninjahax)
    9. cold boot: An entry point done automatically by hijacking the boot process, requiring no user input (e.g. 3DS's bootstrap9)
    10. nsp: "Nintendo Submission Package", this is what would be downloaded and installed by the eShop. It's essentially an installation file. Similar to the .cia format for the 3DS.
    11. xci: This is just a cartridge format, essentially a rom. Similar to the .3ds format for the 3DS.

    Getting Started
    So, you wish to learn how to go from a Stock switch, to running a CFW.
    While this thread isn't directly a tutorial, it's essentially a binder of information to make the process more easy to understand and to show the current state of the scene.
    If any term confuses you, please read the above legend.

    A - Tipping your toes, to see how warm it is

    We need to find out if your switch is vulnerable to rcm or not. To do this, we can give a quick check with your Switch's Serial Number.
    You can find your serial number in your Switch Setting Menu aswell as on the bottom left of your Switch unit.
    Follow the instructions on and it will let you know the result. If its Green, it's vulnerable! If it's Red, its ipatched :(
    But if it's Orange, you will need to test the vulnerability to find out.

    B - Running an rcm payload

    It's super simple in practice, but it gets fairly repetitive and annoying, it's the only downside to RCM, the annoying steps you need to take.
    You need a few things to run an rcm payload, a jig, and an injector. Both has been explained in the legend above.
    Kinds of Jigs:
    • Cheap 3d printed item (ebay $5)
    • Paperclip that you bend (takes a while and is often fiddly and needs adjusting)
    • Tinfoil (not recommended, generally harder to do, and reports of damaging the pins)
    You can find a Payload Injector in the Software list below.
    Once you have a Jig and a way to inject a Payload, simply follow this tutorial to try injecting Hekate's payload :)
    The tutorial also states how to know if it failed because of it being a patched switch.

    Assuming the test above ran with no troubles, you now know if you are either ipatched, or non ipatched.
    • ipatched: Can only execute unsigned code with software flaws. (e.g. deja vu)
    • non ipatched: You can always run unsigned code through rcm (or software flaws)
    Here's what you can do from here:
    • ipatched: Check below in the "Entry-points" list to see if there's any exploits available for your Firmware.
      - if there is, try use it and come back here.
      - if there's not, it's the end of the line, don't update your system, and wait patiently for a possible exploit.
    • non ipatched: Simply run whatever payload you wish! :D It cannot be patched by Software.
    C - Sweet! I got Hekate injected, Now what?

    Now understand the exploitable state of your switch.
    Safeguard it! Read below in the Knowledge-base on managing your system firmware.
    Run Hekate and immediately create a backup of your NAND. Store this safely, I recommend on multiple Cloud Services, as well as on a couple USB's.
    A NAND backup can restore you from errors in the future.

    Now that your safe guarded, let's have some fun.
    We can start by installing a CFW, go ahead and choose one from the list below and click its name, it will bring you to the project page which somewhere in it will contain tutorial/installation steps.
    The CFW installation steps most likely will not contain steps on integrating it with Hekate, while Hekate is not needed, it's a very good chain-loading application.
    It allows you to quickly launch many different payloads just by choosing it on your Switch, and tons more, its a very good utility with too many features to mention.
    We already have Hekate setup from the rcm test earlier, so that saves us time, but now we need to add entries to the Launch option.

    To add an entry to the Launch option, we need to edit sd:/bootloader/hekate_ipl.ini (Since you have already run Hekate earlier, I assume this exists, it's created on first launch).
    For example, the following will add Atmosphere to the Launch list.
    (add that the the end of the .ini file)
    The "[Atmosphere]" is the Launch entry's Name, the "payload=bootloader/payloads/fusee-primary.bin" is the sd path to the rcm payload file.
    There's more options than this for more customization so I recommend searching up Hekate or take a peak at its GitHub Read-me.
    You can add more and more just by doing the same thing with other payloads, the payloads do not have to be CFW's.

    Now when you open Hekate and click Launch, it will show Atmosphere (or whatever you added), simply select it and it launches!

    D - Is there anything else I can do in terms of booting

    Yes! In Hekate it has an option to enable AutoRCM.
    Please, for the love of god, understand how this works. Tempy doesn't like seeing AutoRCM issue threads.
    What AutoRCM does, is it intentionally breaks a boot file by a tiny margin to cause the Switch firmware to panic and enter recovery mode.
    It essentially replaces you having to do the Jig nonsense with the compromise being that the switch wont turn on without you pushing a payload.

    You could install an EmuNAND, have everything you do, be stored on your SD card on a second Firmware, instead of your primary Firmware on your eMMC.
    See EmuNAND section in Software below for more Information.

    Well done! Enjoy!

    While that's about it, summarized down, there's a lot more going on, if you want to see the nerd stuff, head over to
    Right now, we are hoping for Deja Vu to get supported on more firmware's, and there are probably more exploits being investigated as we speak.
    Feel free to read my explanation on Firmware's and Downgrading shown below, to help get you the most out of your Switch.


    • There is currently no cold boot exploit and probably wont be for a while (if ever).

    • General rule is to stay on the lowest firmware version possible. As firmware's get updated, so do security holes patching possible exploits.
      You can see the entry-points above, as you can see, some require an RCM exploitable unit (non ipatched), and some require specific firmware versions.
      Even if the firmware you are on is not satisfied with an exploit, its best to stay on the lowest firmware and wait for a possible exploit. It's essentially a game of patience.
      You never need to update, the only reasons to be updated are to access Online, Your Nintendo Account, and the eShop.
      Does your game require an update to open? No it doesn't ;) Just dump your game cartridge to an nsp with nxdumptool and install it with Goldleaf selecting "Yes" to "Ignore Required Firmware Version". (this requires signature patches and a cfw)
      If you are updating for some reason or another, update using ChoiDujourNX, using its "AutoRCM" option as it update's without burning a fuse which will aid in downgrading in the future.
      You could also try using an EmuNAND, more information on that is below.

      Its best to try and see if you have the ability to downgrade, this may allow you to use exploits only working on older firmware's, see below for information on Downgrading.

      If you wish to prevent receiving updates automatically, use 90DNS or enter Airplane Mode.
      If you received an update and are now being constantly nagged to update, you can enter the Nintendo Switch Recovery Mode (not to be confused with the Tegra RCM) to remove it.
      Simply holding VOL-, VOL+ and POWER at the same time, gets you into the Nintendo Switch Recovery Mode. Simply entering this will remove the cached update which removes the Nag (thanks Nintendo).


    • Yes - You can and most likely will end up getting banned if you mod your Switch.
      There's no point asking if doing X is safe, or will I get banned doing y, because we aren't Nintendo, we don't know.
      Most likely, if you have to ask, it's because you are worried that it will, and if that's the case, it's most likely something that will get you banned.

      Getting banned would usually end up in the inability to access services like:
      • Nintendo CDN (Downloads)
      • Nintendo Account (NNID), including logging in via a Browser or on your Device
      • Linking Accounts
      • Using share services like Twitter and Facebook in Album (Requires Nintendo NNID)
      • Opening apps like YouTube (Requires Nintendo NNID)
      • Online-only games (even free ones) like Fortnite and Rocket League (yes even though it has offline modes)
      Want to get banned?
      • Go online on a pirated game. [confirmed]
      • Use the official DevMenu [semi-confirmed, i asked nintendouk why I was banned, they said illegal romid, i assume this is the devmenu id as it was the only thing suspicious I did]
      • Change your Nintendo accounts avatar via Homebrew or the official DevMenu [confirmed]

    • GBATemp, as well as the general community as well as the vulnerability researchers strongly advise you NOT to pirate.
      By default, when running a CFW like Atmosphere, you will not be able to install and run games you do not own.
      This is because, unlike other CFW's, it doesn't patch the signature checks that are done when opening a game.
      There are ways to patch the signature checks on CFW's like Atmosphere but I will not be explaining how.

    • To understand the Nintendo Switch's downgrade protection, I'll give a tiny tl-dr; but there is a lot more involved, I'm simplifying greatly.
      The Nintendo Switch has an array of eFuses that it can call and see if it's working. When you update through official means, it burns eFuses until there's specific amounts that aren't working.
      When booting the Nintendo Switch, it calls the eFuses to see how many are working and how many are burnt. Each firmware revision expects certain amount of fuses to be broken (the amount that its meant to have burnt when updating).
      If there's more burnt fuses then what the firmware was supposed to have, it assumes you downgraded the firmware and shuts down rendering it somewhat bricked.
      For example, when updating to v3.0.0 through official means, it will burn up to 3 fuses. v3.0.0 when booting will now check and make sure there's no more than 3 burnt fuses, if there's more, it shuts down in panic.
      Another example is, updating to v3.0.0, get 3 burnt fuses, now we are going to "downgrade" to v1.0.0 by simply overwriting the firmware with a v1.0.0 firmware backup. v1.0.0 expects no more than 1 burnt fuse, but there's 3 burnt, it detects that and assumes you have downgraded, it shuts down in panic.
      The great thing, is it doesnt care if you have less burnt fuses then it expects, so running v8.1.0 (which expects 10 burnt fuses) when only having 1 burnt fuse (v1.0.0) it would still let you boot.
      This is why we like to update via ChoiDujourNX, it updates your firmware without burning fuses, so you could go from a v1.0.0 with 1 burnt fuse, to v8.1.0 still with 1 burnt fuse, which would work perfectly fine.
      And since v1.0.0 expects no more than 1 burnt fuse (which is how many we have), we can still downgrade back to v1.0.0.
      To learn more, you can read up on switchbrew here:
      To find out how many burnt fuses you have, you can run the Hekate payload and see via Fuse information.
      You can see which firmware you are able to downgrade to based on your burnt fuse count on this list.


    • There are surprisingly a lot of different CFW's to choose from on the Switch.
      I have listed them in an order upon which seems the most popular right now.
      1. Atmosphere
        By @SciresM (and contributors) - Notable for being the first CFW, it is the top choice among the community base as of right now.
        Free (open-source)
      2. ReiNX
        By @Reisyukaku (and contributors) - Currently has a custom home-menu being developed for it.
        Free (open-source)
      3. SX OS
        By Team-Xecuter - Piracy-focused CFW, they have been blatantly caught many times reusing code from Atmosphere and other Projects
        and has broken many licenses of open-source code. Originally had bricking code upon detecting edit of the binary (crypto locks the emmc with a password). Code is obfuscated. Not recommended.
        Note: There are other CFW's similar to SX OS, this is because they are actually using cracked and edited copies of SX OS's v1.0 binary so they will not be listed.
        $20~ (closed-source)

      • WebCFW (Browser-Based, Cross-Platform)
        Software-less and cross-platform solution (if you exclude the browser, it has limits to device/browser combinations).
      • TegraRcmSmasher (Windows)
        First? payload injector, and still one of the best.
        Quickly inject by drag and dropping a payload onto the .exe file
      • Rekado (Android)
        Need to inject on the go? Just use your handy smartphone! :D
      • Dedicated Device, it's sole purpose is to power on and inject the payload.
        These fly around everywhere on flashcard sites and aliexpress.
        I use the RCMloader ONE by XKIT which is in my opinion the best option, but is harder to find

    • NAND "emulation" solutions have finally arrived.
      It's most handy use is you can keep your eMMC on an old firmware version with absolutely no CFW changes at all done on it, and do everything on your emuMMC and update it without affecting your eMMC.
      The EmuNAND is hosted on your SD card, away from your system memory.

      The EmuNAND solution I recommend to use for its convenience is emuMMC on Hekate (starting from v5.0.0).
      This is very new, there's a couple steps you need to do with your SD card to prepare it.
      In the future you will not require to do any preparation, hekate has plans to automatically do everything in the future.
      If you wish to setup one, please follow this tutorial:

      At some point, you may need your Switch's key files, these are keys used throughout various points, too much to mention.
      Some software requires it, so it may be a good idea to get it over with now.
      Simply run the Lockpick_RCM payload and it will save the keys to sd:/switch/prod.keys within seconds.


    If you have a meaningful contribution/update, feel free to update this thread. I believe staff is able to give you the ability to do so.[/h][/h][/h][/h][/h]
    Last edited by PRAGMA, Jul 2, 2019
    piwix, RealSpyKitty, hausa51 and 5 others like this.
  2. Ericthegreat

    Ericthegreat Not New Member

    Nov 8, 2008
    United States
    Only thing I don't agree with is the last part, they probably won't ban you on your 2nd switch. (Closest I've heard is people getting banned for sharing videos of themselves playing with a friend who hacks, this is not confirmed of course)

    " Gbatemp as well as the general community as well as the vulnerability researchers strongly advise you NOT to pirate. "

    Probably the majority of members joined to learn more about piracy >.>;
    Last edited by Ericthegreat, Jul 2, 2019
  3. lolcatzuru

    lolcatzuru GBAtemp Fan

    Apr 20, 2012
    United States
    very good guide but yea the last part isnt accurate. I've had 2 switches and ive been fine so far. I dont think nintendo is THAT with it.

    PRAGMA GBAtemp Addict

    Dec 29, 2015
    Sure, removed that bit then.
  5. Ericthegreat

    Ericthegreat Not New Member

    Nov 8, 2008
    United States
    If you plan to get this stickyed, tell me and I'll remove my post.
    RealSpyKitty likes this.

    PRAGMA GBAtemp Addict

    Dec 29, 2015
    Its up to staff if it gets stickied, and i'm sure if staff ends up doing so, they will remove the gripe from here.
    Ericthegreat likes this.

    PRAGMA GBAtemp Addict

    Dec 29, 2015
    Updated this a lot in the 2 hours 25 minutes. Its pretty sweet looking now :switch:
    RealSpyKitty likes this.
  8. Dark Ronin

    Dark Ronin GBAtemp Regular

    Oct 5, 2015
    Just my 50 cents of thoughts...
    On iPatched units it is guaranteed that enabling autoRCM bricks console.
    However, we might be able to disassemble console, remove eMMC unit, plug it into non-patched console, run hekate and fix boot0/1 files back to normal state.
    I don't see any obstacles preventing this course or action.
  9. Isakill

    Isakill Member

    Mar 28, 2017
    United States
    Just trying to get everything set up for the future, and testing... no matter what I do (entering in the manual DNS IP's) nets me the "You must update your console" nag. (on 7.0.1)

    I've tried both the IP's listed on the pegascape page, and another one listed on lifewire that was supposed to direct to switchbru DNS.

    Is there anything I'm missing?

    I tried the system restore option after googling "switch update nag" (power+volup+voldown) I'm still getting the nag if I try the link account, adding BOTH ips from pegascape on primary and secondary DNS.. Still googling to figure this out.

    It appears that pegascapes IPs don't run 90DNS as it claims. Because if I use those IP's, I get the nag. If I use the one listed in the 90DNS thread, it is indeed blocked. But then I can't access the pegascape website.
    Last edited by Isakill, Jul 3, 2019
  10. PRAGMA

    PRAGMA GBAtemp Addict

    Dec 29, 2015
    That might work, but it wouldn't be something everyone has the ability to do.
    Dark Ronin likes this.
  11. Dark Ronin

    Dark Ronin GBAtemp Regular

    Oct 5, 2015
    Hmmmm... There may even be a possibility to remove supernag with this.

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

    Yes, as it requires another non-patched console and pretty straight hands.
  12. KnightRiderX420

    KnightRiderX420 Advanced Member

    Nov 24, 2018
    United States
    my question is if the firmware of the lite is identcle and the ipatched units work with the caffine exploit.. sorry I called it coffee here before and was wrong.... couldn't it be emplimented into the switch lite very easily? unless webkit is gone or switchbrew fails too.... just brainstorming.....
  13. PRAGMA

    PRAGMA GBAtemp Addict

    Dec 29, 2015
    Yeah if theres no hidden surprises I see no reason as to it not working (though id be surprised to see it release on a firmware below 8.0.0, they most likely will release it on 8.0.0 or newer because of DejaVu)