GhostLock per Humane AI Pin

GhostLock per Humane AI Pin è una proof of concept open-source di root limitata al boot, per una esatta build firmware retail. Sfrutta CVE-2026-43499, un use-after-free di Linux rtmutex, da una normale shell ADB autorizzata.

Il runner è volutamente ristretto. Verifica l'impronta completa del firmware, la build del kernel, lo slot, lo UID della shell e lo stato di SELinux prima di preparare qualsiasi cosa. Una mancata corrispondenza interrompe l'esecuzione.

[!WARNING] Questo è un exploit del kernel. Può causare panic, riavvio o blocco totale del Pin. Un blocco totale potrebbe richiedere di scollegare il dispositivo e attendere che la batteria si scarichi. Usalo solo su un Pin che possiedi e che puoi permetterti di recuperare. Il root scompare al riavvio.

Target testato

Lo slot _a, il firmware developer, le versioni firmware vicine e altri prodotti Qualcomm atoll sono rifiutati. Vedi dettagli di compatibilità. Un'impronta Android corrispondente non è sufficiente per aggirare questo controllo: gli slot A/B possono contenere immagini di boot e layout del kernel diversi sotto la stessa identità di build dello userspace.

Prima di iniziare

Ti serve:

• un Pin di tua proprietà già autorizzato per ADB;
• una connessione USB dati stabile e alimentazione esterna;
• adb, Python 3.10 o superiore, make e un compilatore C;
• Android NDK 28.2.13676358 (r28c) per compilare il payload.

Questo repository non contiene una chiave privata ADB, un'immagine firmware, un'immagine di boot, un bugreport, un log del dispositivo o un payload precompilato.

Installa l'NDK bloccato con gli strumenti da riga di comando di Android:

sdkmanager "ndk;28.2.13676358"

Verifica che ADB veda già il Pin come device:

$ adb devices
List of devices attached
YOUR_SERIAL    device

Eseguirlo

Clona il repository, poi usa lo stesso seriale esplicito per ogni comando:

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 è in sola lettura. Stampa il firmware rilevato, il kernel, lo slot, il confine della shell, lo stato di SELinux, la batteria, la fonte di alimentazione e la revisione dell'NDK.

run esegue un singolo tentativo controllato. Ti chiede di digitare ROOT YOUR_SERIAL, compila dal sorgente, verifica l'hash del payload dopo averlo inviato, cattura un bugreport del boot corrente per derivare il KASLR, elimina quel bugreport grezzo per impostazione predefinita e avvia l'exploit solo dopo un secondo preflight completo.

verify chiede in modo indipendente al broker root limitato al boot di eseguire id e getenforce.

Una verifica riuscita appare così:

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

Il contesto SELinux esatto è specifico del kernel e del firmware. La condizione di accettazione è UID/GID 0 attraverso il broker con SELinux permissivo sullo stesso boot.

Cosa modifica la PoC

Per il boot corrente, il payload:

1. sostituisce i puntatori alle credenziali del processo exploit con init_cred;
2. disattiva SELinux enforcing e ricarica la policy corrente;
3. scrive un piccolo client di comandi in /data/local/tmp/su;
4. avvia un broker Unix-socket che accetta solo peer con UID 0 autenticato dal kernel o UID 2000 della shell Android.

Non scrive una partizione, non sblocca il bootloader, non installa un modulo, non modifica il verified boot, non crea persistenza al riavvio, non contatta un servizio di rete e non carica telemetria.

Esegui un comando root da un'altra shell ADB con:

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

Fallimento e recupero

Il runner consente un tentativo per boot del kernel. Se segnala un miss, timeout, disconnessione, stato incerto, panic o riavvio, non riprovare su quel boot. Riavvia prima ed esegui di nuovo check.

Se ADB risponde ancora:

adb -s YOUR_SERIAL reboot

Se il Pin è completamente bloccato e ADB non risponde, scollega tutta l'alimentazione esterna. L'hardware retail testato non ha un riavvio forzato affidabile accessibile all'utente, quindi il recupero potrebbe richiedere di attendere che la batteria si scarichi prima di ricollegare l'alimentazione.

Dopo un riavvio normale, il root è scomparso. I file preparati possono rimanere inerti sotto /data/local/tmp; una shell pulita può rimuoverli:

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'

Leggi SAFETY.md prima di usare la PoC e TROUBLESHOOTING.md prima di ritentare un'esecuzione fallita.

Log privati e segnalazioni di problemi

I record di esecuzione vengono scritti in una directory temporanea con modalità 0700. Contengono un seriale del dispositivo, l'identità del boot, indirizzi del kernel e telemetria dell'exploit. Non allegare mai quella directory o un bugreport Android grezzo a una segnalazione.

Crea invece un report ridotto:

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

Esamina il JSON prima di condividerlo. Il redattore omette seriali, boot ID, percorsi host, output grezzo dei comandi e indirizzi del kernel. Vedi PRIVACY.md.

Compilazione e test

Compila il payload Android:

./ghostlock build

Esegui tutti i test host e due build indipendenti:

./scripts/verify-release.sh

Il payload viene scritto in:

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

I prodotti di build sono ignorati da Git. Gli asset di release dovrebbero essere verificati rispetto ai checksum allegati alla corrispondente release GitHub.

Come funziona

L'exploit usa il rt_mutex_waiter pendente sullo stack residente della CVE per instradare un aggiornamento controllato dell'albero red-black. KernelSnitch prima fa trapelare un indirizzo mm_struct tramite il timing dell'hash futex. Un gate perf-event sullo stesso PFN dimostra poi che la pagina slab order-3 rilasciata è stata recuperata da dati controllati del socket-buffer prima che il trigger di corruzione possa procedere. Una base KASLR legata al boot è derivata da almeno due ancore WARN concordanti del boot corrente. La rotta di lettura/scrittura risultante risolve il task corrente ed esegue il cambio di credenziali limitato al boot.

Il profilo target contiene solo gli offset e i simboli consumati da questa rotta. Il kernel Image e la tabella completa dei simboli non sono distribuiti. TECHNICAL.md descrive le fasi e i gate fail-closed.

Stato del progetto

Questa è una release di ricerca sperimentale per un dispositivo consumer non supportato. Non è uno strumento generico di rooting Android e non è affiliata a Humane, HP o CosmOS.

Il codice è concesso in licenza sotto Apache-2.0. L'implementazione parte dal lavoro Apache-2.0 CyberMeowfia di NebuSec; il port per AI Pin e gli strumenti di release sono documentati in PROVENANCE.md e THIRD_PARTY_NOTICES.md.

Leggi SECURITY.md prima di segnalare una vulnerabilità o un problema di abuso.