Hacking Hardware Picofly - a HWFLY switch modchip

[Piorjade]

Soo my current state of information about the HWFLY is the following:

• Microcontroller does most if not all of the "smart" stuff, e.g. writing the payload and custom BCTs to the NAND, determining which glitch configuration (offset + pulse width + some sort of delay) to use
• In the training process, it sends out multiple glitch configs (to the FPGA) and receives the eMMC traffic (from the FPGA) after the glitch has been performed, determining whether it was successful or not and if not send a different config and try again
• The FPGA, on the other hand, handles the actual traffic to the eMMC, synchronizing with the CLK and stuff like that..
  
  It sends messages that were given by the microcontroller and listens to traffic between the main CPU and the eMMC, buffering it so the microcontroller can read the last messages
• The FPGA obviously also runs the actual glitch based on the given configuration, as far as I understand it really only glitches using this config and doesn't have any kind of algorithm to "find" the best config because the microcontroller does that.

All in all I think I must be missing something because with my current understanding the FPGA shouldn't really be that complicated to replace. It can't be that dumb of an FPGA firmware, right?

Other than that, I tried to understand the payload and custom BCTs and honestly, I've hit a road block. I see that the custom BCTs use a new public key (0x69 repeating) and that it also set a new "StartBlock" address for bootloader0

In @Mansi 's BOOT0 dump I can see that the StartBlock was set to 0x000000FC (original is as in the documentation 0x00000040), while the payload is written to 0x1F80 so at this point I don't know what happens next lmao

EDIT:
Well, I've found it out. I forgot to remember that the Tegra talks to the eMMC with a blocksize of 16KiB (=16384 bytes) instead of 512byte like the FPGA does. (https://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html)
0x1F80 * 512 byte = 0x3F0000
0xFC * 16384 byte = 0x3F0000

So yeah, Package1 doesn't get loaded, the payload gets loaded instead and after that basically comes Hekate / Whatever you put into the SD.

Does anyone have a clue what the voltage glitch actually mitigates? On Erista models the BCT is not even encrypted, it's just signed with the given public key (0x69 repeating in HWFLY's case), so what's stopping the payload if we don't do a voltage glitch?

 

[CompSciOrBust]

All in all I think I must be missing something because with my current understanding the FPGA shouldn't really be that complicated to replace. It can't be that dumb of an FPGA firmware, right?

The only reason TX used an FPGA is because they wanted to distribute SX Core updates without giving out the full firmware, which would have lead to earlier clones. By splitting up the firmware the way that they did it stopped people from just cloning the hardware and then slapping TX software on to it. There's no technical reason that the FPGA is needed. This is why I suggested using the HWFly-NX firmware if people are making their own RP2040 glitcher from scratch. It's not much work to reimplement the FPGA logic.

Does anyone have a clue what the voltage glitch actually mitigates? On Erista models the BCT is not even encrypted, it's just signed with the given public key (0x69 repeating in HWFLY's case), so what's stopping the payload if we don't do a voltage glitch?

If you fail to glitch the bootrom reads one of the other three BCTs. I'm not sure about HWFly but on the original SX Core at least one BCT was left intact so if a glitch failed you could still boot in to OFW. If there are no valid BCTs on the NAND and you fail to glitch you end up in RCM mode, which is exactly how auto RCM works on Erista. It just nulls out the first byte in each BCT.

 

[Piorjade]

If you fail to glitch the bootrom reads one of the other three BCTs. I'm not sure about HWFly but on the original SX Core at least one BCT was left intact so if a glitch failed you could still boot in to OFW. If there are no valid BCTs on the NAND and you fail to glitch you end up in RCM mode, which is exactly how auto RCM works on Erista. It just nulls out the first byte in each BCT.

I know about the other BCTs getting loaded upon failing to read / verify the first one. However, the BCT gets verified with the signature and the public key that is also located in the BCT (practically the very first information is the public key info), right?
So if I understand it correctly, the custom BCT should get loaded because the BCT is signed with the custom key and the public key info is placed at the top, doesn't it?
I think what really stops the payload from running is the signature of the payload itself, my theory is that there's a key from Nintendo's hard coded on the chip somewhere (the fuses?) and after the BCT loads the BPMP tries to verify the payload using Nintendo's key and that's where a glitch is needed.

 

[Mansi]

I'm thinking of asking the guy with rp2040 for a patched boot1 and comparing what is written to it. Maybe this will help? It will be interesting to see a comparison with a glitch from hwfly.

Spoiler: Offtop / need help

Guys, now I want to take an oled for tests and work rp2040.
But, I ran into a problem with my order. If I buy the Japan version, will I have problems using the console in Europe?
Or order the European version?

 

[CompSciOrBust]

I know about the other BCTs getting loaded upon failing to read / verify the first one. However, the BCT gets verified with the signature and the public key that is also located in the BCT (practically the very first information is the public key info), right?
So if I understand it correctly, the custom BCT should get loaded because the BCT is signed with the custom key and the public key info is placed at the top, doesn't it?
I think what really stops the payload from running is the signature of the payload itself, my theory is that there's a key from Nintendo's hard coded on the chip somewhere (the fuses?) and after the BCT loads the BPMP tries to verify the payload using Nintendo's key and that's where a glitch is needed.

The boot rom verifies that the BCT is signed with a key stored in the boot rom, the boot rom then takes the bootloader key from the BCT and uses that to verify that the bootloader is signed. You don't need to sign the custom BCT because you're going to glitch that check anyway.

