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

Piorjade

Member
OP
Newcomer
Joined
Nov 8, 2015
Messages
22
Trophies
0
Age
32
XP
103
Country
Gambia, The
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

Well-Known Member
Member
Joined
Apr 13, 2022
Messages
104
Trophies
0
Location
Earth
XP
225
Country
United States
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.
 
  • Like
Reactions: CompSciOrBust

impeeza

¡Kabito!
Member
Joined
Apr 5, 2011
Messages
1,826
Trophies
1
Age
44
XP
3,096
Country
Colombia
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.
 

EnigmaExodus

Member
Newcomer
Joined
Feb 6, 2022
Messages
18
Trophies
0
Location
Earth
XP
21
Country
Belgium
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

Member
Newcomer
Joined
Feb 6, 2022
Messages
18
Trophies
0
Location
Earth
XP
21
Country
Belgium
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'.
 

thesjaakspoiler

Well-Known Member
Member
Joined
Nov 20, 2018
Messages
620
Trophies
0
Age
122
XP
830
Country
Afghanistan
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

Member
OP
Newcomer
Joined
Nov 8, 2015
Messages
22
Trophies
0
Age
32
XP
103
Country
Gambia, The
Thank you everyone! Sadly for whatever reasons I didn't receive email notifications for this thread, anyway thanks again for all this information :)
 

Piorjade

Member
OP
Newcomer
Joined
Nov 8, 2015
Messages
22
Trophies
0
Age
32
XP
103
Country
Gambia, The
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..
 
  • Love
Reactions: binkinator

l7777

Well-Known Member
Member
Joined
Apr 13, 2022
Messages
104
Trophies
0
Location
Earth
XP
225
Country
United States
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

BBMB
Member
Joined
Apr 30, 2012
Messages
8,361
Trophies
1
XP
14,299
Country
United Kingdom
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.
 
  • Like
Reactions: binkinator

binkinator

Garfield’s Fitness Coach
Member
GBAtemp Patron
Joined
Mar 29, 2021
Messages
2,984
Trophies
2
XP
2,166
Country
United States
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…
 
  • Like
Reactions: hippy dave

evil_santa

Well-Known Member
Member
Joined
Jan 15, 2020
Messages
140
Trophies
0
Age
37
XP
923
Country
Germany
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.
 

Attachments

  • 2108.06131 (1).pdf
    4 MB · Views: 13
  • Like
Reactions: hippy dave

CompSciOrBust

¯\_(ツ)_/¯
Member
Joined
Sep 9, 2019
Messages
732
Trophies
0
Location
Switch scene
Website
github.com
XP
1,979
Country
Korea, North
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

Member
OP
Newcomer
Joined
Nov 8, 2015
Messages
22
Trophies
0
Age
32
XP
103
Country
Gambia, The
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

¯\_(ツ)_/¯
Member
Joined
Sep 9, 2019
Messages
732
Trophies
0
Location
Switch scene
Website
github.com
XP
1,979
Country
Korea, North
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.
 
General chit-chat
Help Users
  • No one is chatting at the moment.
    KenniesNewName @ KenniesNewName: Yeah might as well just invest $10 in a good set