Hacking Hardware Picofly - a HWFLY switch modchip

wscp · Mar 21, 2023

Would this work as an alternative, I wonder:

Post automatically merged: Mar 21, 2023

or maybe this? https://aosmd.com/sites/default/files/res/data_sheets/AO3402.pdf

rehius · Mar 21, 2023

Well, since some guys are still reversing the firmware, and PIO has been completely spoiled by flynn, here is the (v2.6) PIO code with my comments. actually, that is the heart of the firmware, like the FPGA part of hwfly.

This reveals like half of inventions totally made.

Code:

.program sd_clk
.side_set 1
.wrap_target
    ; open-drain RST switcher to keep the CPU in reset state
    set pindirs, 0     side 1 ; side-set push-pull eMMC clocker (2mA limit is set to prevent damage)
    irq clear 0        side 0 ; rising edge sync made with IRQs
    set pindirs, 1     side 1
    irq clear 0        side 0
.wrap

.program out_cmd_or_dat
.wrap_target
    out x, 16 ; first word is the write size
    irq wait 0 [1] ; the next cmd will go on falling edge
send_loop:
    out pindirs, 1 ; use open-drain just in case, to prevent 3.3v damage
    jmp x-- send_loop
    irq clear 1  ; unblock the reader
    out NULL, 32 ; clear the osr
.wrap

.program in_cmd_or_dat
.wrap_target
    out x, 32  ;get read size
    irq wait 1 ;wait for cmd send to finish
    irq wait 0 ;sync with clock, next cmd will go at rising edge
data_wait:
    jmp pin, data_wait [1] ; sync pin wait with rising edge
read_loop:
    in pins, 1 ; here we always at the rising edge
    jmp x-- read_loop
    push
.wrap

.program glitch_sniff_cmd
.wrap_target
next_loop:
    mov x, osr ; mmc command pre-loaded bits count (48 - 1 - 1)
wait_for_start_bit:
    wait 0 pin, 31
    wait 1 pin, 31
    jmp pin wait_for_start_bit ; wait for cmd start bit on the rising edge
    wait 0 pin, 31
; waits separated by only 1 instruction, should be able to catch 50 MHz
    in NULL, 1
read_loop:
    wait 1 pin, 31
    in pins, 1 ; command sniffer
    wait 0 pin, 31
    jmp x-- read_loop
    irq clear 2 ; 'some cmd has passed' trigger
    mov x, isr ; save the last 16 bit of command
    push ; send the rest 16 bits of data
    jmp x != y, next_loop ; compare the glitch pattern (0x1351, read block + crc)
    irq clear 0 ; 'glitch pattern' trigger
.wrap

.program glitch_dat_waiter
.wrap_target
    mov x, y    ; data length pre-loaded counter (512 + 16 - 1)
wait_for_start_bit:
    wait 0 pin, 30
    wait 1 pin, 30
    jmp pin wait_for_start_bit ; wait for dat start bit of the rising edge
    wait 0 pin, 30
skip_loop_dat:
    wait 1 pin, 30
    ;in pins, 1 ; data sniffer (not needed anymore, removed to fit 50mhz code)
    wait 0 pin, 30
    jmp x-- skip_loop_dat ; skip the required data ticks
    irq clear 1 ; 'data transfer done' trigger
.wrap

.program glitch_trigger
.side_set 1
.wrap_target
    out x, 32 side 0   ; receive wait timing
    out y, 32 side 0   ; receive pulse timing
    irq wait 0 side 0  ; wait for read 13
    irq wait 1 side 0  ; wait for data transfer
    irq wait 2 side 0  ; wait for status request (should be NOPped for Mariko)
    irq wait 2 side 0  ; wait for status reply (should be NOPped for Mariko)
wait_for_timing:
    jmp x--, wait_for_timing side 0
glitch_en:
    jmp y--, glitch_en side 1
.wrap

jkyoho · Mar 21, 2023

The backlight fpc fits my spare SX micro USB flex.

linuxares · Mar 21, 2023

Dee87 said:
thanks thanks :-)

