Hacking Hardware Picofly - a HWFLY switch modchip

[vittorio]

wont let you fails, and trying to overwrite the sdloader loader with the hwfly one DOES work, but after reboot the switch fails to to glitch.

but you had hwfly on the switch?

 

[Tafty]

but you had hwfly on the switch?

the toolbox, not the actual firmware.....

 

[renoob]

I have found where the unique_id of the current rp2040 is stored in the original firmware:
0x20025978
$1 = 0x20025978 "\346aA\004\003y\247\071W\003"
(gdb) x/8x $r0
0x20025978: 0xe6 0x61 0x41 0x04 0x03 0x79 0xa7 0x39

and this is the output of micropython:
MPY: soft reboot
e6 61 41 4 3 79 a7 39
MicroPython v1.19.1-841-g3446d440f on


Cross Referenced unique_id example code in ghidra with firmware,found where it is,little this and little that and here we are
(rp2040 was live debuged)

 

[vittorio]

perfect, let's try to replace this id with that of @Tafty in the old fw

 

[Adran_Marit]

lockpick rcm doesnt load at all.

and its wired to both sp1 and sp2, its bridged on the flex.

the original photo on page 1 is setup the same way hence why i did it this way aswell.

Which pin on the flex is it wired to? 3rd?

 

[Tafty]

Which pin on the flex is it wired to? 3rd?

pin 3 and 4 bud, 1 2 5 6 are connected to ground, so dont bridge any of those to 3 and 4

 

[renoob]

This is the ID of the chip, not stored one for encryption, still finding where its compared

Anyway. the function is at 0x10002608 which is called at boot

 

[vittorio]

This is the ID of the chip, not stored one for encryption, still finding where its compared

Anyway. the function is at 0x10002608 which is called at boot

I've seen this function

Post automatically merged: Feb 6, 2023

if we try to put the keys manually like it says here https://github.com/CTCaer/hekate/issues/559

Post automatically merged: Feb 6, 2023

Post automatically merged: Feb 6, 2023

@Tafty

 

[RexSonic]

Very interested to see where this goes

 

[Adran_Marit]

pin 3 and 4 bud, 1 2 5 6 are connected to ground, so dont bridge any of those to 3 and 4

So bridge 3/4 thanks, I'll dig out my lite when I get home and have a play.

Did you just use the fw from this thread?

 

[Switch_Maniac]

The sdloader used in this firmware is wrong/bad that’s why it says for Ubuntu. It clears out the keys, that’s why BEK is missing. Someone that understands the firmware better needs to swap out the sdloader code with hwfly or spacecraft sdloader. You cannot patch it with hwfly toolbox because it’s not in the same location

 

[HenryMin]

I've seen this function

Post automatically merged: Feb 6, 2023

if we try to put the keys manually like it says here https://github.com/CTCaer/hekate/issues/559

Post automatically merged: Feb 6, 2023

Post automatically merged: Feb 6, 2023

@Tafty

> hekate_keys.ini is not something that hekate actually supports. I don't know what you are talking about.
Also refrain from illegally posting even a single part of the keys.

hekate_keys.ini was used in some shitty closed source cfw packs, because original tx firmware wipes BEK. You should not post thoese keys tho

 

[TheSynthax]

> hekate_keys.ini is not something that hekate actually supports. I don't know what you are talking about.
Also refrain from illegally posting even a single part of the keys.

hekate_keys.ini was used in some shitty closed source cfw packs, because original tx firmware wipes BEK. You should not post thoese keys tho

Does that mean any console that used the original TX firmware without manually backup up first could never be restored to stock?

 

[HenryMin]

Does that mean any console that used the original TX firmware without manually backup up first could never be restored to stock?

The keys are stored in bootrom, and normally they will be loaded to keyslot at boot. But TX firmware just wipe keyslot at boot to prevent other CFW to boot(It was their DRM lol), so it is not permanent.

 

[Mansi]

Maybe it will be useful for someone. I trimmed the dump.
Deleted UF2 header. UF2 > BIN.

Added old firmware witch cut UF2 file.

 

[Piorjade]

Don't know how the compiler packs Pico code into .uf2 files, but I couldn't find the HWFLY-NX public key signature (0x69 repeating) in the latest unlocked dump. If the uf2 is uncompressed then this firmware really is using different BCTs, but I guess we can already safely bet on that.

In the meantime, I'm currently writing PIO code to sniff eMMC traffic using an external CLK signal. CMD line is almost done, though I don't know yet how to know when I need to sniff 136 bit packages and when I need to sniff 48bit packages. This protocol is pretty annoying tbh.

I don't think I'll be able to even write a prototype for the glitching part, because I don't have a CPU flex cable to test this whole thing out. I have some MOSFETs (slightly different ones from the one linked here) but they're so damn small that I don't trust myself to solder it on the tiny capacitors on the switch lmao.

 

[vittorio]

I told you, the problem is the bct

 

[TheSynthax]

Probably better to solder some 40AWG enamel magnet wire to the caps and the fets if you don't have super good eyes, steady hands, and/or a microscope.

Don't know how the compiler packs Pico code into .uf2 files, but I couldn't find the HWFLY-NX public key signature (0x69 repeating) in the latest unlocked dump. If the uf2 is uncompressed then this firmware really is using different BCTs, but I guess we can already safely bet on that.

In the meantime, I'm currently writing PIO code to sniff eMMC traffic using an external CLK signal. CMD line is almost done, though I don't know yet how to know when I need to sniff 136 bit packages and when I need to sniff 48bit packages. This protocol is pretty annoying tbh.

I don't think I'll be able to even write a prototype for the glitching part, because I don't have a CPU flex cable to test this whole thing out. I have some MOSFETs (slightly different ones from the one linked here) but they're so damn small that I don't trust myself to solder it on the tiny capacitors on the switch lmao.

 

[vittorio]

Don't know how the compiler packs Pico code into .uf2 files, but I couldn't find the HWFLY-NX public key signature (0x69 repeating) in the latest unlocked dump. If the uf2 is uncompressed then this firmware really is using different BCTs, but I guess we can already safely bet on that.

In the meantime, I'm currently writing PIO code to sniff eMMC traffic using an external CLK signal. CMD line is almost done, though I don't know yet how to know when I need to sniff 136 bit packages and when I need to sniff 48bit packages. This protocol is pretty annoying tbh.

I don't think I'll be able to even write a prototype for the glitching part, because I don't have a CPU flex cable to test this whole thing out. I have some MOSFETs (slightly different ones from the one linked here) but they're so damn small that I don't trust myself to solder it on the tiny capacitors on the switch lmao.

https://github.com/hwfly-nx/firmware/blob/master/firmware/src/mmc_sniffer.c

 

[Piorjade]

https://github.com/hwfly-nx/firmware/blob/master/firmware/src/mmc_sniffer.c

This is the MCU‘s side. I‘m writing the actual serial connection which originally the FPGA did on the HWFLY. Thank you though.