First off: outside of very early firmwares, the original Switch doesn’t have any exploitable kernel bugs. There are entry points, but nothing that hands you a full custom firmware. So why does hacking still happen? Because Nvidia screwed up.
Early Switch units became infamous because a simple hardware trick could get you into the device. That “paper-clip” entry point wasn’t some accidental miracle: the Tegra X1 has a recovery mode Nintendo and Nvidia actually use for servicing and flashing. Hackers found two big problems there: recovery mode didn’t check how big a payload was (so it could overflow), and memory wasn’t cleared. Those flaws let attackers run code at the very earliest stage, before Nintendo’s software even starts, and it was devastating. Nintendo fixed it in later chips and changed the USB stack, so that particular exploit (RCM) is a non-starter on newer hardware and won’t be coming back on Switch 2.
The other big class of attacks is voltage glitching. The idea is simple: briefly disturb the CPU’s power so it skips an instruction, and if you hit the right instruction, you can skip crucial checks like signature verification. That’s why early modchips could halt the CPU, inject their own boot code, and then glitch the power at just the right moment to bypass signed checks, essentially re-creating the powerful chain that RCM enabled. With the T239 platform, though, Nvidia and Nintendo put a lot of engineering into stopping both RCM-style problems and glitching.
Software exploits look unlikely, NS2 uses the same kernel and firmware lineage as NS1, and RCM-style bugs aren’t present on T239. Voltage glitching faces two major, practical hurdles. The first is dual-core lockstep: two cores run the same instructions and a comparator checks they match. If one core is fudged, the chip notices and locks down. To beat that you’d need to glitch both cores simultaneously with extreme precision, not easy and not reliable. The second is that the boot/power-management processor is now explicitly untrusted on NS2: anything you could do on that processor won’t let you initialize the rest of the system. You might be able to dump something interesting, but it won’t get you to a usable custom firmware.
That basically leaves two other, much harder targets: NVRISCV (Nvidia’s mostly undocumented security processor) and CCPLEX, the cluster of CPU cores themselves. NVRISCV was designed to resist glitching and to be a sealed black box; attacking it would be like finding a needle in a haystack. CCPLEX attacks would be thwarted in theory by firmware updates and other protections. In short, there’s no obvious silver bullet for NS2, whatever breaks it is likely to be far more sophisticated than what we saw with the 360 hypervisor.
Here is a video from NVIDAI where they talk about this:
Early Switch units became infamous because a simple hardware trick could get you into the device. That “paper-clip” entry point wasn’t some accidental miracle: the Tegra X1 has a recovery mode Nintendo and Nvidia actually use for servicing and flashing. Hackers found two big problems there: recovery mode didn’t check how big a payload was (so it could overflow), and memory wasn’t cleared. Those flaws let attackers run code at the very earliest stage, before Nintendo’s software even starts, and it was devastating. Nintendo fixed it in later chips and changed the USB stack, so that particular exploit (RCM) is a non-starter on newer hardware and won’t be coming back on Switch 2.
The other big class of attacks is voltage glitching. The idea is simple: briefly disturb the CPU’s power so it skips an instruction, and if you hit the right instruction, you can skip crucial checks like signature verification. That’s why early modchips could halt the CPU, inject their own boot code, and then glitch the power at just the right moment to bypass signed checks, essentially re-creating the powerful chain that RCM enabled. With the T239 platform, though, Nvidia and Nintendo put a lot of engineering into stopping both RCM-style problems and glitching.
Software exploits look unlikely, NS2 uses the same kernel and firmware lineage as NS1, and RCM-style bugs aren’t present on T239. Voltage glitching faces two major, practical hurdles. The first is dual-core lockstep: two cores run the same instructions and a comparator checks they match. If one core is fudged, the chip notices and locks down. To beat that you’d need to glitch both cores simultaneously with extreme precision, not easy and not reliable. The second is that the boot/power-management processor is now explicitly untrusted on NS2: anything you could do on that processor won’t let you initialize the rest of the system. You might be able to dump something interesting, but it won’t get you to a usable custom firmware.
That basically leaves two other, much harder targets: NVRISCV (Nvidia’s mostly undocumented security processor) and CCPLEX, the cluster of CPU cores themselves. NVRISCV was designed to resist glitching and to be a sealed black box; attacking it would be like finding a needle in a haystack. CCPLEX attacks would be thwarted in theory by firmware updates and other protections. In short, there’s no obvious silver bullet for NS2, whatever breaks it is likely to be far more sophisticated than what we saw with the 360 hypervisor.
Here is a video from NVIDAI where they talk about this:
