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:
Looking at the pinout of BGA153 UFS chips, there are a few points that look like what a modchip would need to hook into:
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:
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.
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:
Looking at the pinout of BGA153 UFS chips, there are a few points that look like what a modchip would need to hook into:
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:
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.
️
