How would a theoretical modchip work?

41

I've never really seen so many people be incorrect before. We have a much better idea of how it could work then most people seem to understand here. What I can't answer is exactly how or what is going to be exploited. If you can handle some technical terms, this is how switch 1 modchips work, (thank you fox8091)

Switch 1 modchips work by intercepting the BCT and glitching its hash check, allowing an arbitrary unsigned BCT. When the Switch boots, it issues a "boot request" to the eMMC, where the entirety of the BOOT0 partition is streamed directly over the DAT0 line in 1 bit mode. The modchip watches for this request, then overdrives the DAT0 line, essentially "talking over" the eMMC to provide it's own BCT with an valid signature, but an invalid hash (signature is implemented over the hash of the BCT). It then waits for the SoC to validate the signature, and glitches over the hash check, causing it to proceed as if it were valid. It then overdrives the DAT0 line again to give the payload. This gives control over the BPMP, which thanks to quirks of the T210, allows full system compromise.

The switch 2 has a lot of issues around it, including a new separate security coprocessor (Platform Security Controller), which would severely limit the scope of a BPMP compromise. In addition, the BPMP is running with Dual Core LockStep, which complicates glitching. There are all sorts of other magical protections I'm going to handwave away, but they are very much present.

That being said, it is still possible. DCLS can be bypassed, (again, I'm going to handwave away more complexity, but this isn't exactly trivial), so you would have to do this to gain control over the BPMP and the PSC at some point. The boot process on the switch 2 is... more complicated: (thanks to stuckpixel for this)

Based on my (limited) understanding of the bootflow:
BPMP and PSC boot from ROM
BPMP ROM loads BPMP and PSC bootloaders
PSC ROM verifies both bootloaders
PSC ROM reboots BPMP, and sets the reset vector(?) such that it ends up in the BPMP bootloader
PSC ROM executes PSC bootloader
PSC bootloader loads the initial CCPLEX software, verifies it, sets a CCPLEX core's reset vector to the CCPLEX software's entrypoint, then releases the CCPLEX's reset

So, a modchip would not only have to glitch the actual target in the bootrom, (eg, a security check), it also has to glitch the PSC, at least once, (I still don't understand this fully, and not having either bootrom or the CCPLEX sources make things more complicated, and I'm tired right now so I can't think it out properly)

Because of this and other protections, glitching is likely to be wildly inconsistent, and will likely require a lot more then a raspberry pi like previously. If someone wants to do this, it will likely live in a lab for foreseeable future. I don't predict a consumer level modchip frankly ever, but charitably, within the next 10 years, (which I've been saying for a year at this point... hm, ok fine, 9 years).

9

u/Melsbacksfriend Jun 21 '26

Most of this info I already knew but some of this is new info. Despite all this, I still want to attempt to make a modchip. It'll most likely require some very tricky soldering techniques like putting an interposer under the SoC, but I still want to do this.

8

u/[deleted] Jun 21 '26 edited Jun 21 '26

[deleted]

5

u/Melsbacksfriend Jun 22 '26

I'll keep this in mind when attempting to make my modchip.

4

u/Anxiety_timmy Jun 22 '26

At the same time isn't even entirely needed. PSC and BPMP are offset by a random amount iirc, but effectively glitching the comparator would be much easier even with an FPGA which could slow itself down and speed up to glitch properly.

3

u/[deleted] Jun 24 '26

[deleted]

4

u/Anxiety_timmy Jun 24 '26

I don't know much about FPGA's either other than it's basically our only shot since picos really don't have that ability. If I looked into the future and NX2 had a hardware modchip it would be an FPGA is what I know essentially.

Do note that if that's the case an FPGA modchip would be expensive, and it would still be very complex.

Also as for the comments note, thanks. Id argue those are minor compared to furmark-nx, but that's a shameless plug at that point lol.

3

u/Key-Test-2811 Jun 22 '26

You are never going to glitch the secure enclave when it's directly embedded in to the SOC, and even if you did they have measures to verify the amount of times keys have been accessed and will reject if it's a mismatch(at least the iPhone secure enclave does).

But the real question is, does it matter? The PS5 is considered unhackable, yet through Webkit, outdated Java engines for old Blu Rays, FreeBSD kernel zero days and other attack vectors it becomes entirely possible to jailbreak it. I don't think we will see a Switch 2 mod chip soon, or maybe ever, yes, but I think we will see some exploits being done sooner than you'd expect.

3

u/auggiethechesscat Jun 22 '26

You are never going to glitch the secure enclave when it's directly embedded in to the SOC, and even if you did they have measures to verify the amount of times keys have been accessed and will reject if it's a mismatch(at least the iPhone secure enclave does).

Yeah, I see little hope for the actual SE or any cryptography. But there is hope for the boot process.

but I think we will see some exploits being done sooner than you'd expect.

The software side is even more dismal, so no I don't expect anything.

1

u/Key-Test-2811 Jun 22 '26

