bkerler edl: two dependency lists, a 2021 tag and a 3.62 version string

The declared version is 3.62 while the last release tag is 3.52.1 from 2021

pyproject.toml sets `version = "3.62"` for the `edlclient` distribution, and the release history stops well below it: 3.52.1 and 3.51 both tagged on 2021-08-07, and 3.4 on 2021-06-20. The last push to the default branch is dated 2026-09-19, so the working tree is several years ahead of anything a package index would hand you. The tags also carry no prefix, plain numbers where most projects write `v3.52.1`, which matters if you script a fetch against them. Two consequences follow. A report of "the version I have" is ambiguous until you say whether it came from a tag or from the tree, and the tools installed from a release will not include whatever changed in the Sahara V3 handling described further down.

requirements.txt and pyproject.toml do not list the same dependencies

The two documented install paths resolve different sets. The Linux instructions end with `pip3 install -r requirements.txt`, and that file carries wheel, pyusb, pyserial, docopt, pycryptodome, pycryptodomex, lxml, colorama, capstone, keystone-engine, qrcode, requests, passlib, Exscript and paramiko. The macOS instructions end with `pip3 install .`, which reads pyproject.toml, and its dependency list has pylzma and drops capstone, keystone-engine, qrcode, pycryptodomex and wheel. The version floors are split the same way: docopt carries `>=0.6.2` only in requirements.txt, colorama carries `>=0.4.6` only in pyproject. The apt and brew lines make the gap stranger, because the Linux package list installs liblzma, xz-devel and xz while pylzma is the dependency only the other path declares.

The Windows quick install executes a script fetched from the branch head

Method 1 for Windows is one line to paste into PowerShell:

curl.exe -O https://raw.githubusercontent.com/bkerler/edl/master/install_edl_win10_win11.ps1; .\install_edl_win10_win11.ps1

That downloads a script from the master branch of the repository and runs it in the same breath, with no checksum, no signature and no pinned commit, so what executes is whatever that branch holds at the moment you run it. The repository also ships `autoinstall.sh`, `install-linux-edl-drivers.sh` and `edl.bat` at the root, so the fetch-and-run pattern is not limited to Windows. Method 2 is the manual route: Python 3.10 or newer, git, a normal QC 9008 serial port driver, and the UsbDk 64-bit driver from another project, verified by running `UsbDkController -n` and looking for a device with pid 0x9008.

The manual Windows steps still carry a setup.py install the project no longer needs

The manual instructions say to install Python 3.10 or newer, which matches `requires-python = ">=3.10"` in pyproject.toml. They also warn that if you install Python from the Microsoft Store then `python setup.py install` will fail, adding that the step is not required. That is the residue of an older layout: the project now declares a setuptools build backend in pyproject.toml, and the macOS path uses `pip3 install .`, so nothing in the packaging needs setup.py to be invoked directly. The warning survives in the text anyway. A smaller oddity in the same file is the console script name `boottodwnload`, missing an a, which pyproject.toml and the root module of the same name agree on, so the typo is at least consistent.

Sahara V3 chip identification moved to a command the older protocol never had

This fork exists for one concrete reason, and the README states it as a protocol change rather than a feature. V3 devices stop answering `cmd=0x03` for OEM_PK_HASH_READ and `cmd=0x02` for MSM_HW_ID_READ, so the fork reads the extended chip identifier with `cmd=0x0A`, CHIP_ID_V3_READ, added as a constant in `edlclient/Library/sahara_defs.py` with the parsing in `edlclient/Library/sahara.py` and a branch in `cmd_info()` for version 3 and above. The documented V3 structure places the chip identifier at offset 0, MSM_ID at 36, OEM_ID at 40, MODEL_ID at 42, and an alternative OEM_ID at 44 used when offset 40 reads zero. The author reports testing on OnePlus and OPPO devices on SM8350, SM8450 and SM8550 silicon plus Xiaomi devices, with V1 and V2 left compatible.

The live DVD image ships with published credentials and two download hosts

For anyone who would rather not assemble drivers, the project offers a bootable image called Live DVD V4, based on Ubuntu 22.04 LTS, with the account name user and the password user. It is linked from an androidfilehost listing and from a Google Drive mirror, so there is a fallback if the first host is slow. Both facts are ordinary for a live image and worth stating plainly anyway: it is a downloadable operating system image whose credentials are printed in the README, and the second copy of it lives in a personal Drive folder rather than on a release page of the repository. Anyone auditing what they put on a USB stick should download it once, verify it locally, and treat the mirror as an additional copy of an artifact they did not build.

ModemManager has to go, and the OpenRC instructions stop mid-command

Every Linux distribution block removes ModemManager before anything else: `apt purge modemmanager`, `pacman -R modemmanager`, `systemctl stop` plus `systemctl disable ModemManager`, and for Gentoo the emerge line plus the OpenRC commands. Distributions that ship SELinux are told to put it in permissive mode for the session with `sudo setenforce 0`, with the note that this lasts until the next boot. The Gentoo and OpenRC block is where the text breaks down: the last line reads `rc-service modemma`, which is neither a complete command nor the name of the service it is meant to act on. Everything before it is a removal of the daemon that would otherwise hold the device, and that reasoning is left for the reader to supply.

The root carries prebuilt binaries, three dependency manifests and two extra readmes

Alongside the Python sources, the root holds `fastpwn`, `fastpwn.exe` and `ubidump` as committed binaries, with no build step described for them anywhere in the installation instructions. Dependency information exists three times over: `pyproject.toml`, `requirements.txt` and a `uv.lock`. Documentation exists three times as well, in `README.md`, `API_README.md` and `sierrakeygen_README.md`. Loader material comes from a submodule that `git submodule update --init --recursive` populates, with a separate bkerler/Loaders repository as the other source, and converted loaders are named `msmid_pkhash[8 bytes].bin` into a `Loaders` directory. Two loader conversion paths exist: `fhloaderparse` for a directory of loaders, and `beagle_to_loader` for a capture exported from a Totalphase Beagle 480 adapter as sniffeddata.bin.

Editorial conclusion

Use this toolset only on hardware you own or have written permission to examine, and treat every binary it consumes as untrusted: the loaders are third-party files matched by chip identifiers, and the Windows quick install executes a script downloaded from the branch head with no checksum. Before you start, settle four things. Decide whether you want the tagged 3.52.1 from 2021 or the working tree that declares 3.62, since the branch has moved well past the last release. Pick one dependency path and use it consistently, because `pip3 install -r requirements.txt` and `pip3 install .` do not install the same set. Expect to remove ModemManager and set SELinux to permissive on Linux distributions that ship it, and read the GPLv3 terms in full, since the README states that compiled reuse obliges you to open source your own code. Nothing here needs a paid unlock, a patch or a bypass, and nothing here should be pointed at a device that is not yours.

Frequently asked questions

Official sources

1. bkerler/edl on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases