fb3534553b
- FastAPI Web-UI auf 127.0.0.1:8080 mit Geräte-Live-Erkennung, sandboxed File-Browser, Firmware-Library (SQLite + Auto-Identifikation) - Huawei update.app Parser: extrahiert Hardware-ID, Section-Layout, BOOT/SYSTEM-Vorhandensein direkt aus den Headern - Kirin Download-Mode: hisi-idt-Protokoll-Implementation gegen pyusb - USB-Erkennung für Huawei (DLOAD/Fastboot-D), Google, MediaTek, Qualcomm EDL - Huawei-P10-Lite-Workflow (eRecovery + Testpoint-DLOAD-Pfade) - Docker-Compose mit USB-Passthrough (Major 189) für Re-Enumeration - udev-Regeln + Setup-Script für Debian/Ubuntu/Pi-OS Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| aubox | ||
| docs | ||
| firmware | ||
| loaders | ||
| scripts | ||
| udev | ||
| .dockerignore | ||
| .gitignore | ||
| Dockerfile | ||
| README.md | ||
| docker-compose.yml | ||
| requirements.txt | ||
README.md
android-unlock-and-more-box
Open-Source-Werkzeugkasten für Android-Recovery (FRP, Bootloader-Tasks, NV-Reparatur). Läuft auf jedem Linux-PC oder Pi 4 — der PC ist in der Regel die bessere Wahl (schneller bei CRC, schneller bei Firmware-Dumps, mehr RAM). Pi 4 ist nett wenn man ein dediziertes Werkstatt-Gerät will. Kein Voodoo, keine Wunder — Aggregation öffentlicher Protokolle und Workflows.
Status
Pre-Alpha. Aktueller Fokus: Huawei P10 Lite (WAS-LX1, Kirin 658) ohne funktionierenden Bootloader-Unlock und ohne IMEI/NV.
Siehe docs/huawei-p10-lite.md.
Was das hier ist — und was nicht
Ist:
- Lokale Web-UI (FastAPI, kein Build-Step, kein Node)
- Geräte-Erkennung über USB-VID:PID, live im Browser
- Datei-Browser sandboxed auf die Firmware-Library
- SQLite-Index der Firmware-Library mit Auto-Identifikation
(Huawei
update.appvoll, MTK/Samsung als Stub) - Wrapper um
adb,fastboot,pyusb - Implementierung des Kirin-Download-Mode-Protokolls (hisi-idt)
- Geräte-spezifische Workflows mit klaren Schritt-für-Schritt-Anweisungen
- Läuft auf jedem Linux-System: PC, Pi 4, Container
Ist nicht:
- Ersatz für Octopus/UnlockTool/Z3X — die Datenbanken und Loader-Sammlungen dort sind das eigentliche Asset. Hier baust du dir das selbst auf.
- Magic-Exploit-Sammlung. Wenn ein SoC keinen öffentlichen BROM-Bypass hat
(z.B. Kirin 658), braucht es leider Hersteller-Loader, die du selbst
beschaffen musst (siehe
loaders/README.md).
Zwei Wege zum Start
A) Nativ (einfachste Variante)
Funktioniert auf Debian/Ubuntu/Mint/Pi OS gleichermaßen.
sudo bash scripts/setup-linux.sh # einmalig: Pakete + udev + venv
source .venv/bin/activate
python -m aubox detect
python -m aubox p10lite frp-remove --method erecovery
B) Web-UI im Container (empfohlen)
sudo bash scripts/setup-linux.sh # udev-Regeln müssen auf dem Host liegen
docker compose up -d
Browser auf http://127.0.0.1:8080. Fertig. Smartphone per USB anstecken, Geräte-Seite zeigt es live mit dem erkannten Modus.
Was die Compose-Datei macht:
./firmware↔/firmware(read-write, hier liegt deine Firmware-Library + SQLite-Index)./loaders↔/loaders(read-only, Hersteller-Loader)/dev/bus/usb↔/dev/bus/usb(komplett, damit Re-Enumeration funktioniert)- Port 8080 nur an 127.0.0.1 gebunden — nichts geht ins LAN raus
C) Container per Wrapper-Script (für CLI-Nutzung)
./scripts/run-docker.sh detect
./scripts/run-docker.sh p10lite frp-remove --method dload-erase
PC vs. Pi 4 — kurze Entscheidungshilfe
| Kriterium | Linux-PC | Pi 4 |
|---|---|---|
| Geschwindigkeit | viel schneller | ok |
| Firmware-Dumps (>4 GB) | spürbar besser | langsam (USB shared) |
| Dediziertes Werkstatt-Gerät | nein | ja, kann immer laufen |
| Strom/Mobilität | schlechter | besser |
| USB-3-Bandbreite | volles xHCI | ~250 MB/s effektiv |
Lizenz
Privat, noch nicht entschieden.