SWITCH-Basic: Nintendo Switch Security
- SWITCH-Basic is a comprehensive overview of Nintendo Switch security that defines its architecture, trust model, and multi-stage exploit chain from userland ROP to TSEC high-security compromise.
- The methodology combines software reverse engineering with trusted ROM analysis to uncover vulnerabilities in boot processes, IPC protocols, and hardware root of trust mechanisms.
- Insights emphasize that robust defense-in-depth, fault resistance, and strict cryptographic practices are essential to protect embedded systems against sophisticated attacks.
SWITCH-Basic denotes a cohesive overview of Nintendo Switch security centered on the architecture, trust model, analysis methodology, and attack chain described in “Methodically Defeating Nintendo Switch Security” (Roussel-Tarbouriech et al., 2019). In that account, the Switch is presented as a secure embedded system built around Nvidia’s Tegra X1 SoC, Horizon’s microkernel-based software stack, TrustZone separation, and a dedicated security co-processor, TSEC. The paper’s central result is not a single exploit but a multi-stage defeat of the platform’s security assumptions, progressing from userland Return-Oriented Programming (ROP), through service-policy weaknesses and privileged service misuse, to compromise of the hardware root of trust and eventual ROP code execution in TSEC’s high-security mode (Roussel-Tarbouriech et al., 2019).
1. Hardware and protection domains
The Nintendo Switch is built on Nvidia’s Tegra X1 SoC. Its relevant processor complexes are the CCPLEX, the BPMP, and the TSEC. The CCPLEX consists of ARM AArch64 application cores running Horizon OS in the “Normal World.” The BPMP, or Boot and Power Management Processor, is the first core to run after reset; its immutable BootROM, also called BPMP-FW in Nvidia documentation, implements secure boot and recovery logic. TSEC, the Tegra Security Co-Processor, is a Falcon microcontroller-based security engine responsible for key derivation, firmware authentication, and access to hardware-protected secrets (Roussel-Tarbouriech et al., 2019).
TSEC’s security model is structured around Falcon execution modes: Non-Secure (NS), Light Secure (LS), and Heavy Secure (HS). High-security mode grants full access to the cryptographic hardware, protected registers, and secret memory. HS code therefore has privileged operations, including access to device-unique key material and “secret-marked” pages, whereas NS cannot read many registers and memory-mapped regions. In the paper’s attack narrative, HS mode is the decisive boundary because seizing execution there converts architectural privilege into direct access to hardware secrets.
This partitioning illustrates Nintendo’s defense-in-depth strategy. Horizon isolation constrains ordinary software; TrustZone separates Secure World from Normal World; and TSEC functions as a co-processor that anchors key derivation and firmware authentication. A plausible implication is that the platform’s security was intended to remain robust even if a conventional software component failed, provided the root-of-trust path and TSEC staging logic remained intact.
2. Secure boot, key derivation, and the root of trust
The hardware root of trust begins in BPMP BootROM. BootROM uses on-chip hardware secrets, including fuses and device-unique keys, to verify and decrypt early boot artifacts such as Package1 and its loader. Fuses and device-unique keys ensure per-console uniqueness, so keys are not shared across devices. The boot flow described in the paper is BPMP BootROM → Package1Ldr → PK11, which contains warmboot, NX-Bootloader, and the Secure Monitor → Horizon kernel and KIPs → boot2 → system servers → qlaunch (Roussel-Tarbouriech et al., 2019).
Authenticity and integrity depend on verification at each stage and on protection of the relevant keys. The account gives representative formulas for the cryptographic mechanisms involved: a conceptual RSA signature relation, ; AES-CTR encryption, ; and AES-CMAC, . Early firmware packages such as Package1 and PK11 are encrypted and authenticated. TSEC firmware stages may be both signed and encrypted, and AES-CMAC is used inside TSEC because Falcon operates in a constrained environment with integrated AES acceleration.
Chain-of-trust enforcement also depends on device state. BootROM reads PMC registers to decide cold boot versus warmboot, and package1ldr decrypts and verifies PK11 before handing control onward. The intended security property is straightforward: unsigned or tampered payloads should not be accepted. The paper’s broader significance lies in showing that this assurance can fail if any pre-authentication parsing, metadata handling, or privileged copy path is flawed before verification completes.
3. Horizon OS, services, and the software attack surface
Horizon uses a microkernel design with strong isolation. Userland applications run in sandboxes with ASLR and NX/WX memory policies. System functionality is exposed through IPC to services implemented by system service processes, and access is mediated by the central Service Manager, sm, together with per-title signatures and metadata. Critical services include fs, ldr, ns, pm, and sm itself (Roussel-Tarbouriech et al., 2019).
Userland interacts with services through named ports and a marshalled IPC protocol with commands, handles, and buffer descriptors. The paper emphasizes that service security depends on two assumptions: first, that endpoints validate inputs correctly; second, that signed metadata preserves least privilege. In practice, the researchers used memory dumps and symbol discovery to reveal service names and API endpoints, then reverse engineered the IPC protocol, including what they describe as the “madness” of descriptors and bit-shuffling. Fuzzing against service ports then exposed crashes and logic flaws.
The software entry point came from the WebKit-based browser applet exposed through the WiFi captive-portal path. The researchers audited upstream commits linked to security fixes, reproduced instrumented environments for debugging, and exploited a use-after-free in FrameTree unload handlers, nicknamed detachSecurity(), to obtain memory corruption. Because the browser applet lacked JIT, the resulting code-execution technique was ROP via overwritten function pointers. From there, the paper identifies three conceptually distinct software exploit primitives: userland ROP; bypass of service-manager policy by abusing an uninitialized PID in sm:h; and privileged service misuse, including use of the fsp-ldr handle after a loader denial of service, to dump binaries and widen visibility into sysmodules.
A common misconception is that this stage alone constituted a complete compromise. The paper instead presents it as necessary but insufficient. Software analysis provided general architectural understanding and substantial leverage over system software, but defeating the hardware root of trust required a distinct hardware-based methodology (Roussel-Tarbouriech et al., 2019).
4. Dual analysis methodology: software reverse engineering and trusted ROM analysis
The work is explicitly organized around two distinct analysis procedures. The software-based procedure sufficed for reverse engineering userland and operating system services and for building a general architectural understanding of the Switch software stack. The hardware-based procedure was devised to analyze trusted bootstrap code in ROM and was essential for defeating the hardware root of trust (Roussel-Tarbouriech et al., 2019).
The hardware rationale was that pre-authentication boot paths run before operating-system mitigations exist. The researchers therefore sought to understand and subvert BootROM behavior, especially recovery mode USB handling. At a high level, the paper describes voltage glitching of a Tegra X1 platform to dump BPMP BootROM, analysis of the recovery mode USB stack, and construction of an emulator for BootROM logic in HLE/LLE so that fuzzing effort could be focused on input paths before cryptographic checks. The paper does not provide operational details for exploitation, and it states that missing details are intentional in light of responsible disclosure and NDA constraints on prior Tegra X1 research.
This two-pronged structure matters methodologically. Software reverse engineering exposed service layouts, privilege boundaries, and IPC semantics. Trusted ROM analysis exposed the earliest code paths, including paths that could be reached before any signature check. This suggests that for secure embedded systems, architectural understanding of higher layers and direct study of immutable boot code are complementary rather than interchangeable.
5. Attack chain and the compromise of TrustZone and TSEC
The attack chain presented in the paper is ordered and cumulative. It begins with userland ROP obtained through the captive-portal WebKit vulnerability, with PegaSwitch and CVE-2016-4657 (“Pegasus” on AArch64) accelerating ROP availability. It then escalates through a Service Manager policy bypass: by skipping Initialize, the PID remains 0, and PIDs below 8 had unrestricted service access, bypassing cryptographically enforced service access lists managed by sm. A further escalation abused fsp-ldr: crashing ldr released its exclusive fsp-ldr handle, after which code modules could be dumped, exposing sysmodules more broadly (Roussel-Tarbouriech et al., 2019).
The paper then describes the break of the hardware root of trust via a BootROM memcpy bug in the pre-crypto USB path. An attacker-controlled size parameter reached memcpy, enabling a buffer overflow and code execution in BootROM before any signature check. Because ROM lacked ASLR, NX, and stack cookies, this yielded privileged execution at the earliest trust anchor. From there, the researchers analyzed TrustZone warmboot handling. In pre-2.0.0 firmware, Secure Monitor state was saved encrypted with a MAC in DRAM, while the MAC persisted in PMC registers accessible from userland; combined with a Security Engine verification gap, this permitted restoration of attacker-controlled TZRAM and keys. After 2.0.0, PMC access was tightened, but AHB-DMA remained accessible from the CCPLEX kernel, allowing BPMP exception vector overwrite.
The later and more technically specialized stage concerned TSEC high-security compromise in the 6.2.0 and 7.0.0 era. TSEC firmware staging changed from Boot → KeygenLdr → Keygen to Boot → SecureBootLdr → KeygenLdr → Keygen → SecureBoot. Nintendo added SecureBootLdr and SecureBoot in 6.2.0, generated new root keys, and sought to prevent “redirect back to trusted code” tricks; 7.0.0 further enabled TSEC SMMU bypass and updated TSEC root keys. The paper’s breach concept focused on an unauthenticated metadata blob for TSEC stages, specifically size and CMAC metadata. In KeygenLdr, the copy could be steered into a stack smash, after which a residual verified CMAC could be leveraged to re-enter verification with an attacker-controlled payload, achieving ROP within TSEC’s HS mode (Roussel-Tarbouriech et al., 2019).
Once HS execution was obtained, TSEC’s secret-page protections became directly relevant. Secret pages manifested readback protection by returning 0xDEAD5EC1, and the exploit timing arranged ROP after Keygen decryption but before secrets became unrecoverable. The paper’s central technical lesson is that symmetric integrity checking via AES-CMAC is not itself the weak point; rather, unauthenticated metadata and stack-safety lapses in privileged staging code allowed the verification flow to be steered after trust had already been partially established.
6. Mitigations, interpretation, and broader lessons
Nintendo’s responses were incremental. Firmware 2.0.0 tightened PMC access to mitigate warmboot MAC tampering, though AHB-DMA access from CCPLEX kernel still allowed BPMP exception vector rewrites. Firmware 6.0.0 mitigated vulnerabilities disclosed privately, including “nvhax” in the broader chain. Firmware 6.2.0 introduced SecureBootLdr and SecureBoot in TSEC, generated new root keys, and blocked trivial redirection to trusted code. Firmware 7.0.0 enabled TSEC’s SMMU bypass to defeat memory virtualization tricks and updated TSEC root keys again. The community response included “Sept,” described as conceptually forging an AES-CMAC over a custom PK11 to satisfy SecureBoot checks while performing in-place key derivation and scrambling to keep the environment consistent for homebrew (Roussel-Tarbouriech et al., 2019).
The paper’s general lessons are explicit. Defense in depth requires auditing privileged code paths such as SM, NS, FS, and LDR, together with IPC handlers. Pre-authentication ROM paths are high-risk and should be simplified and hardened. Fault resistance matters: glitch and fault-injection countermeasures, post-boot measurements, and protection of DMA-capable paths are all relevant. Cryptographic hygiene also matters, especially when symmetric integrity mechanisms protect firmware in constrained environments; if metadata can influence privileged copy or control flow before it is authenticated, the security argument collapses even if the primitive itself remains sound.
The paper also frames its own scope carefully. Missing details are intentional, and the emphasis is on methodology and architecture rather than operational exploit instructions or code. That framing addresses a recurrent controversy around offensive security publications: whether disclosure facilitates misuse. Here the stated intent is to inform secure embedded system design rather than piracy or harm. In that sense, SWITCH-Basic is best read not merely as a case study in console compromise, but as a study of how microkernel service ecosystems, secure co-processors, warmboot paths, and immutable boot code interact under adversarial analysis (Roussel-Tarbouriech et al., 2019).