There are two main “levels” on which exploit releases will target currently (this is a lie; there are four, but the other two simply don’t matter yet).
Full system-level access allows code running in the TrustZone, which implies code running in all lower levels of execution (kernel, userland). This is what you want for “CFW”.
Homebrew support allows you to develop and run native applications on the Switch.
Current, there is confirmation of full system-level access, through TrustZone exploits, for all firmwares up to 4.1.0.
Likewise, homebrew support is publically available on 3.0.0.
Release of full system-level access tools and exploits are expected as development progresses. Priority is on 1.0.0 first.
The tiers for system-level access are as follows, from soonest to latest: 1.0.0; 2.0.0-3.0.0; 3.0.1-4.1.0.
Release of homebrew access tools, development tools, and exploits are targeting 3.0.0.
If you are on 2.0.0-2.3.0, you may upgrade to 3.0.0 at your discretion. 2.0.0-3.0.0 will have further system-level access at the same time, after 1.0.0.
If you are on 1.0.0 we do not recommend upgrading for this as you will be able to get system-level access first.
Q: What about more recent/current firmware?
A: There really is nothing left to do but wait. Don’t update if you can avoid it, or buy an older Switch with older firmware.
3.0.1 and up has NOTHING public so far. 3.x and 4.x are in the running for future TrustZone exploitation, so stay tuned, and do not update from or to 3.0.1 and up, including 4.x.
Remember the mantra! Wait! Don’t Update!!
ROP is a non-functional form of code execution used to bootstrap further exploitation. PegaSwitch uses ROP to pop into ACE.
ACE is Arbitrary Code Execution. This is the “holy grail” of homebrew, and allows one to write programs which run in the Switch.
Horizon/NX, aka HOS, is the Switch OS, a modern, service-based modular microkernel OS. It is derived from the OS on the Nintendo 3DS, Horizon/CTR, which extensive changes and modernization throughout. It is not FreeBSD-based, or based on any known OS/RTOS kernel. It is entirely custom.
Userland is where regular applications on the Switch live.
They are stripped of all but the most essential privileges, and may be limited in temrs of hardware access and capabilities.
When we say Kernel access we’re talking about getting ACE from a fully-privileged context.
This allows for a greatly expanded set of capabilities for homebrew development, system modification, and development capabilities, such as CFW, and patching of system binaries and applications to change their behaviors.
TrustZone is a new concept in the ARM architecture, and Nintendo is using it for the first time on the Switch.
Its job, through “Secure Monitor calls”, or SMCs, is to perform crypto and a small number of system tasks like power management and sleep.
It is necessary to get TrustZone access to dump one’s own keys for off-system crypto, and to bootstrap a custom hypervisor in “EL2”.
/* You are not expected to understand this */ (it isn’t going to be on the test), but it’s still nice to know and will be included here for reference.
The TrustZone runs within a “Secure World”, which is considered, for all intents and purposes, a separate machine from the main OS.
Secure World can have its own operating system, kernel, and userland running within it, but the Switch does not do that; it runs a very simple “Secure Monitor” on top of EL3.
The Hypervisor level is entirely unused on the stock Switch, currently. It sits below TrustZone, but still above the kernel and system. It allows one to virtualize the OS underneath it, which may be useful for close-to-metal development, emulation of the Switch and other systems on the Switch, and booting other OSes such as Linux or Android without interfering with the Horizon system.
Going a bit deeper, Exception levels, or privilege levels, in order from least to most privileged, refer to different “planes” of system access, underneath which restrictions can be managed.
These levels are Userland (EL0), Kernel/Supervisor (EL1), Hypervisor (EL2, unused), and TrustZone, or “Secure Monitor” (EL3).
If you want to learn more about ARM hypervisors and the trust platform ARMv8 provides, feel free to ask. More reference manuals will be linked to here in due time.
The only way to bypass the fuse checks would be to gain arbitrary code execution before package1 (an early bootloader) attempts to check them, or to glitch the check with fault-injection. Both of which are Hard Problems™. stuckpixel said it best: “basically, if you have the ability to modify how many fuses are expected, then you have the ability to just sign your own FW.”
More information about the fuses
Q: What are the fuses?
A: The Switch has a range of memory embedded in the SoC which is only writable once per bit.
They are called fuses because, electronically, that’s how they function. They conduct until “blown” with a high current, and then they don’t.
These fuses are addressed as registers in the memory space.
Q: What are they used for?
A: In the factory, they are set with console-specific keys and data, as well as factory configuration (am I a devkit? what kind of hardware am I? what revision?)
This data remains static, and does not change after the device is shipped. However, there is a “vendor-specific” range of fuses which can be changed on a shipped device.
On the Switch, this range of fuses counts the number of system software updates installed to prevent you from installing a lower version of the system software. This is part of the Anti-Downgrade protection in the Switch.
(For further reference, see this)