GhostLock para Humane AI Pin

GhostLock para Humane AI Pin es una prueba de concepto de root de código abierto, limitada al arranque, para una compilación de firmware de venta al público exacta. Ejercita CVE-2026-43499, un use-after-free de rtmutex de Linux, desde un shell ADB autorizado ordinario.

El ejecutor es deliberadamente restrictivo. Comprueba la huella completa del firmware, la compilación del kernel, el slot, el UID del shell y el estado de SELinux antes de preparar nada. Una discrepancia detiene la ejecución.

[!WARNING] Este es un exploit de kernel. Puede provocar un pánico, reiniciar o bloquear por completo el Pin. Un bloqueo total puede requerir desenchufar el dispositivo y esperar a que se agote la batería. Úsalo solo en un Pin que poseas y que puedas permitirte recuperar. El root desaparece al reiniciar.

Objetivo probado

El slot _a, el firmware de desarrollador, las versiones de firmware cercanas y otros productos Qualcomm atoll se rechazan. Consulta los detalles de compatibilidad. Una huella de Android coincidente no basta para eludir esta comprobación: los slots A/B pueden contener imágenes de arranque y diseños de kernel diferentes bajo la misma identidad de compilación del espacio de usuario.

Antes de empezar

Necesitas:

• un Pin de tu propiedad ya autorizado para ADB;
• una conexión USB de datos estable y alimentación externa;
• adb, Python 3.10 o posterior, make y un compilador de C;
• Android NDK 28.2.13676358 (r28c) para compilar el payload.

Este repositorio no contiene una clave privada de ADB, una imagen de firmware, una imagen de arranque, un bugreport, un registro del dispositivo ni un payload precompilado.

Instala el NDK fijado con las herramientas de línea de comandos de Android:

sdkmanager "ndk;28.2.13676358"

Confirma que ADB ya detecta el Pin como device:

$ adb devices
List of devices attached
YOUR_SERIAL    device

Ejecútalo

Clona el repositorio y usa el mismo serial explícito en todos los 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 es de solo lectura. Imprime el firmware detectado, el kernel, el slot, el límite del shell, el estado de SELinux, la batería, la fuente de alimentación y la revisión del NDK.

run realiza un único intento protegido. Te pide que escribas ROOT YOUR_SERIAL, compila desde el código fuente, verifica el hash del payload después de enviarlo, captura un bugreport del arranque actual para derivar KASLR, elimina ese bugreport sin procesar de forma predeterminada y solo inicia el exploit tras una segunda comprobación previa completa.

verify solicita de forma independiente al broker de root limitado al arranque que ejecute id y getenforce.

Una verificación correcta tiene este aspecto:

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

El contexto exacto de SELinux es específico del kernel y del firmware. La condición de aceptación es UID/GID 0 a través del broker con SELinux en modo permisivo en el mismo arranque.

Qué modifica el PoC

Para el arranque actual, el payload:

1. reemplaza los punteros de credenciales del proceso del exploit por init_cred;
2. desactiva el modo enforcing de SELinux y recarga la política actual;
3. escribe un pequeño cliente de comandos en /data/local/tmp/su;
4. inicia un broker de socket Unix que solo acepta pares con UID 0 autenticado por el kernel o UID 2000 del shell de Android.

No escribe una partición, no desbloquea el bootloader, no instala un módulo, no modifica el arranque verificado, no crea persistencia tras el reinicio, no contacta con ningún servicio de red ni sube telemetría.

Ejecuta un comando de root desde otro shell ADB con:

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

Fallo y recuperación

El ejecutor permite un intento por arranque del kernel. Si informa de un fallo, un timeout, una desconexión, un estado incierto, un pánico o un reinicio, no lo reintentes en ese arranque. Reinicia primero y ejecuta check de nuevo.

Si ADB sigue respondiendo:

adb -s YOUR_SERIAL reboot

Si el Pin está bloqueado por completo y ADB no responde, desconecta toda la alimentación externa. El hardware de venta al público probado no tiene un reinicio forzado fiable accesible al usuario, por lo que la recuperación puede requerir esperar a que se agote la batería antes de volver a conectar la alimentación.

Tras un reinicio normal, el root desaparece. Los archivos preparados pueden permanecer inertes bajo /data/local/tmp; un shell limpio puede eliminarlos:

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'

Lee SAFETY.md antes de usar el PoC y TROUBLESHOOTING.md antes de reintentar una ejecución fallida.

Registros privados e informes de problemas

Los registros de ejecución se escriben en un directorio temporal con modo 0700. Contienen un serial del dispositivo, la identidad de arranque, direcciones del kernel y telemetría del exploit. Nunca adjuntes ese directorio ni un bugreport sin procesar de Android a un issue.

Crea en su lugar un informe reducido:

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

Revisa el JSON antes de compartirlo. El redactor omite seriales, IDs de arranque, rutas del host, salida de comandos sin procesar y direcciones del kernel. Consulta PRIVACY.md.

Compilación y pruebas

Compila el payload de Android:

./ghostlock build

Ejecuta todas las pruebas del host y dos compilaciones independientes:

./scripts/verify-release.sh

El payload se escribe en:

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

Los productos de compilación son ignorados por Git. Los artefactos de la release deben verificarse con las sumas de comprobación adjuntas a la release correspondiente de GitHub.

Cómo funciona

El exploit usa el rt_mutex_waiter colgante residente en la pila de la CVE para dirigir una actualización controlada del árbol rojo-negro. KernelSnitch primero filtra una dirección de mm_struct mediante el timing del hash de futex. Una puerta de perf-event con el mismo PFN demuestra después que la página slab de orden 3 liberada fue reclamada por datos de socket-buffer controlados antes de que pueda continuar el disparador de la corrupción. Una base KASLR vinculada al arranque se deriva de al menos dos anclas WARN coincidentes del arranque actual. La ruta de lectura/escritura resultante resuelve la tarea actual y realiza el cambio de credenciales limitado al arranque.

El perfil objetivo contiene solo los offsets y símbolos que consume esta ruta. La imagen del kernel y la tabla de símbolos completa no se distribuyen. TECHNICAL.md describe las etapas y las puertas de fallo seguro.

Estado del proyecto

Esta es una release de investigación experimental para un dispositivo de consumo sin soporte. No es una herramienta general de rooteo de Android y no está afiliada a Humane, HP ni CosmOS.

El código está licenciado bajo Apache-2.0. La implementación parte del trabajo CyberMeowfia de NebuSec bajo Apache-2.0; el port para AI Pin y las herramientas de release están documentados en PROVENANCE.md y THIRD_PARTY_NOTICES.md.

Lee SECURITY.md antes de informar de una vulnerabilidad o una preocupación por uso indebido.