Fours years ago, I asked a simple question: Hack a patched switch in 2021? I was 13 at the time, and had little to no idea what I was doing. But Mariko, the V2 ipatched model of the switch, has continued to interest me throughout the years. I’ve continued to research it, and though I’m no expert cryptographer or software engineer, here’s the findings that I have made.
Nintendo’s hardware revision of the Switch from 2019, model HAC-001(-01), run off of the Tegra X1+ chip. It’s a low power variant that supports better battery life and was initially what was cool about it. On the tech side, though, the X1+ also contained some software fixes in the boot code that patched the Fusée Gelée exploit. Fusée Gelée was an exploit where, given my horrible interpretation, a bug in the USB code could cause the Tegra X1 chip in ReCovery Mode (RCM) to provide too much data, and by exploiting this, you could launch a stack smash attack and ultimately write your to the execution stack, causing it to run. The original write up on Fusée Gelée explains it better than I do here.
Tegra X1+ ultimately patched this vulnerability, which sucked. Switches produced after 2019 needed a mod chip in order to be hacked, and RCM just kind of got swept under the rug. It’s still present in Mariko, it just isn’t vulnerable to the stack smash.
I got curious about the system, as I tend to do with random stuff all the time. So I got to reading.
I studied up on the Switch boot process. BootROM, burned onto the SoC, verifies boot0, which passes on to boot1, which passes on to the bootloader. Fairly simple stuff, right? That’s kind of how computers work.
BootROM specifically verifies the signature of boot0, which according to my understanding of the Fusée Gelée document, is likely signed using RCA-2048. RCM payloads also need to be verified with an RCA-2048 or AES-CSM signature. This is actually what caught my interest. To verify these payloads, they need to verify the key in BootROM to run. Both boot0 and RCM. Maybe RCM remains an entry point. Just with the valid signatures.
So, I’m not an expert cryptographer, but I dove into researching RCA vulnerabilities.
Back on the PS3, an issue with reusing numbers in their random number generation caused a security hole in the system wherein two keys could be compared, and through a little algebra, actually suss out the private key. A legendary leak. My smallest and simplest idea is comparing boot0 codes to see if there’s a random number generation flaw. It’s highly unlikely, and likely tried before, but worth noting.
Recent research from Keyfactor suggests that around 1 in 200 keys, give or take a few, are vulnerable to refactoring with minimal resources. Another flaw in RSA that could potentially affect millions of keys. Could the Switch keys be one of them? Who knows. Why not experiment? This one is also unlikely, but worth noting.
CVE-2017-15361 has particularly tickled my fancy. A vulnerability in RSAlib allows for something called the ROCA vulnerability. This particular attack is known to work against RSA-2048, likely how Nintendo signed their key for boot0. The research team that discovered this vulnerability also estimated that 1 in 4 Trusted Platform Module devices are affected by this issue. Even better, this is when the Nintendo Switch was actually released. 1 in 4 is the same chance of a Balatro Wheel of Fortune Tarot triggering. I consider that good enough to look into.
In 2021, Nvidia published 8 vulnerabilities affecting Tegra hardware, including X1 and X1+. These exploits range from being able to analyze microcode to dumping unscrubbed registers to accessing debugging. These all require root access, but root access exists. Modchipped users of Mariko Switches have that administrative power. I’m not entirely sure what that means, per se, but I think valuable information could be acquired via these exploits, which are known to affect Tegra X1 (Erista) and Tegra X1+ (Mariko). Read more here.
Provided I’m entirely incorrect and it’s AES, or provided an RSA vulnerability exists in this tense, perhaps the AMD microcode vulnerability published in March of this year is worth taking a look at. Considering CVE-2021-23201 and 23219 are microcode exploits that I mentioned earlier, users with mod chips could be able to use this microcode exploit to gain access to information for acquiring the private key.
Acquiring the private key that signed boot0 would make RCM a valid entry point for every model of Nintendo Switch (except Lite, which requires some finicking to get into RCM.) Why? Because we could sign our payloads with Nintendo’s private key and run them as though they are valid Nintendo code. Boot0 has a write-protect fuse on it as well, meaning that nothing in it can ever change. Signing payloads with this key makes it the holy grail of Nintendo Switch homebrew, permanently unlocking the bootloader. From there, it’s only a simple matter of using hekate and Atmosphère to fully jailbreak that John, and we’re home free.
I am not a cryptographer nor am I a software engineer, just a homebrew enthusiast with a lot of time on his hands. But I lack the resources to actually try exploiting any of these vulnerabilities. If anyone on this site thinks that these methods are feasible, feel free to check, and keep me in the loop on your progress as well. I’m very interested in seeing the day when the Mariko unit is finally softmoddable. (Which is a when, not an if, because of quantum computing every reaches a high enough state, Shor’s algorithm will obliterate all RSA encryption.)
Let me know what you think of my findings, and whether or not these have been tried or if my information is entirely wrong.
Addon: given that the source code for Mariko is available online (don’t worry mods I will not link it) including the code for boot0 and the cryptography generation, is it feasible to reverse engineer or craft microcode to exploit the 23201 and 23219 vulnerabilities? Who knows. I don’t. Maybe though…
Nintendo’s hardware revision of the Switch from 2019, model HAC-001(-01), run off of the Tegra X1+ chip. It’s a low power variant that supports better battery life and was initially what was cool about it. On the tech side, though, the X1+ also contained some software fixes in the boot code that patched the Fusée Gelée exploit. Fusée Gelée was an exploit where, given my horrible interpretation, a bug in the USB code could cause the Tegra X1 chip in ReCovery Mode (RCM) to provide too much data, and by exploiting this, you could launch a stack smash attack and ultimately write your to the execution stack, causing it to run. The original write up on Fusée Gelée explains it better than I do here.
Tegra X1+ ultimately patched this vulnerability, which sucked. Switches produced after 2019 needed a mod chip in order to be hacked, and RCM just kind of got swept under the rug. It’s still present in Mariko, it just isn’t vulnerable to the stack smash.
I got curious about the system, as I tend to do with random stuff all the time. So I got to reading.
I studied up on the Switch boot process. BootROM, burned onto the SoC, verifies boot0, which passes on to boot1, which passes on to the bootloader. Fairly simple stuff, right? That’s kind of how computers work.
BootROM specifically verifies the signature of boot0, which according to my understanding of the Fusée Gelée document, is likely signed using RCA-2048. RCM payloads also need to be verified with an RCA-2048 or AES-CSM signature. This is actually what caught my interest. To verify these payloads, they need to verify the key in BootROM to run. Both boot0 and RCM. Maybe RCM remains an entry point. Just with the valid signatures.
So, I’m not an expert cryptographer, but I dove into researching RCA vulnerabilities.
Back on the PS3, an issue with reusing numbers in their random number generation caused a security hole in the system wherein two keys could be compared, and through a little algebra, actually suss out the private key. A legendary leak. My smallest and simplest idea is comparing boot0 codes to see if there’s a random number generation flaw. It’s highly unlikely, and likely tried before, but worth noting.
Recent research from Keyfactor suggests that around 1 in 200 keys, give or take a few, are vulnerable to refactoring with minimal resources. Another flaw in RSA that could potentially affect millions of keys. Could the Switch keys be one of them? Who knows. Why not experiment? This one is also unlikely, but worth noting.
CVE-2017-15361 has particularly tickled my fancy. A vulnerability in RSAlib allows for something called the ROCA vulnerability. This particular attack is known to work against RSA-2048, likely how Nintendo signed their key for boot0. The research team that discovered this vulnerability also estimated that 1 in 4 Trusted Platform Module devices are affected by this issue. Even better, this is when the Nintendo Switch was actually released. 1 in 4 is the same chance of a Balatro Wheel of Fortune Tarot triggering. I consider that good enough to look into.
In 2021, Nvidia published 8 vulnerabilities affecting Tegra hardware, including X1 and X1+. These exploits range from being able to analyze microcode to dumping unscrubbed registers to accessing debugging. These all require root access, but root access exists. Modchipped users of Mariko Switches have that administrative power. I’m not entirely sure what that means, per se, but I think valuable information could be acquired via these exploits, which are known to affect Tegra X1 (Erista) and Tegra X1+ (Mariko). Read more here.
Provided I’m entirely incorrect and it’s AES, or provided an RSA vulnerability exists in this tense, perhaps the AMD microcode vulnerability published in March of this year is worth taking a look at. Considering CVE-2021-23201 and 23219 are microcode exploits that I mentioned earlier, users with mod chips could be able to use this microcode exploit to gain access to information for acquiring the private key.
Acquiring the private key that signed boot0 would make RCM a valid entry point for every model of Nintendo Switch (except Lite, which requires some finicking to get into RCM.) Why? Because we could sign our payloads with Nintendo’s private key and run them as though they are valid Nintendo code. Boot0 has a write-protect fuse on it as well, meaning that nothing in it can ever change. Signing payloads with this key makes it the holy grail of Nintendo Switch homebrew, permanently unlocking the bootloader. From there, it’s only a simple matter of using hekate and Atmosphère to fully jailbreak that John, and we’re home free.
I am not a cryptographer nor am I a software engineer, just a homebrew enthusiast with a lot of time on his hands. But I lack the resources to actually try exploiting any of these vulnerabilities. If anyone on this site thinks that these methods are feasible, feel free to check, and keep me in the loop on your progress as well. I’m very interested in seeing the day when the Mariko unit is finally softmoddable. (Which is a when, not an if, because of quantum computing every reaches a high enough state, Shor’s algorithm will obliterate all RSA encryption.)
Let me know what you think of my findings, and whether or not these have been tried or if my information is entirely wrong.
Post automatically merged:
Addon: given that the source code for Mariko is available online (don’t worry mods I will not link it) including the code for boot0 and the cryptography generation, is it feasible to reverse engineer or craft microcode to exploit the 23201 and 23219 vulnerabilities? Who knows. I don’t. Maybe though…
Last edited by Deleted member 535703,
