GhostLock per Humane AI Pin

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

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

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

Target testato

Proprietà	Valore accettato
Dispositivo	Humane AI Pin, unità retail
Firmware	qti/atoll/atoll:12/SKQ1.230401.001/101.000470.45.20:user/release-keys
Android	12
Kernel	4.14.190-perf, compilato Mon Nov 4 18:37:23 PST 2024
Slot	solo _b
Architettura kernel	aarch64
ABI Android	arm64-v8a
ID profilo	humane-aipin-45.20-nov4
Progetto build	humane-aipin-45.20
SHA-256 immagine kernel	d4f4e0deb20871fce207f1f095ba1934162081c2f10afaccbb2e6a1e938719fb
Replay release-candidate	In attesa del replay finale su boot pulito

Lo slot _a, il firmware per sviluppatori, le versioni firmware vicine e altri prodotti Qualcomm atoll vengono 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 userspace.

La compatibilità è definita da un manifest versionato sotto profiles/. Il launcher host, il runner, il preflight nativo generato, la geometria dell'allocator, i simboli minimi e il payload compilato sono vincolati a quello stesso manifest. Aggiungere uno slot a un manifest richiede comunque un replay fisico su boot pulito dell'esatta immagine kernel profilata.

Prima di iniziare

Ti servono:

• un Pin di tua proprietà già autorizzato per ADB;
• una connessione dati USB stabile e alimentazione esterna;
• adb, Python 3.10 o successivo, 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 i command-line tools 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

Eseguilo

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, la revisione NDK e lo stato del build-tool. Il suo output diagnostico maschera il seriale del dispositivo per impostazione predefinita.

run esegue un singolo tentativo protetto. Ti chiede di digitare ROOT YOUR_SERIAL, compila dal sorgente, verifica l'hash del payload dopo averlo inviato, acquisisce un bugreport del boot corrente per derivare KASLR, elimina quel bugreport grezzo per impostazione predefinita e avvia l'exploit solo dopo un secondo preflight completo. Il launcher richiede almeno il 20% di batteria e alimentazione esterna per impostazione predefinita, poi il runner ricontrolla entrambi immediatamente prima di consumare l'unico tentativo del boot. --min-battery 0 disabilita entrambi i controlli di alimentazione ed è inteso solo quando l'alimentazione stabile è stata confermata in modo indipendente.

verify chiede in modo indipendente al broker root con ambito di 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 in modalità permissiva sullo stesso avvio.

Cosa modifica il PoC

Per l'avvio corrente, il payload:

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

Non scrive su 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'

Errore e ripristino

Il runner consente un solo tentativo per avvio del kernel. Se segnala un mancato riscontro, un timeout, una disconnessione, uno stato incerto, un panic o un riavvio, non riprovare su quell'avvio. Riavviare prima ed eseguire nuovamente check.

Se ADB risponde ancora:

adb -s YOUR_SERIAL reboot

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

Dopo un riavvio normale, il root è assente. I file preparati possono rimanere inerti sotto /data/local/tmp; una shell pulita può rimuoverli, incluse le richieste di tentativo atomico specifiche del boot:

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'

Leggi SAFETY.md prima di usare il 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 permessi 0700. Contengono un numero di serie del dispositivo, l'identità di avvio, 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

Rivedi il JSON prima di condividerlo. Il redattore omette seriali, boot ID, percorsi host, output grezzo dei comandi e indirizzi del kernel. Include durate monotoniche fisse per il preflight, l'exploit, la verifica e l'esecuzione totale, così i fallimenti possono essere confrontati senza condividere prove del dispositivo. Vedi PRIVACY.md.

Compilazione e test

Compila il payload Android:

./ghostlock build

Quando esiste più di un profilo supportato da evidenze, selezionarne uno esplicitamente:

./ghostlock build --profile humane-aipin-45.20-nov4