Hacking Hardware Picofly - a HWFLY switch modchip

  • Thread starter Thread starter mathew77
  • Start date Start date
  • Views Views 3,667,828
  • Replies Replies 17,052
  • Likes Likes 15
https://github.com/wyattearp/ghidra_uf2loader on ghidra you can try this
Post automatically merged:

i think the (bool)isCurrentModePrivileged() method blocks by id
Post automatically merged:

https://forums.raspberrypi.com/viewtopic.php?t=336409
Post automatically merged:

can anyone try this
What a fantastic read! It’s where we are now…just 6-7 months earlier.

Did you make some changes hence the request for test?

Did you have to do anything special wrt the two sections of encryption?

(I don’t have my Pico wired up in my switch…still working on getting a logic analyzer working fast enough to follow HWFLY.)
 
Hey, just found leaked sources about how hwfly works.
Post automatically merged:

Also I read on 4pda thats fpga used to fastly generate rsa keys to emulate cartridge. I am not completely understand what does it mean. Looks like it is wrong machine translate.
Thanks for the great catch. ;)
Post automatically merged:

What a fantastic read! It’s where we are now…just 6-7 months earlier.
This sure has been a rather interesting read. I can't wait to see how this progress goes into making this possible.
 
@Tafty may you do the honors? :ha:

this one doesnt do anything.

once you put the uf2 on the pico it reboots it to load it...but just goes straight back into bootloader mode where its waiting for a uf2 to be put on it again.

edit checked another one aswell just incase, same thing
 
the function should be the one according to that post, I have to see if with ghidra I can see the functions better
 
Hey, just found leaked sources about how hwfly works.
Post automatically merged:

Also I read on 4pda thats fpga used to fastly generate rsa keys to emulate cartridge. I am not completely understand what does it mean. Looks like it is wrong machine translate.
Can you provide a link to the exact post?
 
  • Like
Reactions: impeeza
Can you provide a link to the exact post?
Posted here: https://gbatemp.net/threads/pikofly-a-probably-fake-hwfly-modchips-or-not.622701/post-10064859

e: save you some time

7F050F81-2C94-4708-844E-E477C2DEE1EE.jpeg
 
  • Like
Reactions: impeeza
Everything what is on this thread.
Yes I just read everything, but have we gotten it to work yet or have we found a way to make it work? because most of the things you talked about I don't understand much, I just wanted to know
 
Yes I just read everything, but have we gotten it to work yet or have we found a way to make it work? because most of the things you talked about I don't understand much, I just wanted to know
At the minute we have proof it does work, but no one is willing to share the original files to make it work, so the short end of it is currently some of the guys in this thread are reverse engineering the dumped firmware from one.

The first hurdle is getting past the encryption
 
At the minute we have proof it does work, but no one is willing to share the original files to make it work, so the short end of it is currently some of the guys in this thread are reverse engineering the dumped firmware from one.

The first hurdle is getting past the encryption
That's pretty cool, I'm really invested in this, if I can help with anything let me know
 
then the firmware once written does a get id and encrypts everything and saves the id, when you dump the file is encrypted but the functions to compare the id are not
 
  • Love
Reactions: impeeza
I've created a repository for an eMMC interface using the RPi Pico, I haven't and currently can't even test it out in reality, though in theory I currently have a CLK signal, CMD sending (48bit packages) and CMD receiving (48bit and 136bit responses, is set when sending to determine which state machine to use, though probably can be even more optimized)

I also have DAT0 receiving, receiving gets triggered through MCU code via an IRQ.

Again, I haven't tested it out at all, I was just following the documentation on the MMC 4.1 interface (downloadable for free on JEDEC's website). Two things missing: I forgot to actively pull the CMD and DAT0 lines to HIGH and also a PIO can only have 32 instructions, which is why I currently don't have DAT0 sending.

I could just load DAT0 sending into the second PIO but my idea was to have everything on one PIO, sadge..

I tried to document what I was doing in the sourcecode, but honestly it's a complete mess and there's still a lot to do.

Anyway, if anyone likes to mess with the Pico's PIOs, here's something to look at I guess:

https://github.com/Overflwn/pico_emmc
 
I've created a repository for an eMMC interface using the RPi Pico, I haven't and currently can't even test it out in reality, though in theory I currently have a CLK signal, CMD sending (48bit packages) and CMD receiving (48bit and 136bit responses, is set when sending to determine which state machine to use, though probably can be even more optimized)

I also have DAT0 receiving, receiving gets triggered through MCU code via an IRQ.

Again, I haven't tested it out at all, I was just following the documentation on the MMC 4.1 interface (downloadable for free on JEDEC's website). Two things missing: I forgot to actively pull the CMD and DAT0 lines to HIGH and also a PIO can only have 32 instructions, which is why I currently don't have DAT0 sending.

I could just load DAT0 sending into the second PIO but my idea was to have everything on one PIO, sadge..

I tried to document what I was doing in the sourcecode, but honestly it's a complete mess and there's still a lot to do.

Anyway, if anyone likes to mess with the Pico's PIOs, here's something to look at I guess:

https://github.com/Overflwn/pico_emmc
Would you be able to make a sketch to dump the raw bus traffic over USB serial? If so, I'll connect a Pico to my Switch and see if this is able to sniff the bus.
 
  • Like
Reactions: impeeza
Would you be able to make a sketch to dump the raw bus traffic over USB serial? If so, I'll connect a Pico to my Switch and see if this is able to sniff the bus.
To sniff the bus, we'd need PIO code that reacts to the Switch's CLK signal, I haven't done that yet. This code currently produces its own CLK signal so it's more useful for reading/writing to eMMC independently from the Switch.

I'll take a look at it tomorrow, maybe I'll figure something out.
I guess one idea would be that this code is specifically for writing the payload to the eMMC (hold RESET pin so that the Switch doesn't interfere -> start CLK and write payload to the eMMC) and after writing the payload we'd have to (re-)start the Switch anyway and that's where the "sniffing PIO code" comes in.

Honestly, even though only sniffing the eMMC data shouldn't do any damage to the Switch, I'm kind of scared of trying to hook it up to an actual Switch :unsure:

The eMMC communication is basically the first important half of the Picofly and honestly I'm surprised that I couldn't find ANYTHING regarding somebody implementing the eMMC protocol on Picos as this is a public and popular type of flash storage..

Other than that, I don't know if I really should dive deeper into this topic after I've successfully implemented the eMMC protocol, big N's ninjas have eyes everywhere.
 

Site & Scene News

Popular threads in this forum