Edit: Although on Mariko the BCT is encrypted. You can't glitch past that, obviously. You just have to encrypt the custom one with Nintendo's key. To get that key you either have to use a leaked one (ILLEGAL! DO NOT DO THAT!), or use side channel analysis to get the key.

 

[szubiennica]

How about making a bounty on open source firmware/bootloader for pico?

 

[Piorjade]

The boot rom verifies that the BCT is signed with a key stored in the boot rom, the boot rom then takes the bootloader key from the BCT and uses that to verify that the bootloader is signed. You don't need to sign the custom BCT because you're going to glitch that check anyway.

Ooh so I got it the other way around, thanks!

Edit: Although on Mariko the BCT is encrypted. You can't glitch past that, obviously. You just have to encrypt the custom one with Nintendo's key. To get that key you either have to use a leaked one (ILLEGAL! DO NOT DO THAT!), or use side channel analysis to get the key.

So you're saying the BCT in the HWFLY-NX open source code got encrypted with the leaked key? Lmao

I'm thinking of asking the guy with rp2040 for a patched boot1 and comparing what is written to it. Maybe this will help? It will be interesting to see a comparison with a glitch from hwfly.

Honestly I think the picofly prototypes used the exact same BCT and payload, I can't think of a reason why they'd write their own. Though it would be interesting to see, yes.

 

[CompSciOrBust]

So you're saying the BCT in the HWFLY-NX open source code got encrypted with the leaked key? Lmao

Maybe, but they could have just gotten the key themselves through hardware hacking the same way TX did originally, although it would be easier to just use one from the internet.

 

[vittorio]

here are a few things explained
https://gist.githubusercontent.com/...b2612ab62998243ce5e7877496466cabb77f/tsec.txt

 

[Mansi]

Honestly I think the picofly prototypes used the exact same BCT and payload, I can't think of a reason why they'd write their own. Though it would be interesting to see, yes.

I mean, if I use the license for the first time)

 

[CompSciOrBust]

here are a few things explained
https://gist.githubusercontent.com/...b2612ab62998243ce5e7877496466cabb77f/tsec.txt

TSEC was never used on Mariko and it's not needed on Erista anymore.

 

[binkinator]

here are a few things explained
https://gist.githubusercontent.com/...b2612ab62998243ce5e7877496466cabb77f/tsec.txt

*reading intently* Uh-huh…ohhhh…uh-huh

”…anyway, I just collected a few thousand samples of glitched AES samples, ran his script, and all the keys popped out.”

Wait…what?

 

[vittorio]

do you have any idea how to proceed?

 

[saladus]

do you have any idea how to proceed?

accepting jesus christ as our lord and savior
jokes aside, thread seems to be moving towards adapting hwfly-nx's code for the pico so maybe learning c would be a good idea if you want to help but don't know how to start.. maybe i should be doing that as well instead of just talking out my ass

 

[vittorio]

i already know how to program but i don't know where to start with this fw, anyway pikofly is probably an adapted version of spacecraft

 

[Piorjade]

i already know how to program but i don't know where to start with this fw, anyway pikofly is probably an adapted version of spacecraft

It most likely is, however, there is no source code. Also, hwfly-nx is spacecraft-nx, it's just further developed.

I've ordered myself a Pico as well because the specifications looked very fun, especially these PIOs
I only ever played around with basic microcontrollers, learning about these will be fun

Maybe I'll try to at least port hwfly-nx's firmware code over to Pico to try and learn more about it. But honestly I don't know if I'm really smart enough to tackle the part that the FPGA is supposed to do.

Post automatically merged: Jan 31, 2023

By the way @Mansi the BOOT0 dumps you posted were from an Erista model, right? Do you perhaps have the same files but from a Mariko?

 

[FruithatMods]

What are the current roadblocks for implementing this on the rp2040?

What exactly is the fpga supposed to do?

 

[linuxares]

i already know how to program but i don't know where to start with this fw, anyway pikofly is probably an adapted version of spacecraft

The original firmware isn't hwfly-nx.

 

[FruithatMods]

• In the training process, it sends out multiple glitch configs (to the FPGA) and receives the eMMC traffic (from the FPGA) after the glitch has been performed, determining whether it was successful or not and if not send a different config and try again
• The FPGA, on the other hand, handles the actual traffic to the eMMC, synchronizing with the CLK and stuff like that..
  
  It sends messages that were given by the microcontroller and listens to traffic between the main CPU and the eMMC, buffering it so the microcontroller can read the last messages
• The FPGA obviously also runs the actual glitch based on the given configuration, as far as I understand it really only glitches using this config and doesn't have any kind of algorithm to "find" the best config because the microcontroller does that.

Please correct me if I understood you correctly. The gd32 microcontroller stores multiple glitch timings as variables.

During the first boot the fpga glitches the nvidia tegra chip using those supplied timings. My guess is that a restart is sent after trying each unsuccessful timing. It then tries the next one.

How does the fpga determine if the glitch was successful?

After a successful timing was found the timing is stored and the fpga is only used with this specific timing for the subsequent reads?

Correct?

So we need to know two things. 1. How it identified it the glitch was succesful.

2. Which signal does it use to start counting the time?

 

[vittorio]

I was having a look here https://github.com/Spacecraft-NX/firmware/blob/master/firmware/src/fpga.c