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, einen Linux-rtmutex-Use-after-Free, aus einer gewöhnlichen autorisierten ADB-Shell aus.

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. Eine Abweichung stoppt den Lauf.

[!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 der Akku entladen ist. Verwende ihn nur auf einem Pin, den du besitzt und dessen Wiederherstellung du dir leisten kannst. Root verschwindet beim Neustart.

Getestetes Ziel

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.

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-Private-Key, kein Firmware-Image, kein Boot-Image, keinen Bugreport, kein Gerätelog und keine vorgebaute Payload.

Installiere das gepinnte NDK mit Androids Kommandozeilen-Tools:

sdkmanager "ndk;28.2.13676358"

Bestätige, dass ADB den Pin bereits als device erkennt:

$ adb devices
List of devices attached
YOUR_SERIAL    device

Ausführen

Klone das Repository und verwende 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 und die NDK-Revision aus.

run führt einen abgesicherten Versuch durch. Es fordert dich auf, ROOT YOUR_SERIAL einzugeben, baut aus dem Quellcode, verifiziert den Payload-Hash nach dem Pushen, erfasst einen Bugreport des aktuellen Boots zur Ableitung von KASLR, löscht diesen rohen Bugreport standardmäßig und startet den Exploit erst nach einem zweiten vollständigen Preflight.

verify fordert unabhängig den boot-gebundenen Root-Broker 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 firmwarespezifisch. Die Akzeptanzbedingung ist UID/GID 0 durch den Broker mit SELinux permissive im selben Boot.

Was der 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 Kommando-Client nach /data/local/tmp/su;
4. startet einen Unix-Socket-Broker, der nur kernel-authentifizierte UID-0- oder Android-Shell-UID-2000-Peers akzeptiert.

Er schreibt keine Partition, entsperrt keinen Bootloader, installiert kein Modul, verändert nicht Verified Boot, erzeugt keine Reboot-Persistenz, kontaktiert keinen Netzwerkdienst und lädt keine Telemetrie hoch.

Führe 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, Timeout, eine Trennung, einen ungewissen Zustand, eine Panik oder einen Neustart meldet, versuche es in diesem Boot nicht erneut. Starte zuerst neu und führe check erneut aus.

Wenn ADB noch antwortet:

adb -s YOUR_SERIAL reboot

Wenn der Pin hart hängt und ADB nicht antwortet, trenne die gesamte externe Stromversorgung. Die getestete Retail-Hardware hat keinen verlässlichen, benutzerzugänglichen erzwungenen Neustart, sodass die Wiederherstellung möglicherweise erfordert, zu warten, bis der Akku entladen ist, bevor die Stromversorgung wieder angeschlossen wird.

Nach einem normalen Neustart ist Root verschwunden. Die vorbereiteten Dateien können unter /data/local/tmp inaktiv verbleiben; eine saubere Shell kann sie entfernen:

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'

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

Private Logs und Issue-Berichte

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

Überprüfe das JSON, bevor du es teilst. Der Redactor lässt Seriennummern, Boot-IDs, Host-Pfade, rohe Kommandoausgaben und Kernel-Adressen weg. Siehe PRIVACY.md.

Bauen und Testen

Baue die Android-Payload:

./ghostlock build

Führe alle Host-Tests und zwei unabhängige Builds aus:

./scripts/verify-release.sh

Die Payload wird geschrieben nach:

source/build/humane-aipin-45.20/bin/preload.so

Build-Produkte werden von Git ignoriert. Release-Assets sollten gegen die Prüfsummen verifiziert werden, die dem entsprechenden GitHub-Release beigefügt sind.

Wie es funktioniert

Der Exploit nutzt den baumelnden, stack-residenten rt_mutex_waiter der CVE, um ein kontrolliertes Rot-Schwarz-Baum-Update zu routen. KernelSnitch leakt zunächst eine mm_struct-Adresse durch Futex-Hash-Timing. Ein Same-PFN-Perf-Event-Gate beweist dann, dass die freigegebene Order-3-Slab-Seite durch kontrollierte Socket-Buffer-Daten zurückgewonnen wurde, bevor der Korruptions-Trigger fortfahren kann. Eine boot-gebundene KASLR-Basis wird aus mindestens zwei übereinstimmenden WARN-Ankern des aktuellen Boots abgeleitet. Die resultierende Lese-/Schreibroute löst die aktuelle Task auf und führt die boot-gebundene Credential-Änderung durch.

Das Zielprofil enthält nur die Offsets und Symbole, die von dieser Route verwendet werden. Das Kernel-Image und die vollständige Symboltabelle werden nicht verteilt. TECHNICAL.md beschreibt die Stufen und Fail-Closed-Gates.

Projektstatus

Dies ist ein experimentelles Forschungs-Release für ein nicht unterstütztes Verbrauchergerät. Es ist kein allgemeines Android-Rooting-Tool und steht in keiner Verbindung zu Humane, HP oder CosmOS.

Der Code ist unter Apache-2.0 lizenziert. Die Implementierung beginnt mit NebuSecs Apache-2.0-Arbeit CyberMeowfia; der AI-Pin-Port und das Release-Tooling sind in PROVENANCE.md und THIRD_PARTY_NOTICES.md dokumentiert.

Bitte lies SECURITY.md, bevor du eine Schwachstelle oder einen Missbrauchsverdacht meldest.