Hacking Hardware Picofly - a HWFLY switch modchip

[CompSciOrBust]

The width of the glitch line on the previously posted image is how tight the timing is. I think that is a good starting point as it is a known working variable.

The HWFly-NX firmware GitHub repo has known good start points for both glitch width and glitch offset for Erista and Mariko. If you guys are going to build your own glitch chip why reinvent the wheel? Just use HWFly-NX but replace the FPGA communication code with PIO stuff.

 

[Piorjade]

To anybody who's bored and knows a bit about the HWFLY-NX firmware, what the hell is this code at line 69 (nice) in firmware/src/payload.c?
(Link: https://github.com/hwfly-nx/firmware/blob/master/firmware/src/payload.c)

The BCT offsets above that (0, 0x20, 0x40, 0x60) all make sense if you multiple them by 512 (I've guessed that that's the block size), you get the exact offsets the wiki says:

Only this "payload", which I assume is the actual HWFLY / Spacecraft firmware, seemingly makes no sense why the offset is 0x1F80 * 512 = 0xE9E000

package1 (NX Bootloader and stuff like that) starts at 0x100000, this payload is way beyond that and I haven't found anything for this address space..


I'm just curious and learning the code though, please don't get any wrong ideas.

 

[binkinator]

~52mHz. Need use CMD, CLK, D0 pins.

It HAS to be 52mHz? That’s fast. My little guy only does 24MHz but has met all my needs (up until today.) I will look into a faster one but it’s probably going to be too pricey.

 

[FruithatMods]

Because it is a lot simpler writing c than reading c.

For instance if I were to code the emmc read/write portion of the modchip I would simply hold the reset line to make sure the cpu is off while boot0 is being read and written to.

Is there something wrong with this logic?

If we get a full logic analyser dump we can see if that is how it is already being done. isn't that part done in the fpga?

 

[Adran_Marit]

Okay just because I'm dumb, someone wanna recap where we are at?

 

[TheSynthax]

Okay just because I'm dumb, someone wanna recap where we are at?

fck the leak, we're just going to figure out how the SX-Core/HWFLY work so someone can reimplement the functionality on the Pico.

 

[brecht6]

Are you guys now in the first phase of figuring it out or already implementig it?

 

[TheSynthax]

Are you guys now in the first phase of figuring it out or already implementig it?

Just documenting the functionality with a logic analyzer right now, need someone with a fast enough analyzer or scope with enough channels and a working HWFLY or SX-Core/Lite to hook into each of the points and test it during a normal boot, while training, and during a glitch boot.

 

[saladus]

The HWFly-NX firmware GitHub repo has known good start points for both glitch width and glitch offset for Erista and Mariko. If you guys are going to build your own glitch chip why reinvent the wheel? Just use HWFly-NX but replace the FPGA communication code with PIO stuff.

i think this would be better than making it from scratch honestly . why try and figure out what the hwfly does when you have what it does nicely packed in a github repo

 

[ByteFun]

To anybody who's bored and knows a bit about the HWFLY-NX firmware, what the hell is this code at line 69 (nice) in firmware/src/payload.c?
(Link: https://github.com/hwfly-nx/firmware/blob/master/firmware/src/payload.c)

View attachment 350292

The BCT offsets above that (0, 0x20, 0x40, 0x60) all make sense if you multiple them by 512 (I've guessed that that's the block size), you get the exact offsets the wiki says:

View attachment 350293

Only this "payload", which I assume is the actual HWFLY / Spacecraft firmware, seemingly makes no sense why the offset is 0x1F80 * 512 = 0xE9E000

package1 (NX Bootloader and stuff like that) starts at 0x100000, this payload is way beyond that and I haven't found anything for this address space..


I'm just curious and learning the code though, please don't get any wrong ideas.

0x1F80 * 0x200 = 0x3F0000
Maybe it's not a block number, but an address? (1F80)

 

[Piorjade]

0x1F80 * 0x200 = 0x3F0000
Maybe it's not a block number, but an address? (1F80)

Lmao how did I get this multiplication wrong? Maybe I was too sleep deprived.
Anyway, the function "mmc_check_and_if_different_write" internally calls "mmc_read" with the same parameter. mmc_read only reads a single full block, which is 512 bytes.

So this has to be a block number (0x1F80) and its actual address is 0x3F0000.
Problem is, 0x3F0000 still doesn't make sense to me.

(sigh) This code has as little documentation as I write at work

 

[Adran_Marit]

fck the leak, we're just going to figure out how the SX-Core/HWFLY work so someone can reimplement the functionality on the Pico.

The leak was encrypted yeah?

 

[linuxares]

The leak was encrypted yeah?

But you couldn't encrypt the rp2040!!!

 

[TheSynthax]

But you couldn't encrypt the rp2040!!!

You wouldn't encrypt a car!

 

[Piorjade]

Im dumped my old switch emmc witch progger(UFPI).
On the example of these files, you can understand at what addresses the code is being changed. With such success, you can write such a glitch from scratch. The source code of hwfly is there and everything is described there.

The problem is that I'm not strong in the C language (

Thank you! It seems like 0x3F0000 isn't a special memory address used by Nintendo, if your dump is complete and legit.
I think this is just empty space which HWFLY / Spacecraft-NX uses to store the custom payload. Man I'm dumb..

This means the BCT must redirect the bootloader to run the code at this address next instead of package1ldr

(Left is the "no glitch" file and right is the glitched file)

 

[lemongrab]

But you couldn't encrypt the rp2040!!!

IIRC someone said if you change portions of the code it won't work so my guess is they hardcode the flash ID then checksum the code with the ID in it and if the code is modified it quits. The checksum code is obfuscated to make it harder to circumvent. That would be a basic measure to ensure you can't just copy the flash and change the ID.

 

[ByteFun]

IIRC someone said if you change portions of the code it won't work so my guess is they hardcode the flash ID then checksum the code with the ID in it and if the code is modified it quits. The checksum code is obfuscated to make it harder to circumvent. That would be a basic measure to ensure you can't just copy the flash and change the ID.

Have you seen the code? There is a large data segment with high entropy. Specifying an identifier and simply comparing it is too stupid a defense.

 

[lemongrab]

That's not what I said.

 

[ByteFun]

Did you mean checking to prevent patches? Then excuse me, I did not immediately understand what you mean.

 

[Mansi]

Thank you! It seems like 0x3F0000 isn't a special memory address used by Nintendo, if your dump is complete and legit.
I think this is just empty space which HWFLY / Spacecraft-NX uses to store the custom payload. Man I'm dumb..

This means the BCT must redirect the bootloader to run the code at this address next instead of package1ldr

(Left is the "no glitch" file and right is the glitched file)

View attachment 350367

yep. Im used https://github.com/hwfly-nx/firmware 0.72 version.
check firmware 0.72 in archive. find on HEX this bytes)

Post automatically merged: Jan 31, 2023

my dumps fully work)