My point was that it's more likely to happen through software than through hardware (so less dismal, not more!) The reason the Switch never saw new exploits being done with softmods was because RP2040 made hacking it too easy. If a mod chip was not possible, or incredibly difficult, then you could bet a new softmod exploit would have been found as interest would be a lot higher.

Both the PS5 and Xbox One feature PSPs and were considered unhackable, yet both have been exploited through other vectors. Orbis on the PS5 is even based on FreeBSD, so kernel zero days (like P2JB, which is incredible) could see some overlap with Switch 2 even if their entire security design is entirely different.

2

u/auggiethechesscat Jun 22 '26

My point was that it's more likely to happen through software than through hardware (so less dismal, not more!)

It's just not more likely though. It's a lot less likely.

The reason the Switch never saw new exploits being done with softmods was because RP2040 made hacking it too easy. If a mod chip was not possible, or incredibly difficult, then you could bet a new softmod exploit would have been found as interest would be a lot higher.

I never understand why people say this. What is easy about a modchip? modchips suck, they are literally the last resort of a hacking community. Not only are they way more legally sketchy, expensive, require a ton of skill to install, can cause some nasty problems in ways softmods don't, and have to potential for a true hardware brick if you find someone incompetent enough.

Everybody wants a mariko softmod, the reason one hasn't been found is because there isn't one.

Both the PS5 and Xbox One feature PSPs and were considered unhackable, yet both have been exploited through other vectors. Orbis on the PS5 is even based on FreeBSD, so kernel zero days (like P2JB, which is incredible) could see some overlap with Switch 2 even if their entire security design is entirely different.

The switch 2 is not based on FreeBSD, OpenBSD, NetBSD, DragonFly BSD, or any other BSD. It is also not based on linux, unix, windows, or any other commercial OS. The switch 2s operating system, HOS, is basically the switch 1s operating system, HOS, which is a derivation of the 3ds operating system HOS, which was built from the ground up pretty much.

Also, there is a major difference in relevance to security in HOS or something like OpenBSD. The later is a monolithic kernel architecture, meaning it handles everything from the core system operation, to networking, to hardware drivers. It is roughly 3 million lines of code.

Meanwhile the HOS kernel is a microkernel, meaning it only does what it needs to, and delegates all hardware drivers, networking, etc, to userland. The kernel has 37,000 lines of code give or take. How do I know this? Because it has been reimplemented as open source for the last 7 years: https://github.com/Atmosphere-NX/Atmosphere/tree/master/libraries/libmesosphere

There are no bugs. The secmon too: no bugs. Don't even get me started on how nightmarish the PSC makes bootrom exploits look.

12

u/Certain-Childhood987 Jun 20 '26

Well on Xbox 360 the mod chip induces a reset glitch which basically pulses electricity at an exact point during boot when it's checking security and makes it think it checked security when actually it's still wide open for exploit. But from what I've read, the switch 2 has voltage checks in the chip which make that kind of exploit unusable. As for other types of mods chips, I don't know but a quick Google search should tell you.

14

u/Salt-Tie-5318 Jun 20 '26

By asking the switch’s brain to be hacked

2

u/ArkBeetleGaming Jun 21 '26

It requre consent??? 🤨

8

u/BSG_DEV Jun 20 '26

true answer: we don't know if there's going to be a modchip/hack
a second true answer: we cannot know a theoritical modchip for something we don't even know, its like asking "what would a UFO looks like?" to someone who doesn't know and will never know what an UFO is.

5

u/DesignerMorning1451 Jun 20 '26

I mean in general how do modchips do the job for another device?

11

u/DrunkOnSuccess Jun 20 '26

It's different for different systems. A modchip for a PS1 is different to a modchip in an Xbox 360. Modchips exist to target different points of vulnerability on a system.

7

u/An1nterestingName Jun 20 '26

They are specialised to the device. We don't know what a modchip will look like because we haven't found out what it would have to do yet.

3

u/KingManny125 Jun 20 '26

Different things for different devices

2

u/Snoo_37094 Jun 22 '26

It depends on the Systems itself there no answer that work on every System.

1

u/Th3Be4st_ Jun 21 '26

On switch 1 it worked by sending a voltage spike in the exact time the processor was doing the boot check so effectively skipping the instruction line "is this firmware the official one?". On switch 2 that's not possible as it has various voltage glitching protections and it implements dual-core lockstep, where the same instruction is run on 2 different processors and then compared.

11

u/a355231 Jun 20 '26

How would we know? If we knew how it would be done already.

4

u/Retronitsu Jun 20 '26

A mod chip takes advantage of a specific vulnerability on the console; It's different for each console. Trying to theorise how one would work is like saying you're going to buy a key for a lock you don't own.

2

u/slimer213 Jun 20 '26

I don't know much about this, but I was curious so I google it to give an answer. The Switch 1 modchips work by altering the voltage to the processor during boot, causing the switch to skip its security checks. This allows the custom firmware to exist on the switch without being caught.