so who is already looking for there broken ps4 controllers

To ebay!

vittorio · Mar 21, 2023

rehius said:

Well, since some guys are still reversing the firmware, and PIO has been completely spoiled by flynn, here is the (v2.6) PIO code with my comments. actually, that is the heart of the firmware, like the FPGA part of hwfly.

This reveals like half of inventions totally made.

Code:

.program sd_clk
.side_set 1
.wrap_target
    ; open-drain RST switcher to keep the CPU in reset state
    set pindirs, 0     side 1 ; side-set push-pull eMMC clocker (2mA limit is set to prevent damage)
    irq clear 0        side 0 ; rising edge sync made with IRQs
    set pindirs, 1     side 1
    irq clear 0        side 0
.wrap

.program out_cmd_or_dat
.wrap_target
    out x, 16 ; first word is the write size
    irq wait 0 [1] ; the next cmd will go on falling edge
send_loop:
    out pindirs, 1 ; use open-drain just in case, to prevent 3.3v damage
    jmp x-- send_loop
    irq clear 1  ; unblock the reader
    out NULL, 32 ; clear the osr
.wrap

.program in_cmd_or_dat
.wrap_target
    out x, 32  ;get read size
    irq wait 1 ;wait for cmd send to finish
    irq wait 0 ;sync with clock, next cmd will go at rising edge
data_wait:
    jmp pin, data_wait [1] ; sync pin wait with rising edge
read_loop:
    in pins, 1 ; here we always at the rising edge
    jmp x-- read_loop
    push
.wrap

.program glitch_sniff_cmd
.wrap_target
next_loop:
    mov x, osr ; mmc command pre-loaded bits count (48 - 1 - 1)
wait_for_start_bit:
    wait 0 pin, 31
    wait 1 pin, 31
    jmp pin wait_for_start_bit ; wait for cmd start bit on the rising edge
    wait 0 pin, 31
; waits separated by only 1 instruction, should be able to catch 50 MHz
    in NULL, 1
read_loop:
    wait 1 pin, 31
    in pins, 1 ; command sniffer
    wait 0 pin, 31
    jmp x-- read_loop
    irq clear 2 ; 'some cmd has passed' trigger
    mov x, isr ; save the last 16 bit of command
    push ; send the rest 16 bits of data
    jmp x != y, next_loop ; compare the glitch pattern (0x1351, read block + crc)
    irq clear 0 ; 'glitch pattern' trigger
.wrap

.program glitch_dat_waiter
.wrap_target
    mov x, y    ; data length pre-loaded counter (512 + 16 - 1)
wait_for_start_bit:
    wait 0 pin, 30
    wait 1 pin, 30
    jmp pin wait_for_start_bit ; wait for dat start bit of the rising edge
    wait 0 pin, 30
skip_loop_dat:
    wait 1 pin, 30
    ;in pins, 1 ; data sniffer (not needed anymore, removed to fit 50mhz code)
    wait 0 pin, 30
    jmp x-- skip_loop_dat ; skip the required data ticks
    irq clear 1 ; 'data transfer done' trigger
.wrap

.program glitch_trigger
.side_set 1
.wrap_target
    out x, 32 side 0   ; receive wait timing
    out y, 32 side 0   ; receive pulse timing
    irq wait 0 side 0  ; wait for read 13
    irq wait 1 side 0  ; wait for data transfer
    irq wait 2 side 0  ; wait for status request (should be NOPped for Mariko)
    irq wait 2 side 0  ; wait for status reply (should be NOPped for Mariko)
wait_for_timing:
    jmp x--, wait_for_timing side 0
glitch_en:
    jmp y--, glitch_en side 1
.wrap

2.6? New fw?

SorataVP69 · Mar 21, 2023

Hello, Is there a diagram to install the chip with the hwfly Flex cables in the V2 and Oled?

Garius · Mar 21, 2023

Lot of respects for you guys. Huge work here, congrats.
Can someone please give me the values of those resistor, red, blue, green, and those two mosfets in yellow ?

Also do you know with which software can we open leaked HWFly leaks schematics/ board files ? I tried Eagle/Kicad they are not working. Altium works but layout of pcb seems broken (see where the mosfet emplacement should be in white):

Thanks

Phantomas77 · Mar 21, 2023

rehius said:

Well, since some guys are still reversing the firmware, and PIO has been completely spoiled by flynn, here is the (v2.6) PIO code with my comments. actually, that is the heart of the firmware, like the FPGA part of hwfly.

This reveals like half of inventions totally made.

Code:

.program sd_clk
.side_set 1
.wrap_target
    ; open-drain RST switcher to keep the CPU in reset state
    set pindirs, 0     side 1 ; side-set push-pull eMMC clocker (2mA limit is set to prevent damage)
    irq clear 0        side 0 ; rising edge sync made with IRQs
    set pindirs, 1     side 1
    irq clear 0        side 0
.wrap

.program out_cmd_or_dat
.wrap_target
    out x, 16 ; first word is the write size
    irq wait 0 [1] ; the next cmd will go on falling edge
send_loop:
    out pindirs, 1 ; use open-drain just in case, to prevent 3.3v damage
    jmp x-- send_loop
    irq clear 1  ; unblock the reader
    out NULL, 32 ; clear the osr
.wrap

.program in_cmd_or_dat
.wrap_target
    out x, 32  ;get read size
    irq wait 1 ;wait for cmd send to finish
    irq wait 0 ;sync with clock, next cmd will go at rising edge
data_wait:
    jmp pin, data_wait [1] ; sync pin wait with rising edge
read_loop:
    in pins, 1 ; here we always at the rising edge
    jmp x-- read_loop
    push
.wrap

.program glitch_sniff_cmd
.wrap_target
next_loop:
    mov x, osr ; mmc command pre-loaded bits count (48 - 1 - 1)
wait_for_start_bit:
    wait 0 pin, 31
    wait 1 pin, 31
    jmp pin wait_for_start_bit ; wait for cmd start bit on the rising edge
    wait 0 pin, 31
; waits separated by only 1 instruction, should be able to catch 50 MHz
    in NULL, 1
read_loop:
    wait 1 pin, 31
    in pins, 1 ; command sniffer
    wait 0 pin, 31
    jmp x-- read_loop
    irq clear 2 ; 'some cmd has passed' trigger
    mov x, isr ; save the last 16 bit of command
    push ; send the rest 16 bits of data
    jmp x != y, next_loop ; compare the glitch pattern (0x1351, read block + crc)
    irq clear 0 ; 'glitch pattern' trigger
.wrap

.program glitch_dat_waiter
.wrap_target
    mov x, y    ; data length pre-loaded counter (512 + 16 - 1)
wait_for_start_bit:
    wait 0 pin, 30
    wait 1 pin, 30
    jmp pin wait_for_start_bit ; wait for dat start bit of the rising edge
    wait 0 pin, 30
skip_loop_dat:
    wait 1 pin, 30
    ;in pins, 1 ; data sniffer (not needed anymore, removed to fit 50mhz code)
    wait 0 pin, 30
    jmp x-- skip_loop_dat ; skip the required data ticks
    irq clear 1 ; 'data transfer done' trigger
.wrap

.program glitch_trigger
.side_set 1
.wrap_target
    out x, 32 side 0   ; receive wait timing
    out y, 32 side 0   ; receive pulse timing
    irq wait 0 side 0  ; wait for read 13
    irq wait 1 side 0  ; wait for data transfer
    irq wait 2 side 0  ; wait for status request (should be NOPped for Mariko)
    irq wait 2 side 0  ; wait for status reply (should be NOPped for Mariko)
wait_for_timing:
    jmp x--, wait_for_timing side 0
glitch_en:
    jmp y--, glitch_en side 1
.wrap

Oh boy, here we go (again)!!

Thank you @rehius

SorataVP69 · Mar 21, 2023

Phantomas77 said:
The MOSFETs are already present in the cable, you should be just good to go with it only.
The resistors are necessary for filtering signal interference and for booting into SYSMMC, more info just few pages ago.

