Hacking [QUESTION] Are there any resources on the functionality of SX / HWFLY?

[Piorjade]

Basically the title..
I'm interested in how these modchip work, I'm in no way capable of reproducing these things nor do I even know much about hacking at all.
I'm just some random CS student interested in this exploit procedure.

I roughly know that apparently they utilize a voltage glitch exploit at some point in time to somehow manipulate the BCTs and thus allow custom code to run

Howevery, I'd like to know what exactly the role of the chip firmware (e.g. spaceship-nx) is and what the FPGA in contrary does.
I'm guessing the FPGA does the voltage glitch itself but on the other hand that if it was the only thing it did than it shouldn't be that the HWFLY is practically the only clone out there..

Does anyone have any more resources or more detailed documentations of these chips? Thanks in advance, even if you guys don't have any more information for me

 

[l7777]

Basically the title..
I'm interested in how these modchip work, I'm in no way capable of reproducing these things nor do I even know much about hacking at all.
I'm just some random CS student interested in this exploit procedure.

I roughly know that apparently they utilize a voltage glitch exploit at some point in time to somehow manipulate the BCTs and thus allow custom code to run

Howevery, I'd like to know what exactly the role of the chip firmware (e.g. spaceship-nx) is and what the FPGA in contrary does.
I'm guessing the FPGA does the voltage glitch itself but on the other hand that if it was the only thing it did than it shouldn't be that the HWFLY is practically the only clone out there..

Does anyone have any more resources or more detailed documentations of these chips? Thanks in advance, even if you guys don't have any more information for me

People definitely have info on the FPGA, but for legal reasons it will be hard to get ahold of. Nintendo won its case against TX effectively setting the precedent that the chips violate the DMCA.

What you can probably find is the info on hacking the Tegra X1. This info should be publicly available and it is my understanding that the modchips take advantage of this attack.

 

[binkinator]

e: https://gbatemp.net/threads/sx-modchip-firmware-has-been-dumped.575204/

 

[impeeza]

For the few information about the "Hardware" hack, the chip send "Weird" voltages to the CPU, put it on a unstable state, then [BlackBox] interact with the EMMC chip and interchange the bootloader read from it to a custom payload

but that is the big picture, the exact detail are secrets and it's beleive only TX team knows it. about the clones, no body really knows if are from TX or one of they factories.

The Open Source "Firmware" for the mod chips, as I know is only for the payload part. the direct manipulation of CPU, interaction with MMC and decryption are on other part of the chip.

 

[impeeza]

https://gbatemp.net/threads/flashing-binaries-onto-hwfly-v3-for-oled.610589/

 

[EnigmaExodus]

The people behind HWFLY definitely know - If not related to TX its either dumping and reverse-engineering the FPGA bitstream or a clean-room re-implementation but for reasons they keep their research private (to sell chips).

 

[EnigmaExodus]

People definitely have info on the FPGA, but for legal reasons it will be hard to get ahold of. Nintendo won its case against TX effectively setting the precedent that the chips violate the DMCA.

What you can probably find is the info on hacking the Tegra X1. This info should be publicly available and it is my understanding that the modchips take advantage of this attack.

Perhaps. Part of me believes the reason Nintendo so vigorously forced the TX case were because of its blatant relation to piracy and not just homebrew or modchips.

For starters I believe TX:

1) Included copyrighted Nintendo content or encryption keys that could be extracted from units without re-distribution
2) Had a license functionality in SXOS to enable the loading of unsigned XCIs with a paid license (read, game piracy).
3) Allegedly were involved with a service that was selling subscription access to pirated ROM dumps.

In that light the above is much more questionable than just 'a modchip to run unsigned code'.

 

[evil_santa]

This is probably useful for your understanding.

https://research.nccgroup.com/2020/...-your-soc-glitching-the-mediatek-bootrom/amp/

 

[thesjaakspoiler]

A few weeks after Yifan Lu published an article about how she used voltage glitching to hack the boot process of the PSVita, the SXOS modchip was 'suddenly' shown to the public.
Voltage glitching is like Tom Cruise if Mission Impossible were real.
Voltage glitching is sending a voltage spike on the clock signal in order to cause the cpu to misbehave in a controlled manner like skipping a security check. Modern cpu's have all kinds of security features to check whether the data that they are reading has been tampered with. So you can't just put some hacked code in the flash memory and expect the CPU to execute it.
So legitimate data from the flash memory is replaced with hacked data (via the FPGA) and voltage glitching is used to fool the CPU into believing that what it just read was valid. Without that voltage glitch, the CPU would conclude that someone tried to tamper with the data and not execute the hacked code.

She has some background articles on how the process works on her site :
https://yifan.lu/2019/02/22/attacking-hardware-aes-with-dfa/
https://github.com/TeamMolecule/petite-mort
And a scientific paper as well :
https://arxiv.org/abs/1903.08102

At a certain point, the original data from the flash memory needs to be replaced with some hacked data.
Based on a specific timing, this data needs to be provided with the same bus speed as the flash memory is running on.
Doing that with a generic mpc/cpu is not possible because these mpus are just too slow.
This is where the FPGA comes in.
Technically speaking everything could have implemented inside an FPGA but that requires a bigger (more expensive) FPGA and makes it harder to update the modchip.
With upcoming new models in mind, updating modchip is an issue to keep in mind.

TX got sued over the SXOS and their modchip because it included Nintendo proprietary code and allowed for piracy as a feature out of the box.
As long as you stay away from creating a product for other users to pirate their Switch, studying the security models of devices falls is legally allowed.
Even Nintendo will probably have learned something from all the security research and maybe beef up the security of their next game console.
Or maybe not....

 

[Piorjade]

Thank you everyone! Sadly for whatever reasons I didn't receive email notifications for this thread, anyway thanks again for all this information

 

[Piorjade]

Just an FYI (though probably everybody that wanted to learn the more technical side of this stuff already knows about it):

A rather interesting video about glitching the switch comes from LiveOverflow:

Seems like he explains this whole BootROM stuff on the Tegra X1 a bit more and reading the article posted by @evil_santa in combination with skipping through the hwfly-nx firmware a bit I think I now understand that the CPU on the modchips is responsible for actually injecting custom BCTs / payloads / whatever while it tightly communicates with the FPGA.

I guess the FPGA functions similar to the one in the article by nccgroup, that is, monitoring the eMMC data (which is probably where this whole "DAT0" stuff when it comes to OLED comes from) and actually applying a voltage glitch.
I only skipped through the hwfly-nx firmware code but it seems to me that the CPU basically tells the FPGA to glitch at offset X with pulsewidth Y and then somehow gets a response from the FPGA if the glitch was successful. I'm guessing "success" refers to successfully reading the bootROM because if I understood the video from LiveOverflow correctly, the bootROM gets locked up at some point early at boot time and such a glitch allows to read the bootROM after it was supposed to be locked.

Though in all honestly I might aswell mix some things up here and probably don't understand it at all..

 

[l7777]

Just an FYI (though probably everybody that wanted to learn the more technical side of this stuff already knows about it):

A rather interesting video about glitching the switch comes from LiveOverflow:

Seems like he explains this whole BootROM stuff on the Tegra X1 a bit more and reading the article posted by @evil_santa in combination with skipping through the hwfly-nx firmware a bit I think I now understand that the CPU on the modchips is responsible for actually injecting custom BCTs / payloads / whatever while it tightly communicates with the FPGA.

I guess the FPGA functions similar to the one in the article by nccgroup, that is, monitoring the eMMC data (which is probably where this whole "DAT0" stuff when it comes to OLED comes from) and actually applying a voltage glitch.
I only skipped through the hwfly-nx firmware code but it seems to me that the CPU basically tells the FPGA to glitch at offset X with pulsewidth Y and then somehow gets a response from the FPGA if the glitch was successful. I'm guessing "success" refers to successfully reading the bootROM because if I understood the video from LiveOverflow correctly, the bootROM gets locked up at some point early at boot time and such a glitch allows to read the bootROM after it was supposed to be locked.

Though in all honestly I might aswell mix some things up here and probably don't understand it at all..

Good stuff. I always assumed that the patched switches simply prevent entering RCM mode via button presses or other accessible means. This means that all the mod chips have to do is trigger RCM mode, and then take advantage of all the work done on the original unpatched switches. This is likely an oversimplification but I can't see why it wouldn't work.

 

[hippy dave]

Good stuff. I always assumed that the patched switches simply prevent entering RCM mode via button presses or other accessible means. This means that all the mod chips have to do is trigger RCM mode, and then take advantage of all the work done on the original unpatched switches. This is likely an oversimplification but I can't see why it wouldn't work.

No, RCM is triggerable in the same way on all models, because it's there for official use. What's fixed is the exploit triggered by sending a hack payload to RCM - on an unpatched Switch the payload takes advantage of a bug that lets it run even tho it's not valid/officially signed. On unhackable Switches the payload is just rejected because it's not valid.

 

[binkinator]

Watch the video. It really is worth it. I always thought the payload was directly executed. It’s not. It has to be indirectly pulled in and then called from the stack. He explains the bug at a high level and how they actually overwrite the stack with the payload. Very easy for N to put constraints on the size of data that can be written and patch it out. Very cool stuff.

Watching the more detailed video he references https://media.ccc.de/v/c4.openchaos.2018.06.glitching-the-switch

still so much to learn…

 

[evil_santa]

here is another interesting case study for the tegra x2 as a PDF. also note the references there are many interesting links to be found.

 

