You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I started doing my research on IPL injection technique, I mostly based my research on Shuriken Attack which uses quite basic method. In short - it listens on boot sequence and counts bits transferred and starts injecting its payload at the correct timing just where BS2 starts.
This approach is a dead end and is not letting me provide any new features. Instead, PicoBoot should act as EXI slave device and process commands issued to IPL chip. This will not only improve IGR (PicoBoot doesn't work on subsequent resets) but also let homebrew communicate with PicoBoot. This means we will be able to read LFS filesystem (#56), update the firmware using DOL file and use WiFi module on Pico W (#57).
I've made some initial tests with Pico talking to homebrew via EXI bus and communication is not really a problem here. The other issue that is present even with current approach has to be addressed too. Basically in order to overpower IPL chip, PicoBoot needs to transmit the same data on multiple GPIO pins at the same time. This is why you have to bridge 2 pins on Pico side. Currently the payload is processed to duplicate all bits 4 times (in theory you only need 2 bits but in practice I couldn't get enough power from 2 GPIOs)
One idea is to store payload unmodified and utilize 2 SMs to output the same payload on 2 different GPIOs. In theory it should have the same effect with the benefit of keeping payloads in raw form.
This feature has the highest priority and it'll be crucial to proceed with other features.
The text was updated successfully, but these errors were encountered:
When I started doing my research on IPL injection technique, I mostly based my research on Shuriken Attack which uses quite basic method. In short - it listens on boot sequence and counts bits transferred and starts injecting its payload at the correct timing just where BS2 starts.
This approach is a dead end and is not letting me provide any new features. Instead, PicoBoot should act as EXI slave device and process commands issued to IPL chip. This will not only improve IGR (PicoBoot doesn't work on subsequent resets) but also let homebrew communicate with PicoBoot. This means we will be able to read LFS filesystem (#56), update the firmware using DOL file and use WiFi module on Pico W (#57).
I've made some initial tests with Pico talking to homebrew via EXI bus and communication is not really a problem here. The other issue that is present even with current approach has to be addressed too. Basically in order to overpower IPL chip, PicoBoot needs to transmit the same data on multiple GPIO pins at the same time. This is why you have to bridge 2 pins on Pico side. Currently the payload is processed to duplicate all bits 4 times (in theory you only need 2 bits but in practice I couldn't get enough power from 2 GPIOs)
One idea is to store payload unmodified and utilize 2 SMs to output the same payload on 2 different GPIOs. In theory it should have the same effect with the benefit of keeping payloads in raw form.
This feature has the highest priority and it'll be crucial to proceed with other features.
The text was updated successfully, but these errors were encountered: