GhostLock para Humane AI Pin

GhostLock para Humane AI Pin é uma prova de conceito de root de código aberto, com escopo de boot, para uma compilação exata de firmware de varejo. Ele explora 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 incompatibilidade interrompe a execução.

[!WARNING] Este é um exploit de kernel. Ele pode causar panic, reinicialização ou travamento total do Pin. Um travamento total 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

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: slots A/B podem carregar imagens de boot e layouts de kernel diferentes sob a mesma identidade de compilação do espaço de usuário.

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 em todos os comandos:

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, kernel, slot, limite do shell, estado do SELinux, bateria, fonte de energia e revisão do NDK.

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 um segundo preflight completo.

verify solicita independentemente ao broker de 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:

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

Ele não grava uma partição, desbloqueia o bootloader, instala um módulo, modifica o verified boot, cria persistência após reinicialização, contata um serviço de rede ou envia telemetria.

Execute um comando root de outro shell ADB com:

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

Falha e recuperação

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

Se o ADB ainda responder:

adb -s YOUR_SERIAL reboot

Se o Pin estiver totalmente travado e o ADB não responder, desconecte toda a energia externa. O hardware de varejo testado não possui reinicialização forçada confiável acessível ao usuário, então a recuperação pode exigir esperar a bateria descarregar antes de reconectar a energia.

Após uma reinicialização normal, o root desaparece. Os arquivos preparados podem permanecer inertes em /data/local/tmp; um shell limpo pode removê-los:

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'

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 modo 0700. Eles contêm um serial de 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 issue.

Crie um relatório reduzido em vez disso:

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

Revise o JSON antes de compartilhá-lo. O redator omite seriais, IDs de boot, caminhos do host, saída bruta de comandos e endereços de kernel. Consulte PRIVACY.md.

Compilação e teste

Compile o payload Android:

./ghostlock build

Execute todos os testes de host e duas compilações independentes:

./scripts/verify-release.sh

O payload é gravado em:

source/build/humane-aipin-45.20/bin/preload.so

Os produtos de compilação são ignorados pelo Git. Os artefatos de release devem ser verificados em relação aos checksums anexados à release correspondente do GitHub.

Como funciona

O exploit usa o rt_mutex_waiter pendente residente na pilha da CVE para encaminhar uma atualização controlada de árvore rubro-negra. O KernelSnitch primeiro vaza um endereço mm_struct através do timing do futex-hash. Um gate de perf-event do mesmo PFN então prova que a página slab de ordem 3 liberada foi recuperada por dados controlados de socket-buffer antes que o gatilho de corrupção possa prosseguir. Uma base KASLR vinculada ao boot é derivada de pelo menos dois âncoras WARN concordantes do boot atual. A rota de leitura/escrita resultante resolve a tarefa atual e realiza a alteração de credencial com escopo de boot.

O perfil alvo contém apenas os offsets e símbolos consumidos por esta rota. O kernel Image e a tabela de símbolos completa não são distribuídos. TECHNICAL.md descreve os estágios e os gates fail-closed.

Status do projeto

Esta é uma versão experimental de pesquisa para um dispositivo de consumo sem suporte. Não é uma ferramenta geral de root para Android e não é afiliada à Humane, HP ou CosmOS.

O código é licenciado sob Apache-2.0. A implementação parte do trabalho CyberMeowfia Apache-2.0 da NebuSec; o port para AI Pin e as ferramentas de release estão documentados em PROVENANCE.md e THIRD_PARTY_NOTICES.md.

Leia SECURITY.md antes de relatar uma vulnerabilidade ou preocupação de uso indevido.