initial aubox skeleton: web-UI, kirin DLOAD, firmware library

- 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>

README.md

@@ -0,0 +1,84 @@
+# 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](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.app` voll, 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.
+
+```bash
+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)
+
+```bash
+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)
+
+```bash
+./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.