- Joined
- Oct 27, 2002
- Messages
- 23,745
- Trophies
- 4
- Age
- 46
- Location
- Engine room, learning
- XP
- 15,682
- Country
The different Atmosphère CFW patches for your Switch Firmwares
Written by @Cyan and @Itsuki235
Last update: 2020 05 10
Available firmware version as of this guide Last update date: OFW 10.0.2, AMS 0.12.0, Hekate 5.2.1
If a new (custom) Firmware version is available, this guide may become outdated. Use with care and gather compatibility information in other places before proceeding.
This guide has an informative purpose only to help you understand the different patching methods. It only helps you understand and make your choice between other available hacking guides and patches.
Presentation
Since the Switch Horizon firmware v10.0.0 has been released, a lot of confusion has arisen with CFW patches.
This guide will try to explain what happened and what are your current choices for patches.
Seeing how much new forum threads asking the same questions about patches were created these past few days, I wanted to write this guide to explain and help people understand what's happening, what they are using and how to do so. I hope it will be helpful to you.
If you are only looking for patches, go to the patching Atmosphere section or use NeutOS. Links below.
Why do I need a new way to apply patches?
Horizon 10.0.0 moved the ES signature functions from ExeFS to a new "loader" module.
Following that change, Atmosphère implemented a "loader" sysmodule to replicate the functionality. Since ES and ACID check functions for CFW are now in that Atmosphère sysmodule, CFW 10 requires some way to patch that new module if you ever need ES patches to install and play unsigned apps.
Additional Background - The Boot Modes
Before 10.0.0, the patches were applied directly to Nintendo's sysmodules. New patches were required only on new firmware versions.
The patches are now applied to a Atmosphere Loader sysmodule, and therefore will require new patches on each new AMS revision to that sysmodule.
Previous patches were all released in ips format.
That new Loader sysmodule and atmosphere now have to be patched using two different methods:
- ips patches and/or
- a custom “loader.kip” sysmodule.
Update 2020 05 01: Since Hekate release v5.2.0, the "kip" modules can be live patched too, in the form of hekate patches.ini file (not ips). so, new packages could be provided without the kip file.
So you might wonder what are these two booting methods you should use and how to apply the patches correctly. There are 2 different methods to boot into Atmosphere.
- Boot using fusée-primary
This is the primary method of booting atmosphere supported by the developers.
Example1: You send Atmosphère fusée-primary payload directly to the console in RCM.
Example2: You send Hekate_CTR payload to the console in RCM, which boots Atmosphère using “payload=fusée-primary” functionality.
The scenario in example 2 is the same way of launching Atmosphère as in Example1, except it's chain-loaded by Hekate.
- Using Hekate to boot fusée-secondary
Hekate can boot Atmosphère by extracting Atmosphere modules directly from fusée-secondary.bin, which can then be loaded or replaced independently.
Example3: You send Hekate_CTR payload to the console in RCM, which boots Atmosphère using “fss0=fusée-secondary” functionality.
Note that "sending" here refers to using your preferred Fusée Gelée payload sending method with your console in recovery mode: computer(TegraRCM), USB dongle, phone apps, etc.
So the three can be resumed like this :
Send Payload “Fusee-primary.bin” > boot Atmosphere (fusée-secondary)
Send Payload “Hekate” > chain-boot fusee-primary.bin > boot Atmosphere (payload=)
Send Payload “Hekate” > Hekate uses fusee-secondary to boot Atmosphere (fss0=)
A Special Note About EmuMMC and Hekate/Kosmos:
Hekate (and Nyx interface of Hekate) set by Kosmos ready-to-use package lets you choose how you want to boot your console (Stock, SysMMC or emuMMC) directly from its menu. But this choice can only be applied if you launch Atmosphère with fusée-secondary (“fss0=”).
If you have an emuMMC folder or partition and use fusée-primary (“payload=”) method to boot your console, Atmosphère will always follow its own setting to determine whether to use sysMMC or emuMMC regardless of the user choice in Hekate.
While an alternative may be to edit Atmosphere config files to force disable emuMMC and reboot the console, the typical method is to edit “emummc/emummc.ini” and set emummc!enabled=0 or 1. 0 means disabled. 1 Means enabled. You can edit the file yourself, or use existing homebrew directly from your Homebrew Launcher menu, such as emuMMC Toggler or EmuMmcConfig and reboot the payload (fusée-primary).If you use Hekate, you could name your boot choice “Atmosphere” only.
This loss of flexibility and user unfriendliness from Hekate boot menu when using fusee-primary.bin to launch AMS is why Kosmos uses the “fss0=” booting style for syntax.
Using fss0= with fusée-secondary potentially allows for the following boot modes directly from Hekate:
- Stock-like sysMMC
- sysCFW
- emuCFW
Patching Atmosphere
The patches you need can depend on which version of the Horizon OS you are launching with Atmosphère (whether it's > 9.2.0 or not), and which Boot method you are using.
FW < 10.0 (e.g OFW ≤ 9.2.0)
If you are booting a custom firmware before 10.0.0, the latest version of the patches also includes the patches needed for older custom firmware. So you don't need to find old packs. The new ips patch pack contains the patches needed for older firmwares too!
This is also true for AMS’s new “loader” sysmodule bundled with AMS v11.0+. It is only used on CFW v10.0.0 or newer so applying newer IPS patches to the newer sysmodle cannot break anything because it does not activate when not needed.
Previously maintained by The-4n here (historical)
Whether you use fusée-primary or fusée-secondary, the patches are the same.
You can also get the patches bundled for FW≥10 fusée-primary as they contain all previous ones.
FW >= 10
If booting using fusée-primary payload, with or without Hekate
If you are booting using fusee-primary, you need this subset of the ips patches. Choose one from the available packages
- Raugo (outdated)
maintained by Raugo here.
- HarukoNX (outdated)
Haruko is also providing the same package, but he called it "Fusée". Even if you are using Hekate to boot primary, do not use the "hekate" package!
His Homebrew patch downloader will soon be updated to also detect and include the "fusée" package (for fusée-primary boot method). For the moment, use only the manual installation method.
maintained by Haruko here.
- lbcap
New maintained thread.
maintained by lbCap Here
If using Hekate/Kosmos to boot fusée-secondary with “fss0=”
For the “fss0=” boot method, The ips patches used by Atmosphère alone are not enough, you need additional patches applied directly by Hekate.
- SDFiles (Still current? outdated or not?)
SDFiles website has a full package of these patches.
https://sdsetup.com/console?switch
If the website doesn't work, update your Internet browser or use another one.
- HarukoNX (outdated)
You can find either a package (which he called "hekate") with the files to copy to SD , or a homebrew updater to launch from your console Homebrew Launcher which detects and downloads the exact loader.kip and patches.ini files you need based on your currently installed Atmosphère version.
Since Hekate v5.2.0 released in May 2020, the "loader.kip" module is not included anymore in Haruko package and is replaced with live hekate patches.
maintained by Haruko here.
The pack is not complete (yet) !
It's missing FS patches for FW < 10.0, only ES patches are present !
This does not contain ES patches for FW >= 10, only FS and Loader.
Haruko claimed he didn’t include ES patches for FW≥10 for personal reason, but will eventually add them on a later update.
Special Notes:
- Bundled Loader.kip (not included anymore since May 2020) and hekate patches.ini files are not working with Blawar’s Tinfoil on CFW 10+ because of personal decision. This forces Tinfoil users to use either fusée-primary with ips patches, SX OS, or NeutOS.
Loader.kip provided here is/was a modded version of Atmosphère's Loader sysmodule, which directly includes/included all the needed patches.
Loading this modded module requires fss0= boot method in order to extract all kips from fusée-secondary.bin and replace the original with the modded one.
As of May 1st 2020, Hekate can also patch the extracted kip modules, there is no more need of pre-compiled modded binary kip files. some packages you find on other website, or old packages might still include it. Either a modded kip file or a patches.ini file can achieve the same role.
- ShadowOne33
new maintained thread.
maintained by lbCap Here
Using another CFW for Patches
- NeutOS
NeutOS was a fork of atmosphere with the stated purpose of being compatible with tinfoil. NeutOS has been discontinued in favor of ReiNX custom firmware.
ReiNX has been updated on 2020 May 6th to support FW 9.x and 10.x, and contains all the needed patches to use tinfoil, therefore NeutOS didn't had any purpose on pursuing its support.
The information here are provided for reference to people still using NeutOS.
NeutOS is Atmosphere but with a different bootloader based upon the Shofel2 source code which is implemented in a very similar way to the bootloader used in SX OS.
NeutOS already contains all the needed patches (ES, FS, Loader)
https://github.com/borntohonk/NEUTOS/releases
emuMMC:
NeutOS "install guide" (provided with each revision's changelog) lets you boot the payload directly from the RCM menu without using hekate, therefore the EmuMMC choice is the same as using Atmosphère with Fusée-primary boot method. It means that you need to edit emuMMC/emummc.ini file to swap or choose between sysMMC or emuMMC!
if you ever decide to use Hekate to boot NeutOS, be sure to use "payload=" method, not "fss0"!
- ReiNX
Note: Currently, ReiNX doesn't support EmuMMC ! but this feature will be added quickly in future releases.
If you need tinfoil on SysMMC, use ReiNX
If you need tinfoil on emuMMC, use NeutOS (discontinued).
in both cases, you can always use Atmosphère CFW with the Fusée-primary boot method (with primary patches).
https://github.com/Reisyukaku/ReiNX/releases
How to change the boot method in Hekate
Atmosphère can be launched without using Hekate, directly by injecting fusée-primary payload into RCM, like officially intended.
If you use Hekate to launch Atmosphère, the boot menu displayed in Hekate can be edited to change the launch method (payload= or fss0=).
Open and edit SD:/bootloader/hekate_ipl.ini according to this: https://github.com/CTCaer/hekate
Guide by @toxic9 : https://gbatemp.net/threads/how-to-hekate-chainload-vanilla-atmos.563255:
Note: This guide uses fusée-primary method to boot Atmosphère, therefore changes the Hekate boot menu to display only two choices : Atmosphere (cfw) and Horizon (ofw).
Whether Atmosphère is booting on sysNAND or emuNAND depends on its own ini file, not hekate anymore.
If you plan to use Fusée-secondary with Haruko patches, you’ll have to keep the emuMMC boot choices from hekate menu, but remember that Blawar’s Tinfoil does not work with that boot method. It will detect and delete the files present on your SD card even if you are temporarily not using fusée-secondary boot method to use Tinfoil.
Hekate and boot method specific FAQ
- Why use Hekate to boot fusée-primary if you can boot Atmosphère directly?
Even if Hekate is a powerful tool for advanced users, it is used in most hacking guides to perform the initial eMMC backup for safety reasons, and often bundled in ready-to-use CFW packages (such as SDMenu/Kosmos) as a boot menu.
Hekate actually has many uses besides loading Atmosphere and so loading Atmosphere is just one of the many things that it does. Part of the reason to set it as main payload to benefit from all of those other functionalities without having to modify which payload.bin to push initially, such as easily creating and managing emuMMC, sys backup/restore management, launching arbitrary payloads occasionally (like Lockpick_RCM, Lakka, Android, etc.), viewing console hardware information including battery charge status and rate. It can also be used to set up an automatic chain-boot into any other payload present on the SD card, not only atmosphere, such as NeutOS or SX_Loader.bin.
Chained payload can be on SD card and chosen from a menu on the console instead of being sent using Fusée hack (TegraRCM/dongle/android). On your dongle, you can keep Hekate payload and don't need to change it every time you want to send a different payload.
- What's the differences with using primary or secondary in Hekate?
Fusée-secondary contains different sysmodules in it (kips files)
- When using fusée primary, all the included kip modules are used. Additional kips files can be added from kips folder, ips patches can also be applied to change some included modules.
- When using fusée secondary, hekate extracts each module from secondary before loading them independently, and allows the user to replace some extracted kips with any others.
- Why is this a problem with new Horizon 10.0.0 ?
ips for loader.kip seems to work only when using the fusée-primary boot method.
So, based on your booting method, you'll have to find and use different patching files.
- What is ACID? What about ACID patches?
For .nsps, an ACID check checks the RSA key in the NPDM ACID section and the checks for the NPDM RSA signature in the Program NCA section.
Files with valid ACID signatures mean the RSA key is untouched and hence the Program NCAs are unmodified (not altered).
ACID patches just remove another signature check.
ACID patches are part of "nosigchk" patches.
Interestingly, NSPs can be dumped in such a way so as to not require ACID checks, but that would also mean there is no way to validate that they have not been modified.
General Guide FAQ, Error and help section
- Do I need a new patch every time Atmosphère updates the loader sysmodule?
YES !
You used to need new patches on every new Nintendo's Horizon OS firmware.
Now that ES/ACID checks are inside an Atmosphère sysmodule, Every change done to that Atmosphère module will require a new set of patches for that specific Atmosphère version, and not only when Nintendo changes or updates its own modules on new Horizon OS firmware.
Patches should now be released with Atmosphere version information, for example "2.0.0-10.0.0 for AMS 0.12.0"
if you are on 10.0.0 but with AMS 0.12.1 it will NOT WORK! even if your firmware is matching FS sysmodule of the firmware 10.0.1.
- Why do you mention Tinfoil and no other apps?
Blawar’s Tinfoil has very strict requirements and forces users to launch specific configurations so compatibility information is listed here. Other apps do not have arbitrary compatibility limitations so they are not mentioned before now.
Alternative Title installers include Goldleaf, SX Installer and Awoo Installer.
- Is using NeutOS a good or bad idea?
NeutOS is an unoffical Atmosphère fork and will need to be updated after each new official release.
It is no different than waiting for ips patches after a new atmosphere release, and at least for now, NeutOS and Atmosphere are still binary compatible.
Some could argue using recompiled binary sysmodules could be more riskier if no sources are provided (when only the kip is shared without info about its source).
But that concern can also be applied to ips patches. I am sure very few people actually look at the patched addresses.
It also comes with added convenience of not having to locate patches every time at the cost of a closed-source boot process.
- Pros:
- Includes all the patches “out of the box”
- It is Atmosphere and contains all of Atmosphere’s functionality
- Works with every versions of firmware that Atmosphere supports (10.0+)
- Works with Blawar’s Tinfoil (subjective)
- Cons:
- It is Atmosphere but with some closed source changes to the bootloader
- dependent on a fork of Atmosphère, not the official release.
- not clear how long it will be supported for
- Works with Blawar’s Tinfoil (subjective)
- Pros:
More Q/A might be added here based on user's recurrent questions found on GBAtemp.
Disclaimer
This thread is purely meant to be informative. I'm in no way forcing users into using one boot method of CFW or configuration over another!
Users are free to use the booting and patching method they want now that they (hopefully) understand their choices better.
PLEASE DO NOT FIGHT OR ARGUE TO KNOW WHICH VERSION OF CFW OR CONFIG IS SUPERIOR OR START DEV WAR IN THIS THREAD.
Keep it civilized and helpful, answer user's concerns and provide neutral information. Other users only want their titles installed and don't care whether you hate or prefer one developer or one CFW over another!
If you spot any error in this guide, or any new update or changes to mention, please let me or Itsuki know about it.
Thanks
Special thanks to @Itsuki235 for your help on writing and fixing this guide.
Last edited by Cyan,
, Reason: Added new URLs