Switch 2: data gathering for possible modchip attack vectors

[The Real Jdbye]

I "think" you missed the point. He's trolling, and it looks like he succeeded.

"This will just kill off 3rd party developer support and we will get lack luster Nintendo games"

Typically on Nintendo consoles the most popular games are the ones made by Nintendo, followed by a ton of 3rd party games, many of which are "lack luster" shovelware. Especially if you look through their eShops.

It was still important to mention because a lot of people actually believe that, including a lot of the people who would be reading this thread.

 

[xbmcuser]

When has that ever been the case? The Wii had drivechips available roughly a year after release and it was extremely successful. Some early consoles like the PSX had almost no security and were very successful. The PSP was only successful because it was easily hackable. Piracy killing support is a myth.

Err... Dreamcast piracy, nearly killed Sega the company. it was so rife people would sell the disc on the streets and market here.

Sega never produced a new console afterwards

 

[linuxares]

Err... Dreamcast piracy, nearly killed Sega the company. it was so rife people would sell the disc on the streets and market here.

Sega never produced a new console afterwards

The Saturn killed Sega. The Dreamcast didn't get any sales since people didn't trust Sega.

 

[l7777]

it's known that normal SD cards won't work it uses micro SD express cards (pretty sure express cards are/can be encrypted)

Post automatically merged: Apr 3, 2025

also thanks google AI for my answer

No, microSD Express cards are not inherently encrypted, but some manufacturers offer cards with built-in encryption features, such as AES 256-bit, allowing users to password-protect their data.

