GhostLock para Humane AI Pin

GhostLock para Humane AI Pin é uma prova de conceito de root de código aberto, limitada ao boot, para uma compilação exata de firmware de varejo. Ele explora a CVE-2026-43499, um use-after-free de rtmutex do Linux, a partir de um shell ADB autorizado comum.

O executor é deliberadamente restrito. Ele verifica a impressão digital completa do firmware, a compilação do kernel, o slot, o UID do shell e o estado do SELinux antes de preparar qualquer coisa. Uma divergência interrompe a execução.

[!WARNING] Este é um exploit de kernel. Ele pode causar panic, reiniciar ou travar completamente o Pin. Um travamento completo pode exigir desconectar o dispositivo e esperar a bateria descarregar. Use-o apenas em um Pin que você possui e pode se dar ao luxo de recuperar. O root desaparece após a reinicialização.

Alvo testado

Propriedade	Valor aceito
Dispositivo	Humane AI Pin, unidade de varejo
Firmware	`qti/atoll/atoll:12/SKQ1.230401.001/101.000470.45.20:user/release-keys`
Android	12
Kernel	`4.14.190-perf`, compilado em `Mon Nov 4 18:37:23 PST 2024`
Slot	somente `_b`
Arquitetura do kernel	`aarch64`
ABI do Android	`arm64-v8a`
ID do perfil	`humane-aipin-45.20-nov4`
Projeto de compilação	`humane-aipin-45.20`
SHA-256 da Kernel Image	`d4f4e0deb20871fce207f1f095ba1934162081c2f10afaccbb2e6a1e938719fb`
Reprodução do release candidate	Pendente de reprodução final em boot limpo

O slot _a, firmware de desenvolvedor, versões de firmware próximas e outros produtos Qualcomm atoll são rejeitados. Consulte detalhes de compatibilidade. Uma impressão digital Android correspondente não é suficiente para contornar esta verificação: os slots A/B podem conter imagens de boot e layouts de kernel diferentes sob a mesma identidade de compilação do userspace.

A compatibilidade é definida por um manifesto versionado em profiles/. O launcher do host, o executor, o preflight nativo gerado, a geometria do alocador, os símbolos mínimos e o payload compilado estão vinculados a esse mesmo manifesto. Adicionar um slot a um manifesto ainda exige uma reprodução física em boot limpo da Kernel Image exata do perfil.

Antes de começar

Você precisa de:

um Pin de sua propriedade já autorizado para ADB;
uma conexão USB de dados estável e energia externa;
adb, Python 3.10 ou mais recente, make e um compilador C;
Android NDK 28.2.13676358 (r28c) para compilar o payload.

Este repositório não contém chave privada ADB, imagem de firmware, imagem de boot, bugreport, log de dispositivo ou payload pré-compilado.

Instale o NDK fixado com as ferramentas de linha de comando do Android:

sdkmanager "ndk;28.2.13676358"

Confirme que o ADB já reconhece o Pin como device:

$ adb devices
List of devices attached
YOUR_SERIAL    device

Execute

Clone o repositório e use o mesmo serial explícito para cada 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 é somente leitura. Ele imprime o firmware detectado, o kernel, o slot, o limite do shell, o estado do SELinux, a bateria, a fonte de energia, a revisão do NDK e o status da ferramenta de build. Sua saída de diagnóstico mascara o número de série do dispositivo por padrão.

run realiza uma tentativa protegida. Ele solicita que você digite ROOT YOUR_SERIAL, compila a partir do código-fonte, verifica o hash do payload após enviá-lo, captura um bugreport do boot atual para derivar o KASLR, exclui esse bugreport bruto por padrão e inicia o exploit somente após uma segunda verificação prévia completa. O launcher exige pelo menos 20% de bateria e energia externa por padrão, e então o runner verifica ambos novamente imediatamente antes de consumir a única tentativa do boot. --min-battery 0 desativa ambos os bloqueios de energia e é destinado apenas quando a energia estável foi confirmada de forma independente.

verify solicita de forma independente ao broker root com escopo de boot que execute id e getenforce.

Uma verificação bem-sucedida se parece com isto:

uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
SELinux: Permissive
Boot epoch: <redacted>; uptime: <redacted>s

O contexto SELinux exato é específico do kernel e do firmware. A condição de aceitação é UID/GID 0 através do broker com SELinux permissivo no mesmo boot.

O que o PoC altera

Para o boot atual, o payload:

substitui os ponteiros de credenciais do processo de exploit por init_cred;
limpa o modo enforcing do SELinux e recarrega a política atual;
grava um pequeno cliente de comandos em /data/local/tmp/su;
inicia um broker de socket Unix que aceita apenas pares com UID 0 autenticados pelo kernel ou UID 2000 do shell do Android.

Ele não grava em uma partição, não desbloqueia o bootloader, não instala um módulo, não modifica o verified boot, não cria persistência entre reinicializações, não contata um serviço de rede nem envia telemetria.

Execute um comando root a partir de outro shell ADB com:

adb -s YOUR_SERIAL shell '/data/local/tmp/su -c id'

Falha e recuperação

O runner permite uma tentativa por inicialização do kernel. Se ele relatar uma falha, timeout, desconexão, estado incerto, panic ou reinicialização, não tente novamente nessa inicialização. Reinicie primeiro e execute check novamente.

Se o ADB ainda responder:

adb -s YOUR_SERIAL reboot

Se o Pin estiver travado e o ADB não responder, desconecte toda a energia externa. O hardware de varejo testado não possui um reinício forçado confiável e acessível ao usuário, portanto a recuperação pode exigir aguardar a bateria descarregar antes de reconectar a energia.

Após um reboot normal, o root desaparece. Os arquivos preparados podem permanecer inertes em /data/local/tmp; um shell limpo pode removê-los, incluindo as reivindicações de tentativa atômica específicas do 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'

Leia SAFETY.md antes de usar o PoC e TROUBLESHOOTING.md antes de tentar novamente uma execução com falha.

Logs privados e relatórios de problemas

Os registros de execução são gravados em um diretório temporário com permissão 0700. Eles contêm um número de série do dispositivo, identidade de boot, endereços de kernel e telemetria do exploit. Nunca anexe esse diretório ou um bugreport bruto do Android a um problema.

Em vez disso, crie um relatório reduzido:

./ghostlock report /private/tmp/ghostlock-aipin-TIMESTAMP --output ghostlock-report.json

Revise o JSON antes de compartilhá-lo. O redator omite números de série, boot IDs, caminhos do host, saída bruta de comandos e endereços do kernel. Ele inclui durações monotônicas fixas para o preflight, o exploit, a verificação e a execução total, para que as falhas possam ser comparadas sem compartilhar evidências do dispositivo. Consulte PRIVACY.md.

Compilação e teste

Compile o payload Android:

./ghostlock build

Quando existe mais de um perfil respaldado por evidências, selecione um explicitamente:

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

Mais Populares

humane-aipin-ghostlock