Hacking Hardware Picofly - a HWFLY switch modchip

[abal1000x]

Hi, thank you for responding.

So those are 3 short flashes?

Yes I checked and it was about 780. same as most of the other connections. Only point I was really not confident in was my CPU point and from my understanding it cannot be checked with diode mode.

edit: After comparing to another video of someone else's error codes, I think they are 3 long flashes which is just the generic "could not glitch" error. Is this always a dat0 issue? Doesn't dat0 have more unique error codes on the list as well such as:

*** No eMMC CMD1 responce (bad eMMC?)
**= No eMMC block 1 read (should not happen)
*=* No eMMC block 0 read (eMMC init failure?)
*== No eMMC CMD1 request (poor wiring, or dead CPU)
=** eMMC init failure during glitch process

I would like to test if I corrupted/killed my emmc. Best way to do that is just to desolder everything and try OFW?

I think its 3 long flash, timeout glitch.
=== Glitch attempt limit reached, cannot glitch

The 3 short flash, cmd1 response not detected, its occured before the glitch (before blue light).

And yes its the dat0 adapter. I experience that timeout glitch too. Measured the diode mode value around 580 then shift it a little bit then measured again its around 600 then, its works.

 

[RatchetRussian]

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?

 

[abal1000x]

I think its 3 long flash, timeout glitch.
=== Glitch attempt limit reached, cannot glitch

The 3 short flash, cmd1 response not detected, its occured before the glitch (before blue light).

And yes its the dat0 adapter. I experience that timeout glitch too. Measured the diode mode value around 580 then shift it a little bit then measured again its around 600 then, its works.

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.

 

[RatchetRussian]

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?

 

[abal1000x]

So the picofly will still glitch it with the corrupted emmc?

The emmc still functioning, only the data inside (program code) is corrupted. So the glitch will work, the loader will work, everything is fine except the OS.

 

[RatchetRussian]

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!

 

[abal1000x]

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.

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.

 

[cgtchy0412]

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.

 

[abal1000x]

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!

As far as i understand, glitch doesn't need any data from the emmc. Watching the glitching on nvidia jetson videos, what i understand (might be wrong), the voltage glitch make the cpu jump the current code address (pc) to our custom address code (the loader). Also modified the bct partition with our fake bct whose signed matched with the loader. So the bootchain worked as usual.

But i have not read any confirmation whether it really could work on blank emmc. Might be need some partition data to be in there. Not so sure of the detail. But in my assumption, it doesn't need any data. I assume the fake bct is enough to boot the loader (payload).

 

[SQc04]

Post automatically merged: Jun 7, 2023

This have problem https://a.aliexpress.com/_mquqLH6 ?

This board has a record of damaging EMMC in my locality

 

[cgtchy0412]

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.

 

[abal1000x]

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?

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.

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.

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.

 

[SQc04]

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

 

[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.

 

[SQc04]

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: Jun 7, 2023

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.

When the cable is impedance matched, if the resistors do not match, it will only cause EMMC slowdown, not damage the data

 

[poiu15]

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.

 

[abal1000x]

If the address is safe, then why this address can affect the whole emmc data consistency? am i missing something?

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.

Also you cannot corrupt something by reading it.

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.

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.

Yes its usually about short circuit. But we need the detail scenario to understand correctly the why and how to prevent it.

 

[Browbon]

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: Jun 7, 2023

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?

 

[cgtchy0412]

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.

 

[abal1000x]

This is why I, specific in Lite already move the Dat0 solder point to an alternate safer place, even though its harder to solder.

Yes, lite is safe.

I silently read, people whose got blackscreen (corupted data) usually oled. My hunch says that Dat0 adapter is the main cause.

People might assume if the pico take out, cut off the whole cable, and take pico out, then its save to boot into ofw, it doesn't. You need to take out the Dat0 adapter (and the mosfet). Because if its Short circuited the dat0 and dat1, when the OS running, it will corrupt the whole data.

For safety reason, take everything out before running the ofw.