unless nintendo forces encryption on format (which i believe can be illegal here (similar to ransomware)

You can be assured that the sd card will be encrypted as there is a requirement to connect to the internet when first using a card. The data on the card will likely be looked at as simply an extension of the internal storage and as such most certainly be encrypted. Nothing illegal about encrypting their data. I'm pretty certain most devices that allow external storage to be used behave the same.

 

[MrQQ]

This thread is pointless and purely speculation until its released - You have zero idea what software it will run or what security it implements as it isnt released yet.

 

[xbmcuser]

The Saturn killed Sega. The Dreamcast didn't get any sales since people didn't trust Sega.

Utopia boot disc killed Sega

 

[Dust2dust]

If they would quit relying on SD cards, that would close an entire avenue to load payloads from, dump nand to, etc. Making it far more inconvenient to hack the system. But Nintendo just loves their systems getting hacked, since they keep including SD card slots...

But how else would you expand the storage? 256 GB will fill up fast for those people who buy lots of games. Would you suggest they should use an overpriced proprietary card, like Sony was doing with the PSP and Vita?

 

[chrisrlink]

the switch didn't need to be hacked switch 2 nintendo is basicly asking for it due to their greed

 

[Jayro]

But how else would you expand the storage? 256 GB will fill up fast for those people who buy lots of games. Would you suggest they should use an overpriced proprietary card, like Sony was doing with the PSP and Vita?

Either that, or give it decent storage at launch like 1TB. At least then the high price would be worth it.

Another method would be to use a proprietary filesystem like the Wii U, Xbox, and PS3/4 does. Then users could still use MTP over USB to get their photos and stuff.

 

[Dust2dust]

Either that, or give it decent storage at launch like 1TB. At least then the high price would be worth it.

Another method would be to use a proprietary filesystem like the Wii U, Xbox, and PS3/4 does. Then users could still use MTP over USB to get their photos and stuff.

Proprietary file system seems like a good idea (from Nintendo's side, not ours). I wonder what kept them from doing it with the Switch?

 

[Jayro]

Proprietary file system seems like a good idea (from Nintendo's side, not ours). I wonder what kept them from doing it with the Switch?

Might have been a time restraint, who knows.

 

[Deviant_Raven]

I wonder if I should get a micro sd express card for launch and connect online and activate it before putting this thing away.

Really good question.
Been thinking about that also.

 

[Prof0nWear]

The system is very likely to function in the same way that the original switch did, heck the whole motherboard is essentially designed the same way.

Look at the Switch 2 menu, it's almost identical to the original switch, thus the software will very likely also be very similar along with additional software level protection e.g. Hypervisor.

The issue that everyone needs to come to terms with is that the APU (CPU+GPU) will most likely have removed the RST and CPU (Post) lines during manufacturing.

Look at the OLED switches, they Dat 0 point was even unexposed under the FLASH NAND which required a flex adapter, no different to a post adapter for the 360, but you have to appreciate that there will likely be attempts at board level to hide / remove easy access to these points; and also disabling them at manufacture.

Nintendo will have learned from their previous mistakes, they aren't going to just let you make another Picofly style chip.

This means that hacking this thing really isn't going to be very easy, at least from a RGH style of approach.

 

[BoxNinPlay]

I hope there is no homebrew or piracy for at least 18 months.
This will just kill off 3rd party developer support and we will get lack luster Nintendo games

Don’t worry, personally I think we’ll see something decent at least 24 months later, and unfortunately it will be some kind of open heart surgery on your switch 2, so you better practice your surgical skills well, you have 2 years to learn, or go find someone you trust, for example on switch 1 I tried and killed my new first one, I still have it disassembled piece by piece, it was a Zelda Oled, then I bought a second one and I had to trust someone I don’t know, but at least it did the job it was supposed to do, I don’t know if he changed any parts or whatever, but at least the switch is responding, good luck with that.

 

[Xitrial]

I'm just really more intrested in how they will manage to hack it, the journey, not that much in using it.

For everyone else buy one, store it, and don't jump into the first hack that is released, many times it's improved with time or a better one releases.

 

[SciresM]

Hi all,

since a repeat of the Nvidia RCM blunder from the switch v1 is extremely unlikely, any permanent unsigned code execution on the Switch 2 is very likely to happen through some sort of modchip, if at all.

We can assume that the private keys required to create signed blobs of code will remain an unbroken secret deep within the Nintendo vault.

(brief history for reference)
On the switch (1), the modchips (sx, hwfly, instinct, picofly) work through hooking into the communication between the CPU and eMMC, and also the power supply of the CPU. The power button on the switch enables the 3.3v rail of the system which turns the modchip on, and the chip immediately activates the RST line to keep the switch CPU halted. While keeping RST high, the modchip overwrites the boot0 of the eMMC with its own (unsigned) sd-loader. Then it lowers RST to let the CPU initiate boot, listens on the CMD line as a reference point for timing, and then triggers a MOSFET that drops the supply voltage to the CPU with perfect timing to make it skip execution of the boot0 signature check. The modchip triggers RST and makes the system reboot over and over and tries different timings for the voltage glitch until it succeeds and the CPU executes the unsigned sd-loader.

Now, starting with a similar approach as a base point for Switch 2, we know from various leaks that the Switch 2 no longer uses an eMMC - it uses UFS storage, more specifically a 256GB UFS3.1 chip from Kioxia. Model number THGJFGT1E45BAIL
While having a completely different electrical interface, this chip happens to come in the same BGA153 packaging as the eMMC from Switch 1.
We can spot the new UFS chip in the leaked pcb photos:

View attachment 491610

Looking at the pinout of BGA153 UFS chips, there are a few points that look like what a modchip would need to hook into:

View attachment 491611

Thoughts:
- Unlike the eMMC which uses dat0-7 for both reading and writing, UFS has separate channels for read and write, with two points for each channel. Assuming the modchip might also need to read something from the UFS, we would need to hook into Din0-t (H1), Din0-c (H2), Dout0-c (K1), Dout0-t (K2). There is also a separate "lane" to achieve higher speeds (D(in/out)1), similar to the eMMC dat1-7 points, which the modchip should not need to bother with.
- The CLK point (H1) works the same way as on the eMMC and will probably be used.
- The UFS storage is also connected to the RST line that is used to keep CPU halted on the switch 1. This line will most likely need to be severed with both sides connected to the modchip, since the modchip will need to manipulate the UFS contents while keeping the CPU halted.

Assuming Nintendo have learnt their lesson, these lines will most likely be hidden deep within the layers of the mainboard PCB without any accessible debug points. Since some of the pins the chip will need to access are not along the outer edge of the BGA153 layout, a variant of the "slide-under dat0 adapters" will not be possible either.
The best approach for interfacing will most likely be an interposer PCB, similar to the one designed for the switch 1 eMMC by @abal1000x , but with a different shape to accomodate the shape of the frame around the UFS chip, and obviously with different pins broken out. The interposer could conveniently handle the severing of RST and expose both ends of the line as points on the interposer PCB. The layout could be something like this:

View attachment 491612

What remains to be seen is whether the Tegra T239 CPU is susceptible to voltage glitching attacks. It's likely Nvidia will have made attempts at protecting against it - the question is if they've thought of everything from every angle. Time will tell.

Got more discoveries or information to share? Thoughts? Agree? Disagree? Let's pool our resources, and with some luck someone will read this thread and go "aha!" at a not too distant point in the future.

I think people who are expecting voltage glitching attacks to be viable (especially anywhere in the immediate future) are delusional, honestly.

The Switch 2's BPMP may or may not have DCLS, but let's assume for purpose of argument that it doesn't.

Anybody talking about voltage glitching just has not studied the boot flow: https://docs.nvidia.com/jetson/arch...R/BootArchitecture/JetsonAgxOrinBootFlow.html

Conventional glitching attacks on NX (and Mariko) pwn the BPMP, by making it accept a different public key. So, okay, let's say you replicate that attack verbatim, magically.

You've now pwned the BPMP. This gets you *nothing* on Switch 2, because all the BPMP does is handover to the PSC ("Platform Security Controller"), a custom NV-RISCV chip responsible for all actual cryptographic stuff/security on the platform.

You can't start the ccplex. You can't get any keys to decrypt anything. You could dump the bootrom, if you do a double glitch, probably. But that doesn't help you in any capacity, because unlike on NX, on the Switch 2 the whole chain of trust is designed around an insecure BPMP that happens to be secured anyway.

You can think of it as like when they added TSEC in 6.2.0 on the Switch, except this is baked in from the get-go, and NV-RISCV is likely actually secure (they claim formal verification, and I'm skeptical, but I still think it won't have the basic tsec problems). And you have to glitch to even get to that point.

So...yeah. I would tell people not to get their hopes up. You would need to glitch the PSC (completely blindly glitching a custom-architecture processor that NVidia gave hardware conference talks on how they designed to be anti-glitching?) or the ccplex (doesn't get you keys, everything you do there is potentially patchable by a firmware update?).

It's not like Mariko was for the Switch, it's a whole new game.

 

[Prof0nWear]

I think people who are expecting voltage glitching attacks to be viable (especially anywhere in the immediate future) are delusional, honestly.

The Switch 2's BPMP may or may not have DCLS, but let's assume for purpose of argument that it doesn't.

Anybody talking about voltage glitching just has not studied the boot flow: https://docs.nvidia.com/jetson/arch...R/BootArchitecture/JetsonAgxOrinBootFlow.html

View attachment 496438

Conventional glitching attacks on NX (and Mariko) pwn the BPMP, by making it accept a different public key. So, okay, let's say you replicate that attack verbatim, magically.

You've now pwned the BPMP. This gets you *nothing* on Switch 2, because all the BPMP does is handover to the PSC ("Platform Security Controller"), a custom NV-RISCV chip responsible for all actual cryptographic stuff/security on the platform.

You can't start the ccplex. You can't get any keys to decrypt anything. You could dump the bootrom, if you do a double glitch, probably. But that doesn't help you in any capacity, because unlike on NX, on the Switch 2 the whole chain of trust is designed around an insecure BPMP that happens to be secured anyway.

You can think of it as like when they added TSEC in 6.2.0 on the Switch, except this is baked in from the get-go, and NV-RISCV is likely actually secure (they claim formal verification, and I'm skeptical, but I still think it won't have the basic tsec problems). And you have to glitch to even get to that point.

So...yeah. I would tell people not to get their hopes up. You would need to glitch the PSC (completely blindly glitching a custom-architecture processor that NVidia gave hardware conference talks on how they designed to be anti-glitching?) or the ccplex (doesn't get you keys, everything you do there is potentially patchable by a firmware update?).

It's not like Mariko was for the Switch, it's a whole new game.

To have SciresM to respond here is nothing short of thank you worthy.

Thank you firstly SciresM for everything you've done for this scene and secondly for responding here.

I do have a few questions if I may.

Obviously glitching is is almost likely completely unfeasible.

1) Obvious goals here would be to find a userland/kernel exploit, which would allow homebrew, which sadly will always be patched, the goal as most want is piracy, I do not as you do not also, want piracy... is there any known flaws in the current HorizonOS code that you know of that may be useable for a software based exploit on SW2? I understand obviously it may not be as straight forward as that, but to at least allow some form of homebrew via known exploit as I am assuming that the new horizonOS for SW2 will likely be based off of the same NX horizon code...

2) Do you know of any other additional security implementations that the SW2 has that the NX does not?

3) SW2 uses a translation layer to essentially emulate SW1 games, do you think something like mig-flash now that the NX Lotus cart encryption has been cracked that there could be some movement with an exploit via this route? again I understand Nintendo may have a work around for this these kinds of products for obvious reasons.

4) What would hypotheses will be the entry point into a hacked (homebrewed) SW2 be?

5) Will you be looking into hacking the SW2?

And lastly thank you, as someone with such a interest in hacking, I wish I could learn more deeply as to what you know from someone like you!

 

[whitesword7]

I hope there is no homebrew or piracy for at least 18 months.
This will just kill off 3rd party developer support and we will get lack luster Nintendo games

L take, I hope there’s hacks on DAY ONE

and don’t worry, everyone will be good boys and girls and only use their legal backups right? right?

 

[Lumpofcoal]

The master has spoken, thank you for the insight even if I struggle to understand the finer technical aspects of it.

Unfortunately, I still expect a bunch of "wHy yoU No mAkE Atmosphere for Switch 2? Get to work pLoZ!" "support requests" to appear on the github come switch 2 release day.

Especially given how the prevalent assumption on the ground seems to be that the two are nearly identical.

 

[BoxNinPlay]

I think people who are expecting voltage glitching attacks to be viable (especially anywhere in the immediate future) are delusional, honestly.

The Switch 2's BPMP may or may not have DCLS, but let's assume for purpose of argument that it doesn't.

Anybody talking about voltage glitching just has not studied the boot flow: https://docs.nvidia.com/jetson/arch...R/BootArchitecture/JetsonAgxOrinBootFlow.html

View attachment 496438

Conventional glitching attacks on NX (and Mariko) pwn the BPMP, by making it accept a different public key. So, okay, let's say you replicate that attack verbatim, magically.

You've now pwned the BPMP. This gets you *nothing* on Switch 2, because all the BPMP does is handover to the PSC ("Platform Security Controller"), a custom NV-RISCV chip responsible for all actual cryptographic stuff/security on the platform.

You can't start the ccplex. You can't get any keys to decrypt anything. You could dump the bootrom, if you do a double glitch, probably. But that doesn't help you in any capacity, because unlike on NX, on the Switch 2 the whole chain of trust is designed around an insecure BPMP that happens to be secured anyway.

You can think of it as like when they added TSEC in 6.2.0 on the Switch, except this is baked in from the get-go, and NV-RISCV is likely actually secure (they claim formal verification, and I'm skeptical, but I still think it won't have the basic tsec problems). And you have to glitch to even get to that point.

So...yeah. I would tell people not to get their hopes up. You would need to glitch the PSC (completely blindly glitching a custom-architecture processor that NVidia gave hardware conference talks on how they designed to be anti-glitching?) or the ccplex (doesn't get you keys, everything you do there is potentially patchable by a firmware update?).

It's not like Mariko was for the Switch, it's a whole new game.

Thank you, SENSEI, for your wise words, we will follow you wherever you go. A KAMIKAZE attack might help???