Hacking Hardware Picofly - a HWFLY switch modchip

  • Thread starter Thread starter mathew77
  • Start date Start date
  • Views Views 3,675,526
  • Replies Replies 17,052
  • Likes Likes 15
If you detach Dat0 wire from pico then it will boot into ofw, assuming wires instalation is correct.
Thank you, but it looks like my new switch OLED is bricked :(

Not sure how, but I removed the entire chip alongside all the wires and I can no longer boot into OFW.

I thought I may have weakened the solder balls underneath the emmc so I reflowed it and still nothing. Maybe my emmc got corrupted somehow?

My joints were clean and all the diode mode values were correct. I can't find any shorted caps on the board. Plugging in a usb tester yields the following values:

no battery: 15v 0.057a

with battery: 15v 0.510a (does not fast charge)

are these signs of a dead emmc?
 
  • Like
Reactions: Subtle Demise
I think your emmc is okay (hardware perspective). You might only corrupted the data.

I think your dat0 adapter shortcircuit the Dat0 and Dat1. So when theres write request on CMD, it will corrupt the data.

I think to solve this you need to install the picofly until its worked, then backup the emmc, than rebuild the partition.
So the picofly will still glitch it with the corrupted emmc?
 
The emmc still functioning, only the data inside (program code) is corrupted.
I guess I just need to learn more about the glitching process and how it works internally.

I was not sure if the exploit required the data on the emmc to be intact.

I guess all it needs is a functional chip and the actual data on the chip is not important? Very informative thank you! I will try it as soon as I get my flex cable in the mail so there are less variables! I will also be reballing the emmc. Fuck the DAT0 adapters.

edit: Is this really true? Does that mean if I actually break the emmc, I can just buy a new one for $15 on aliexpress and as long as I install a picofly correctly, it will boot into hekate? I am so behind on the switch scene!
 
Last edited by RatchetRussian,
This is my learning on the glitch (might be wrong), based reading on the code.

The flow is:
1. First the picofly is on (blue light) and the cpu reset.
2. Picofly detect the voltage on CMD, DAT0, RST, if wrong throws the light code and halt.
3. Wait until boot is done. While waiting detect the supposed process via CMD line such as emmc initialization by cpu, then cmd1 request, then cmd1 response.
4. Check emmc read, then write bct to emmc (loader?).
5. Do glitch
If Success (by reading the cmd line for a supposed byte), cpu will run the loader (no sd shows). (short white light), picofly throws short white light than halt.
If failed reset do glitch again with different parameter. (blue light)
If all attempt has been done, but still failed, throws timeout glitch.

So the step number 4 might corrupted the data if the line is not properly prepared.
On step 4, if it writes to emmc then in order to not corrupt it everytime you need to clear it after glitch/shutdown/??, you see any code of clearing/deleting emmc?
Or there is like some safe address which this loader sits on, but then it wont corrupt the emmc because its safe address.
We cannot just write to emmc which is non volatile and then just leave its destiny to an event which may happen or not.
 
This board has a record of damaging EMMC in my locality
Which board specifically?
Also in order to confirm it then you need to install/swap that board to/with a working unit, and if its instantly corrupt the emmc and make the Switch softbrick then you know its the board.
Also compare the same board with another one and look for diferences/defect in one of them that makes that board dangerous.
It may be helpfull for others.
 
Which board specifically?
Also in order to confirm it then you need to install/swap that board to/with a working unit, and if its instantly corrupt the emmc and make the Switch softbrick then you know its the board.
Also compare the same board with another one and look for diferences/defect in one of them that makes that board dangerous.
It may be helpfull for others.
Sorry, I'm replying to a message from Vittorio, maybe the gba has a bug, not quoted
 
  • Like
Reactions: cgtchy0412
The address is safe, the problem is when the CMD/CLK/Dat0 is not properly prepared, the write operation will fault, that will leads to data corruption on the emmc.
If the address is safe, then why this address can affect the whole emmc data consistency? am i missing something?
Also you cannot corrupt something by reading it.
My hunch tells that this corrupted thing is because incorrect voltage for whatever reason, it can be from bad/short wires instalation or from specific board/s, or feedback voltage from incorrect mosfet inst...
etc..
So bottom line is, this mod must be offered with sacrifice then you can only succeed with it or just let it go and move on.:rofl2:
 
If the address is safe, then why this address can affect the whole emmc data consistency? am i missing something?
Also you cannot corrupt something by reading it.
My hunch tells that this corrupted thing is because incorrect voltage for whatever reason, it can be from bad/short wires instalation or from specific board/s, or feedback voltage from incorrect mosfet inst.
I think it should be the impedance mismatch that causes noise to enter the emmc and is written to corrupt the data.There are many considerations for high-speed signal line routing
Post automatically merged:

If the address is safe, then why this address can affect the whole emmc data consistency? am i missing something?
Also you cannot corrupt something by reading it.
My hunch tells that this corrupted thing is because incorrect voltage for whatever reason, it can be from bad/short wires instalation or from specific board/s, or feedback voltage from incorrect mosfet inst...
etc..
So bottom line is, this mod must be offered with sacrifice then you can only succeed with it or just let it go and move on.:rofl2:
When the cable is impedance matched, if the resistors do not match, it will only cause EMMC slowdown, not damage the data
670179BFB518797C141555C689E0D17B.jpg

937658AAAA152CF768AB9351606AFE87.jpg
 
  • Love
Reactions: tspfreitas
If the line CMD/CLK/Dat0 is correct, then the write will success.

Clearing/deleting it doesn't solve the corruption if the line is not properly prepared. Since it simply write again to the emmc which is fault.


The address is safe, the problem is when the CMD/CLK/Dat0 is not properly prepared, the write operation will fault, that will leads to data corruption on the emmc.
Is it possible to detect this kind of problem? I mean if in some stage we know the right value of Dat0 and Dat1, when they are shortcircuited, Dat0 will have the wrong voltage, then pico can throw a error code.
 
Last edited by poiu15,
I think it should be the impedance mismatch that causes noise to enter the emmc and is written to corrupt the data.There are many considerations for high-speed signal line routing
Post automatically merged:


When the cable is impedance matched, if the resistors do not match, it will only cause EMMC slowdown, not damage the data
View attachment 376367
View attachment 376368
It look interesting. May i ask what it is?
 
Is not about the address, but its about the line is not properly prepared. For example if the Dat0 short circuit with the Dat1, then when write command send to the CMD line, any pulse goes to Dat0 will also goes to the Dat1 and vice versa, this signal is the data stream to be written.

The pico also write. Even if you remove the pico but not removing the problematic Dat0 adapter. The HOS (OFW) will also write something to the emmc when he is normally working, which will be fault, since the Dat0 adapter is short circuit.

If i take a guess, its not the pico whose corrupting the data, but the ofw. Because i also experiment on it, but it doesn't failed (blackscreen). When i am experiment i never goes to OFW, only until nosd, then shutdown take the battery off. Maybe people take the pico off, but doesn't take the Dat0 adapter out, then reboot to OFW, which make the data corrupted.

Yes its usually about short circuit. But we need the detail scenario to understand correctly the why and how to prevent it.
This is why I, specific in Lite already move the Dat0 solder point to an alternate safer place, even though its harder to solder.
But on oled i think we need a better procedure to guarantee a perfect Dat0 instalation. Its too risky to just hoping it will work.
Or maybe the adapter should not target directly to Dat0 solder ball but next to it which is not connected.
 
Last edited by cgtchy0412,

Site & Scene News

Popular threads in this forum