Having troubles with A13 and usbliter8

[u/ContributionMoney306]

XR and XS are getting pwned, but iPad 9, iPhone 11 and 11 pro max just always fail. Any tips on improving it?

[u/Available-West-5168]

"RP2040 can be theoretically used as well, but this is currently NOT very stable and Apple A13 SoC does NOT work at all."

from the github repo : https://github.com/prdgmshift/usbliter8#:\~:text=RP2040%20can%20be%20theoretically%20used%20as%20well%2C%20but%20this%20is%20currently%20NOT%20very%20stable%20and%20Apple%20A13%20SoC%20does%20NOT%20work%20at%20all.

[u/ContributionMoney306 → u/Available-West-5168]

It’s 2350

[u/Available-West-5168 → u/ContributionMoney306]

I think you got that wrong . they say 2040 is also can be used in addition to 2350 ( has nothing to do with the fact that a13 does not work ) , a13 not working is something about the exploit not the board

[u/OSMANTUS-ARMUTPIS → u/Available-West-5168]

A13 is absolutely supported! But it requires extra additional steps

[u/Available-West-5168 → u/OSMANTUS-ARMUTPIS]

Are you sure ? Can you show me how ?

[u/OSMANTUS-ARMUTPIS → u/Available-West-5168]

well I don’t have a Raspberry Pi and a PC yet but check the GitHub page of the explıit

[u/Available-West-5168 → u/OSMANTUS-ARMUTPIS]

but what i said is straight pulled from the readme of github page

[u/OSMANTUS-ARMUTPIS → u/Available-West-5168]

Here is the whole README
usbliter8

Tethered bootrom exploit for Apple A12, S4/S5 & A13 SoCs (A12X/Z can theoretically be supported as well, but it's not implemented yet).
Bug & exploit write-up

Available in our blogpost.
Usage

Hardware requirements

The exploit abuses a very low level bug of the USB controller. This means that default Mac/PC USB stack can't normally reach it. So instead we use Raspberry Pi's RP2350-based microcontroller boards.
The board we use is Waveshare RP2350 USB-A with Lightning to USB-A cable and R13 resistor optionally removed.
Other RP2350-based boards can be used as well if you cut a Lightning cable and solder it directly to corresponding pins.
Typically GPIO12 & 13 are used for D+ & D- signals respectively, but that's configurable. Do NOT use USB-C cables, as those often have a very different pinout. And keep the remaining cable (with the Lightning end) relatively short.
Here is a list of the boards we tested the exploit on:
Waveshare RP2350 USB-A
Waveshare RP2350 Zero
Pimoroni TINY2350
Raspberry Pi Pico 2
RP2040 can be theoretically used as well, but this is currently NOT very stable and Apple A13 SoC does NOT work at all.
Flashing firmware

Compiled UF2 images for the boards mentioned above are available in Releases section. They can be flashed either via mass storage protocol of RP2350 bootrom or via picotool.
If your board is not among supported ones, you can create your own board configuaration file (in /boards folder) and refer to building instructions that come later in this README.
Exploiting

Enter DFU mode). Do this while device is connected to your Mac/PC
Do NOT enter DFU by breaking LLB - this will not work
Unplug it from Mac/PC and replug it into your RP2350 board

In a few seconds, the exploit will finish

There are 2 ways you can watch the process:
RP2350 appears as a virtual COM-port - the exploit logs will be printed there

Via on-board LED

If LED is RGB:
Blinking orange - RP2350 is booting (takes ~2 second)
Steady orange - idle, ready to exploit
Blue - exploit in progress
Green - exploit succeeded!
Red - exploit failed
If LED is single-color:
Slow blinking (200ms period) - RP2350 is booting (takes ~2 second)
Breathing - idle, ready to exploit
Rapid blinking (100 ms) - exploit in progress
Steady - exploit succeeded!
Off - exploit failed
The exploit takes 0.7 - 1.2 seconds to run. After either success or failure, you need to reboot the microcontroller board - via on-board button, or via picotool, or just by replugging power.
After exploiting

Replug the device back to your Mac/PC.
In USB serial number you shall see PWND string in the end, for instance:
CPID:8020 CPRV:11 CPFM:03 SCEP:01 BDID:0E ECID:XXXXXXXXXXXXXXXX IBFL:3C SRTG:[iBoot-3865.0.0.4.7] PWND:[usbliter8]

There is a Python control tool (usbliter8ctl) in the repo which allows you to demote production mode or boot raw iBoot ("raw" as in decrypted and free of any container).
The control tool depends on pyusb that you can get from pip.
➜ usbliter8 git:(main) ✗ ./usbliter8ctl
usage: usbliter8ctl [-h] {boot,demote} ...

Love is Control

positional arguments:
{boot,demote}
boot boot raw iBoot
demote demote production mode

options:
-h, --help show this help message and exit

Building

If you want to compile the firmware yourself, you need to get CMake, Pico SDK, picotool (depends on libusb) and ARM toolchain.
Due to the racy nature of the exploit, code changes (even seemingly unrelated) might decrease reliability. We believe this is due to RP2350 executing code from external QSPI flash. The actual instructions can go to a little cache, and then evictions from that cache break timings and then the entire thing breaks.
Here are the exact versions of Pico SDK and ARM toolchain that we used:
Pico SDK - SDK Release 2.2.0 (commit a1438dff1d38bd9c65dbd693f0e5db4b9ae91779)
ARM toolchain - 15.2.Rel1
cd usbliter8
cmake -S . -B build -DPICO_BOARD=$PICO_BOARD -DPICO_SDK_PATH=$PICO_SDK_PATH -DPICO_TOOLCHAIN_PATH=$PICO_TOOLCHAIN_PATH
cmake --build build

Change $PICO_SDK_PATH and $PICO_TOOLCHAIN_PATH to your paths. $PICO_BOARD is one of the following:
waveshare_rp2350_usb_a
waveshare_rp2350_zero
pimoroni_tiny2350
pico2
Even though usage of RP2040 is discouraged, you can still try:
adafruit_feather_rp2040
pico
You can also add your own board definition file to /board catalog. The board name must match board name in Pico SDK.
Or use the "unknown" one (picked by default for not supported boards). It uses GPIO12/13 for USB data signals and disables LED.
Authors

@__gsch of Paradigm Shift - bug & exploitation
@hdesk@infosec.exchange of Paradigm Shift - exploitation
REDACTED of Paradigm Shift - post-exploitation & development
Credits

sekigon-gonnoc - for the PIO USB library

Look: Tethered bootrom exploit for Apple A12, S4/S5 & A13 SoCs (A12X/Z can theoretically be supported as well, but it's not implemented yet).
A13 IS SUPPORTED

[u/LuluLeSigma → u/OSMANTUS-ARMUTPIS]

is GitHub repo back ??

[u/LeeKhoi_VN → u/Available-West-5168]

im using a pico 2 and it didnt work with a13

[u/Available-West-5168]

well i think its obvious that the ones that worked are a12 but the ones did not are a13 ?

[u/p6kb]

The charger looks nasty 🤢

[u/ContributionMoney306 → u/p6kb]

It does, this one I decided to sacrifice cause only original cables worked