GhostLock für Humane AI Pin

GhostLock für Humane AI Pin ist ein quelloffener, boot-gebundener Root-Proof-of-Concept für einen exakten Retail-Firmware-Build. Er nutzt CVE-2026-43499 aus, einen Linux-rtmutex-Use-after-Free, und zwar aus einer gewöhnlichen autorisierten ADB-Shell heraus.

Der Runner ist bewusst eng gefasst. Er prüft den vollständigen Firmware-Fingerprint, den Kernel-Build, den Slot, die Shell-UID und den SELinux-Zustand, bevor er irgendetwas vorbereitet. Bei einer Abweichung wird der Lauf abgebrochen.

[!WARNING] Dies ist ein Kernel-Exploit. Er kann den Pin in eine Panik versetzen, neu starten oder hart aufhängen. Ein harter Hänger kann erfordern, das Gerät abzustecken und zu warten, bis sich der Akku entlädt. Verwende ihn nur auf einem Pin, den du besitzt und dessen Wiederherstellung du dir leisten kannst. Root verschwindet beim Neustart.

Getestetes Ziel

Eigenschaft	Akzeptierter Wert
Gerät	Humane AI Pin, Retail-Einheit
Firmware	qti/atoll/atoll:12/SKQ1.230401.001/101.000470.45.20:user/release-keys
Android	12
Kernel	4.14.190-perf, gebaut Mon Nov 4 18:37:23 PST 2024
Slot	nur _b
Kernel-Architektur	aarch64
Android-ABI	arm64-v8a
Profil-ID	humane-aipin-45.20-nov4
Build-Projekt	humane-aipin-45.20
Kernel-Image SHA-256	d4f4e0deb20871fce207f1f095ba1934162081c2f10afaccbb2e6a1e938719fb
Release-Candidate-Replay	Ausstehend, finaler Clean-Boot-Replay

Slot _a, Entwickler-Firmware, benachbarte Firmware-Versionen und andere Qualcomm-atoll-Produkte werden abgelehnt. Siehe Kompatibilitätsdetails. Ein passender Android-Fingerprint reicht nicht aus, um diese Prüfung zu umgehen: A/B-Slots können unterschiedliche Boot-Images und Kernel-Layouts unter derselben Userspace-Build-Identität tragen.

Die Kompatibilität wird durch ein versioniertes Manifest unter profiles/ definiert. Der Host-Launcher, der Runner, das generierte native Preflight, die Allocator-Geometrie, die minimalen Symbole und die gebaute Payload sind an dasselbe Manifest gebunden. Das Hinzufügen eines Slots zu einem Manifest erfordert weiterhin einen physischen Clean-Boot-Replay des exakt profilierten Kernel-Images.

Bevor du beginnst

Du benötigst:

• einen benutzereigenen Pin, der bereits für ADB autorisiert ist;
• eine stabile USB-Datenverbindung und externe Stromversorgung;
• adb, Python 3.10 oder neuer, make und einen C-Compiler;
• Android NDK 28.2.13676358 (r28c), um die Payload zu bauen.

Dieses Repository enthält keinen ADB-Privatschlüssel, kein Firmware-Image, kein Boot-Image, keinen Bugreport, kein Gerätelog und keine vorgebaute Payload.

Installiere das gepinnte NDK mit den Android-Kommandozeilentools:

sdkmanager "ndk;28.2.13676358"

Bestätigen Sie, dass ADB das Pin bereits als device erkennt:

$ adb devices
List of devices attached
YOUR_SERIAL    device

Ausführen

Klonen Sie das Repository und verwenden Sie dann für jeden Befehl dieselbe explizite Seriennummer:

git clone https://github.com/TheAndersMadsen/humane-aipin-ghostlock.git
cd humane-aipin-ghostlock

./ghostlock check --serial YOUR_SERIAL
./ghostlock run --serial YOUR_SERIAL
./ghostlock verify --serial YOUR_SERIAL

check ist schreibgeschützt. Es gibt die erkannte Firmware, den Kernel, den Slot, die Shell-Grenze, den SELinux-Zustand, den Akku, die Stromquelle, die NDK-Revision und den Status der Build-Tools aus. Seine Diagnoseausgabe maskiert standardmäßig die Geräteseriennummer.

run führt einen einzelnen abgesicherten Versuch durch. Es fordert dich auf, ROOT YOUR_SERIAL einzugeben, baut aus dem Quellcode, überprüft den Payload-Hash nach dem Push, erfasst einen Bugreport des aktuellen Boots, um KASLR abzuleiten, löscht diesen rohen Bugreport standardmäßig und startet den Exploit erst nach einer zweiten vollständigen Vorabprüfung. Der Launcher verlangt standardmäßig mindestens 20 % Akku und externe Stromversorgung, dann prüft der Runner beides unmittelbar erneut, bevor er den einzigen Versuch des Boots verbraucht. --min-battery 0 deaktiviert beide Stromsperren und ist nur dann vorgesehen, wenn eine stabile Stromversorgung unabhängig bestätigt wurde.

verify fordert den boot-gebundenen Root-Broker unabhängig auf, id und getenforce auszuführen.

Eine erfolgreiche Verifikation sieht so aus:

uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
SELinux: Permissive
Boot epoch: <redacted>; uptime: <redacted>s

Der exakte SELinux-Kontext ist kernel- und firmware-spezifisch. Die Akzeptanzbedingung ist UID/GID 0 über den Broker bei permissivem SELinux im selben Boot.

Was das PoC ändert

Für den aktuellen Boot führt die Payload Folgendes aus:

1. ersetzt die Credential-Zeiger des Exploit-Prozesses durch init_cred;
2. deaktiviert SELinux-Enforcing und lädt die aktuelle Policy neu;
3. schreibt einen kleinen Befehlsclient nach /data/local/tmp/su;
4. startet einen Unix-Socket-Broker, der ausschließlich kernel-authentifizierte UID-0- oder Android-Shell-UID-2000-Peers akzeptiert.

Es schreibt keine Partition, entsperrt keinen Bootloader, installiert kein Modul, verändert nicht Verified Boot, erzeugt keine Reboot-Persistenz, kontaktiert keinen Netzwerkdienst und überträgt keine Telemetrie.

Führen Sie einen Root-Befehl aus einer anderen ADB-Shell aus mit:

adb -s YOUR_SERIAL shell '/data/local/tmp/su -c id'

Fehler und Wiederherstellung

Der Runner erlaubt einen Versuch pro Kernel-Boot. Wenn er einen Fehlschlag, ein Timeout, eine Trennung, einen ungewissen Zustand, eine Panik oder einen Neustart meldet, nicht auf diesem Boot erneut versuchen. Zuerst neu starten und check erneut ausführen.

Wenn ADB weiterhin antwortet:

adb -s YOUR_SERIAL reboot

Wenn der Pin hart hängt und ADB nicht reagiert, trennen Sie die gesamte externe Stromversorgung. Die getestete Einzelhandelshardware hat keinen zuverlässigen, benutzerzugänglichen erzwungenen Neustart, sodass die Wiederherstellung möglicherweise erfordert, zu warten, bis sich der Akku entlädt, bevor die Stromversorgung wieder angeschlossen wird.

Nach einem normalen Neustart ist root weg. Die abgelegten Dateien können unter /data/local/tmp inaktiv bleiben; eine saubere Shell kann sie entfernen, einschließlich der boot-spezifischen atomaren Versuchsansprüche:

adb -s YOUR_SERIAL shell 'rm -f /data/local/tmp/ghostlock-aipin.so /data/local/tmp/su /data/local/tmp/.ghostlock-su.sock /data/local/tmp/.ghostlock-aipin-attempt'
adb -s YOUR_SERIAL shell 'rm -rf /data/local/tmp/.ghostlock-aipin-attempt.*.lock'

Lies SAFETY.md, bevor du das PoC verwendest, und TROUBLESHOOTING.md, bevor du einen fehlgeschlagenen Lauf erneut versuchst.

Private Protokolle und Fehlerberichte

Laufaufzeichnungen werden in ein temporäres Verzeichnis mit Modus 0700 geschrieben. Sie enthalten eine Geräteseriennummer, Boot-Identität, Kernel-Adressen und Exploit-Telemetrie. Hänge dieses Verzeichnis oder einen rohen Android-Bugreport niemals an ein Issue an.

Erstelle stattdessen einen reduzierten Bericht:

./ghostlock report /private/tmp/ghostlock-aipin-TIMESTAMP --output ghostlock-report.json

Prüfe die JSON-Datei, bevor du sie teilst. Der Redactor lässt Seriennummern, Boot-IDs, Host-Pfade, rohe Befehlsausgaben und Kernel-Adressen weg. Er enthält feste monotone Dauern für Preflight, Exploit, Verifikation und den gesamten Lauf, damit Fehler verglichen werden können, ohne Gerätebeweise zu teilen. Siehe PRIVACY.md.

Bauen und testen

Baue das Android-Payload: