Tutorial
Updated
TLDR on Switch Hacking (Entry-points, Firmware, Downgrading, Bans and More)
WARNING
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.
Legend
- 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.
- 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
- 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.
- payload (rcm payload): This is a compiled executable file meant to be run through rcm via a RCM stack smasher like TegraRcmSmasher
- ipatched unit: A Nintendo Switch unit that has patched the Tegra X1's Recovery Mode against unsigned code execution
- emmc: The System's Storage, with storage up to 32GB
- nand: System files stored on the eMMC chip
- warm boot: An entry point that gets done after the boot process by software, typically by manually doing stuff (e.g. 3DS's ninjahax)
- cold boot: An entry point done automatically by hijacking the boot process, requiring no user input (e.g. 3DS's bootstrap9)
- 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.
- 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.
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 ismyswitchpatched.com 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.
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:
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.
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!
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.
DO NOT USE AUTORCM ON AN IPATCHED UNIT, YOU WILL PERMANENTLY BRICK!
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.
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 https://switchbrew.org
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.
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 ismyswitchpatched.com 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)
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)
- 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.
Code:
[Atmosphere]
payload=bootloader/payloads/fusee-primary.bin
{}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.
DO NOT USE AUTORCM ON AN IPATCHED UNIT, YOU WILL PERMANENTLY BRICK!
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 https://switchbrew.org
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.
Knowledge-base
Entry-pointsManaging your System FirmwareBansPiratingDowngrading
There is currently no cold boot exploit and probably wont be for a while (if ever).
- Tegra X1's Recovery Mode Overflow (aka RCM)
Hardware flaw, cannot be patched via software, requires jig and external device
First revision units are the only ones vulnerable, check ismyswitchpatched.com
Tutorial: https://gbatemp.net/threads/how-to-boot-hekate-using-sx-os-pro-dongle-or-windows-pc.507619 - Deja Vu
Software flaw, patched on v8.0.0, warm boot exploit
v1.0.0 with Nereba, v2.0.0-v4.1.0 using Caffeine, More firmware's to be supported in the future.
Recommended to be used via PegaScape
- Tegra X1's Recovery Mode Overflow (aka RCM)
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).
DOING ANY KIND OF FIRMWARE DOWNGRADE/UPGRADE/CHANGE IS NOT ADVISED ON AN IPATCHED UNIT AS OF RIGHT NOW, IT IS NOT SAFE!
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)
- 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: https://switchbrew.org/w/index.php?title=Fuses
-
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.
AS JUST EXPLAINED, DO NOT ATTEMPT TO DOWNGRADE TO AN OLDER VERSION THAN THE BURNT FUSE COUNT ALLOWS
ON A NON IPATCHED UNIT YOU CAN RECOVER FROM IT BY USING RCM + CHOIDUJOURNX TO UPDATE TO A CORRECT FIRMWARE, BUT ON AN IPATCHED UNIT YOU CANNOT!
Software
Custom Firmware'sPayload InjectorsEmuNANDLockpick_RCM
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.
- 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) - ReiNX
By @Reisyukaku (and contributors) - Currently has a custom home-menu being developed for it.
Free (open-source) - 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)
- Atmosphere
- WebCFW (Browser-Based, Cross-Platform)https://webcfw.sdsetup.com
Software-less and cross-platform solution (if you exclude the browser, it has limits to device/browser combinations).https://webcfw.sdsetup.com - TegraRcmSmasher (Windows)https://switchtools.sshnuke.net/
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!
- 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 findhttps://www.xkit.xyz/rcmloader/
- WebCFW (Browser-Based, Cross-Platform)https://webcfw.sdsetup.com
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: https://gbatemp.net/threads/setting-up-partitions-for-emummc-with-hekate5-0-nyx.542321/
https://github.com/shchmue/Lockpick_RCM
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.
Notes
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,