[CompSciOrBust]

Surprised no one linked the 34C3 talk yet. The Switch brew team documented a glitching process on the TX1 back in 2017. It's not identical to the way the SX chips do it but it's the same basic idea.


IIRC the SX Core operates as follows:
Write custom BCT to the NAND which allows booting an unsigned bootloader
Write custom bootloader to the NAND
Monitor the NAND data lines to detect when the BCT is being read

Once the chip detects that the BCT is being read it tells the FPGA to start glitching the CPU (I'm assuming you already know how voltage glitching works)
The Switch then boots the "unsigned" bootloader, which is actually signed with a custom private key with the corresponding public key being kept in the BCT
The public key used for Spacecraft is 0x69 repeating, the SX chips use a different public / private key combo
The main chip firmware (Spacecraft in HWFly's case) will then also be responsible for detecting failed glitches and resetting the CPU, as well as training to find correct offset / glitch length for that specific CPU.

Note that they don't actually glitch the bootloader, the Tegra will happily boot whatever is in there as long as the key in the BCT says that it is signed. So they just have to glitch the BCT checks which is handled in the bootrom.

The process of creating a custom FPGA firmware is supposedly easy (I haven't done it myself) but anyone who is capable of doing it isn't willing to open themselves to legal trouble by sharing it. You can't just dump the FPGA firmware from the SX Core because it is protected.

Also of note is that on Mariko the BCT is signed encrypted with the BEK (boot encryption key), I don't think it has been publicly documented anywhere how to do that although it is public knowledge. I've been told by someone how to do it but I don't know if I'm allowed to share that.

 

[Piorjade]

Surprised no one linked the 34C3 talk yet. The Switch brew team documented a glitching process on the TX1 back in 2017. It's not identical to the way the SX chips do it but it's the same basic idea.


IIRC the SX Core operates as follows:
Write custom BCT to the NAND which allows booting an unsigned bootloader
Write custom bootloader to the NAND
Monitor the NAND data lines to detect when the BCT is being read

Once the chip detects that the BCT is being read it tells the FPGA to start glitching the CPU (I'm assuming you already know how voltage glitching works)
The Switch then boots the "unsigned" bootloader, which is actually signed with a custom private key with the corresponding public key being kept in the BCT
The public key used for Spacecraft is 0x69 repeating, the SX chips use a different public / private key combo
The main chip firmware (Spacecraft in HWFly's case) will then also be responsible for detecting failed glitches and resetting the CPU, as well as training to find correct offset / glitch length for that specific CPU.

Note that they don't actually glitch the bootloader, the Tegra will happily boot whatever is in there as long as the key in the BCT says that it is signed. So they just have to glitch the BCT checks which is handled in the bootrom.

The process of creating a custom FPGA firmware is supposedly easy (I haven't done it myself) but anyone who is capable of doing it isn't willing to open themselves to legal trouble by sharing it. You can't just dump the FPGA firmware from the SX Core because it is protected.

Also of note is that on Mariko the BCT is signed encrypted with the BEK (boot encryption key), I don't think it has been publicly documented anywhere how to do that although it is public knowledge. I've been told by someone how to do it but I don't know if I'm allowed to share that.

I think documenting / telling how the Mariko BCT is signed isn‘t really illegal in that sense, otherwise all these videos should be banned aswell but they aren‘t.

I think it isn‘t really specific to Nintendo themselves, the CPU is by NVIDIA after all and they allow anyone to buy a dev kit and have detailed information on its inner workings I think, signing BCT with a BEK isn‘t really anything new by Nintendo AFAIK

I might be wrong though

 

[CompSciOrBust]

I think documenting / telling how the Mariko BCT is signed isn‘t really illegal in that sense, otherwise all these videos should be banned aswell but they aren‘t.

I think it isn‘t really specific to Nintendo themselves, the CPU is by NVIDIA after all and they allow anyone to buy a dev kit and have detailed information on its inner workings I think, signing BCT with a BEK isn‘t really anything new by Nintendo AFAIK

I might be wrong though

Encrypting the BCT with the BEK was something Nvidia added with the Mariko revision. Iirc it's an optional feature for vendors. I don't think it would be illegal for me to share how to obtain the key used to encrypt it but it was told to me privately and I think it would be a dick move to share it on GBATemp when it isn't documented anywhere on the public web, it seems to just be shared from scene dev to scene dev in private chats. It requires exploiting a vulnerability in the crypto engine which allows dumping out locked key slots.

 

[hippy dave]

The public key used for Spacecraft is 0x69 repeating,

Nice.

 

[CompSciOrBust]

Nice.

Sauces:

https://github.com/Atmosphere-NX/At...1fee45bb63f1d782cc38b69a3355a026e7e962d42e893

https://gist.github.com/SciresM/16b63ac1d80494522bdba2c57995257c