Thanks

rehius · Mar 21, 2023

vittorio said:
2.6? New fw?

the PIO has been updated since v2.5, so yes, this one should be in the next fw

Mansi · Mar 21, 2023

rehius said:
the PIO has been updated since v2.5, so yes, this one should be in the next fw

what changes or improvements await us?

rehius · Mar 21, 2023

Mansi said:
what changes or improvements await us?

mainly, software update support

Adran_Marit · Mar 21, 2023

rehius said:
mainly, software update support

any idea what sort of time frame to release so I can update my thread?

linuxares · Mar 21, 2023

Adran_Marit said:
any idea what sort of time frame to release so I can update my thread?

Why not give @rehius access to update it? So it's consolidated to one thread?

rehius · Mar 21, 2023

Adran_Marit said:
any idea what sort of time frame to release so I can update my thread?

no idea, there are three more things to make & test for it

detilmalala · Mar 21, 2023

does this tiny friend work?

linuxares · Mar 21, 2023

detilmalala said:
does this tiny friend work?

Isn't the difference just the usb port?

detilmalala · Mar 21, 2023

linuxares said:
Isn't the difference just the usb port?

that i wanna know

SorataVP69 · Mar 21, 2023

rehius said:
Latest firmware here

ChangeLog:

v2.0 + Active MMC communication
v2.1 + Toshiba support
v2.2 + Fix Toshiba boot fail
v2.3 + SanDisk support
v2.4 + Faster Toshiba boot
v2.5 + fix OFW boot

must be RED after USB write. if you see green, set "RGB mode" jumper

WHITE = eMMC write
BLUE = glitch
PURPLE = eMMC boot failure, check CMD / CLK
YELLOW = eMMC write failure, check D0 / unsupported eMMC
CYAN = no reaction to glitch, check mosfet wire
GREEN = success

View attachment 357132
View attachment 357133
View attachment 357135
View attachment 357134
View attachment 357136

View attachment 357137
View attachment 357138
View attachment 360187
View attachment 357139
View attachment 357140
View attachment 360186

Q: What is supported?
A: Erista (v1), Mariko (v2, Lite, OLED)

Q: eMMC types support?
A: Tested on Hynix, Samsung, Toshiba, SanDisk

Q: GREEN, but instant reset
A: Check your soldering, clean flux. If does not help = add 20K-30K to RST

Q: Do I really need 47 Ohm resistors?
A: You can skip them, however in this case you will have to use emuMMC due to the line interference, sysNAND would not boot.

Q: Does the firmware has learning? How to reset statistics
A: Short pin 0 to either 1 or GND during start for chip reset. The statistics is collected each boot. The more you start it - the better it boots.

Q: open source?
A: no

Q: why you made it?
A: to prove it possible!

Q: run Atmosphere?
A: no piracy

By using the Atmosphere unlock tool you agree to use it for homebrew only.

Way 1 (USB): flash the unlock.uf2 into chip by USB
Way 2 (no USB): run picofly_tb from Hekate, need unlock.bin on the SD card

Boot into Full Stock and perform a full system reset.

Hi, sorry for the inconvenience, but is there a diagram to install the chip with the hwfly Flex cables in the V2 and Oled? I saw that there is a diagram for the Lite that uses the third pin of the Flex cable to take it to the "cpu" pinout on the rp2040, I don't know if this also applies to the V2 and the Oled

Adran_Marit · Mar 21, 2023

detilmalala said:
does this tiny friend work?

Yes, resistors still needed tho

Hacking Hardware Picofly - a HWFLY switch modchip

Member

Well-Known Member

Well-Known Member

Attachments

The inadequate, autocratic beast!

Well-Known Member

Active Member

New Member

Well-Known Member

Active Member

Well-Known Member

Well-Known Member

Well-Known Member

Walküre's Hacker

The inadequate, autocratic beast!

Well-Known Member

Well-Known Member

Attachments

The inadequate, autocratic beast!

Well-Known Member

Active Member

Attachments

Walküre's Hacker

Similar threads

Popular threads in this forum