Hacking Hardware Picofly - a HWFLY switch modchip

[rehius]

Wow
Is Android OLED public already?

also firmware includes Auto-HOS-off, but Android did reboot instead - strange

 

[Magnus Hydra]

Wow
Is Android OLED public already?

also firmware includes Auto-HOS-off, but Android did reboot instead - strange

not public yet.

 

[evil_santa]

Let's call it now the switchroot modchip.
Thank you @rehius to bring us this.
Can't wait to finish my switch lite whit this.

 

[malgamer]

tested on my switch oled

 

[Adran_Marit]

This might be a dumb question, but to me, logically, why don't we just use the uf2 we currently have and just overwrite it with the working one, then resale the uf2 after the fact?

I assume there I'd a technical reason why yhag won't actually work

 

[lenoa]

anyone know?
is that cpu mosfet

it goes to hos directly

 

[malgamer]

anyone know?
is that cpu mos

u

anyone know?
is that cpu mosfet

it goes to hos directly

didnt solder the mosfet ?

 

[lenoa]

u

didnt solder the mosfet ?

it does, that thing right below sd card

 

[Adran_Marit]

it does, that thing right below sd card

Either use a mosfet on cpu caps or get the ribbon

 

[malgamer]

it does, that thing right below sd card

yes i saw it, cant boot to hekate?

 

[rehius]

anyone know?
is that cpu mosfet

it goes to hos directly

CYAN = no glitch reaction

MOSFET must be connected very close, very thick wire, or direct solder

on video - very very long very very thin wire. cannot do 20 Amperes

 

[flynnsmt4]

Okay, after taking some time off I decided to look at this again and realized that they're most definitely fingerprinting (or rather, changing behaviour) based on the flash ID. They call flash_get_unique_id as part of an init callback (I thought this was some random flash func) and then continuously copy the unique ID: (lol I initially missed that mov R2, R4)

Based on this data it writes to memory in a specific pattern which is much more complicated to patch out than a simple check; the easiest way to go about this would be if someone dumped a firmware and a unique ID and then emulated it instruction-by-instruction. At the very least it would be helpful to see what they're doing with the 0x110B0 bytes copied from 0x1000297C to the SRAM base (0x20000000). The only problem I see from this would maybe be navigating the function that looks for the sequence on the CMD pin.

I also realized that they probably exit the XIP flash because it runs off of clk_sys which they're changing, because otherwise the dumped firmware.bin would look strange and I don't think the flash would be able to keep up anyways.

For reference, the initially dumped firmware grabs the unique ID in the init routine at 0x10002608, which gets copied into a 256-byte structure at 0x20025868 in the routine at 0x1000070C. Interestingly, the other .uf2s posted here do something slightly different when copying the unique ID, for some reason.

Other than this, I'm basically stuck until someone does what I suggested or if it turns out that binary blob has easy-to-disassemble ARM code.

 

[vittorio]

are the 0.7mm cables for rp2040 soldering ok?

 

[rehius]

are the 0.7mm cables for rp2040 soldering ok?

0.15-0.2mm diameter ok

 

[vittorio]

Thanks

 

[mrdude]

are the 0.7mm cables for rp2040 soldering ok?

If you look at the amount of power you are going to use, you can calculate the wire thickness. For this application you don't need anything more than 25 AWG (0.45mm) - that's more than thick enough, so the 0.7mm wire you are using is fine.

 

[batwings21]

Okay, after taking some time off I decided to look at this again and realized that they're most definitely fingerprinting (or rather, changing behaviour) based on the flash ID. They call flash_get_unique_id as part of an init callback (I thought this was some random flash func) and then continuously copy the unique ID: (lol I initially missed that mov R2, R4)
View attachment 357376
Based on this data it writes to memory in a specific pattern which is much more complicated to patch out than a simple check; the easiest way to go about this would be if someone dumped a firmware and a unique ID and then emulated it instruction-by-instruction. At the very least it would be helpful to see what they're doing with the 0x110B0 bytes copied from 0x1000297C to the SRAM base (0x20000000). The only problem I see from this would maybe be navigating the function that looks for the sequence on the CMD pin.

I also realized that they probably exit the XIP flash because it runs off of clk_sys which they're changing, because otherwise the dumped firmware.bin would look strange and I don't think the flash would be able to keep up anyways.

For reference, the initially dumped firmware grabs the unique ID in the init routine at 0x10002608, which gets copied into a 256-byte structure at 0x20025868 in the routine at 0x1000070C. Interestingly, the other .uf2s posted here do something slightly different when copying the unique ID, for some reason.

Other than this, I'm basically stuck until someone does what I suggested or if it turns out that binary blob has easy-to-disassemble ARM code.

For anyone wanting to reverse engineering this, the focus needs to be on getting both a dump and the unique id of the same working chip. Adding a check to verify the unique id is kindergarten stuff, they wouldn't do that. At minimum they would encrypt the rest of the information using the unique id as a key or part of the key.

 

[rehius]

For anyone wanting to reverse engineering this, the focus needs to be on getting both a dump and the unique id of the same working chip. Adding a check to verify the unique id is kindergarten stuff, they wouldn't do that. At minimum they would encrypt the rest of the information using the unique id as a key or part of the key.

Page 40

 

[Bekir57]

hello guys, there is a problem, after breaking the capacitor at 3.3 v, I got a blue screen error, I hope it's from the capacitor, because at the same time, it short-circuited the 2 cables I connected the mosfet, so I hope tegra x1 is not broken.

 

[derfreaker]

View attachment 357480
hello guys, there is a problem, after breaking the capacitor at 3.3 v, I got a blue screen error, I hope it's from the capacitor, because at the same time, it short-circuited the 2 cables I connected the mosfet, so I hope tegra x1 is not broken.

Dont ask that questions here its for the picofly