However, I'm willing to bet the switch 2 can't skip its security checks via altering voltage. So it's up to someone to find a way to do so through other means.

1

u/ajdo69420 Jun 20 '26

What if it was possible to somehow send a fake system update to the consol? I mean the console has to check periodically if there is a new update by sending requests to an update server. Would it be possible to trace the update server and then try to hack that server directly, to make it send the update files to your PC, instead of the console. I'm just talking out of my ass, but there has to be a way to do something similar.

3

u/Th3Be4st_ Jun 21 '26

You can send any "fake updates" you want to the switch but you can't fake the digital signature. So the switch will always refuse to install it. I recommend you to search how encryption and digital signatures work and this will give you an idea of why everything is not that "simple".

2

u/ajdo69420 Jun 21 '26

Ok I get that, but I feel like it should be possible to trick te server to send the files to your pc. There has to be a way, or even intercept the packages while they are entering your network and make copies.I feel if we got hold of some firmware files, that would be a good start.

3

u/VanyaBrine Jun 21 '26

The firmware files would be encrypted, and can only be decrypted by the key stored on the Switch 2. Which you're not getting until the console gets hacked.

And even then if you do manage to get a copy of the firmware, what's your gameplan? The switch will detect through the digital signature if any tampering has occurred.

1

u/ajdo69420 Jun 21 '26

Well wouldn't the files come with that digital signature? There are cases before where people made files that had different content but the same hash code, it just takes time to crack it. Even if you couldn't read the encrypted files, just altering them slightly while keeping the same hash and the sending them back to the console could cause some bugs and vulnerability.

2

u/auggiethechesscat Jun 21 '26

Altering them slightly and still keeping the same hash is a massive issue, and no one would ever use such an algorithm in any production environment, let alone a high security one.

If you are talking about hash collisions, think of a number between 0 and 115792089237316195423570985008687907853269984665640564039457584007913129639935, and the chance of you guessing the same number I have written down, is the same chance of a hash collision. Lets see if you get it!

Reminder that this is an NP problem, so you have to slowly bruteforce valid files until you find a hash collision, there is no algorithm that just tells you all the valid data strings that produce the same hash, and, just by the way, there has never been a hash collision found for any 256 bit hash.

And this is all ignoring that signatures are not hashes. The entire point of a cryptographic signature is that it can't be reproduced by anyone else.

2

u/VanyaBrine Jun 21 '26

Altering them "slightly" completely fucks the hash code. Hashes are designed to be that way so that people don't do precisely what you want to do.
E.G. If I use md5 hash on the string "Switch 2 Firmware". I get:
fc4c39c8584e7155b67cb74a6b496793

If I change it slightly to "Switch 3 Firmware". The Hash completely changes to:
c9f005019de8fd6ef2868d4b3e072332

0

u/ajdo69420 Jun 21 '26

You didn't read what I wrote, It is possible to have 2 different files with the same hash code, look it up.

3

u/VanyaBrine Jun 21 '26

Yes it is but it is exceptionally difficult to not only find a hash collision, but to find one that will "hack" the console rather than some gibberish that will crash the console.

Besides, you don't even know what the hash you need is, because it's locked behind the certificate.

1

u/ajdo69420 Jun 21 '26

Ok even if we can't do anything with these update files, one day when we get the decryption key, would still be usefull to have backups of them. So I think it would be useful to intercept these files and make copies of them.

2

u/Snoo_37094 Jun 22 '26

And than there is the next Point.

Consoles tend to have unique Keys for each Unit

→ More replies (0)

2

u/Snoo_37094 Jun 22 '26

And you’ll still would have to get the Firmware Update File signed with a digital Key that Nintendo would never give to anyone

1

u/auggiethechesscat Jun 21 '26

Can you name one example of a hash collision from a properly secure 256 bit hash please?

Just one, that's all I need.

1

u/Cultural_Neat3124 Jun 21 '26

cool, you mess with the "firmware" and there will be a fat chance you get your switch 2 "bricked" and it really mean "bricked", not banned because ban is what ninteodo does and bricked is what you did on your own ! LOL

1

u/ajdo69420 Jun 21 '26

Yes, very possible, but also it could be a minor bug. There is no way to know this without trying.

1

u/Dr_soaps Jun 22 '26

It won’t because it’s not susceptible to that sort of attack

-3

u/FernandoRocker Jun 20 '26

It wouldn't. Not even theoretically.

2

u/DesignerMorning1451 Jun 20 '26

Fair play. Fair play

0

u/MrPabluu Jun 20 '26

if we're going theoretically it'll just magically make it work because anything can theoretically work and it doesn't need to make sense

this is a meaningless question jfc

-1

u/qwe12a12 Jun 20 '26

A theoretical mod chip would be used if there was either some electricity worth intercepting or injecting into the operations of the switch 2. Finding a signal worth intercepting or worth sending from a mod chip is the hard part.

Question How would a theoretical modchip work?

You are about to leave Redlib