GhostLock para Humane AI Pin

GhostLock para Humane AI Pin es una prueba de concepto de root de código abierto, de alcance limitado 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, la ranura, el UID del shell y el estado de SELinux antes de preparar nada. Cualquier 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 sea de tu propiedad y que puedas permitirte recuperar. El root desaparece al reiniciar.

Objetivo probado

Propiedad	Valor aceptado
Dispositivo	Humane AI Pin, unidad de venta al público
Firmware	qti/atoll/atoll:12/SKQ1.230401.001/101.000470.45.20:user/release-keys
Android	12
Kernel	4.14.190-perf, compilado Mon Nov 4 18:37:23 PST 2024
Ranura	solo _b
Arquitectura del kernel	aarch64
ABI de Android	arm64-v8a
ID de perfil	humane-aipin-45.20-nov4
Proyecto de compilación	humane-aipin-45.20
SHA-256 de la imagen del kernel	d4f4e0deb20871fce207f1f095ba1934162081c2f10afaccbb2e6a1e938719fb
Repetición del candidato a versión	Pendiente de la repetición final en arranque limpio

La ranura _a, el firmware de desarrollador, las versiones de firmware cercanas y otros productos Qualcomm atoll son rechazados. Consulta los detalles de compatibilidad. Una huella de Android coincidente no basta para eludir esta comprobación: las ranuras 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.

La compatibilidad se define mediante un manifiesto versionado en profiles/. El lanzador del host, el ejecutor, la comprobación previa nativa generada, la geometría del asignador, los símbolos mínimos y el payload compilado están vinculados a ese mismo manifiesto. Añadir una ranura a un manifiesto sigue requiriendo una repetición física en arranque limpio de la imagen del kernel perfilada exacta.

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 superior, make y un compilador de C;
• Android NDK 28.2.13676358 (r28c) para compilar el payload.

Este repositorio no contiene ninguna clave privada de ADB, imagen de firmware, imagen de arranque, bugreport, registro del dispositivo ni 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 luego usa el mismo 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 es de solo lectura. Imprime el firmware detectado, el kernel, la ranura, el límite del shell, el estado de SELinux, la batería, la fuente de alimentación, la revisión del NDK y el estado de las herramientas de compilación. Su salida de diagnóstico enmascara el número de serie del dispositivo por defecto.

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 por defecto, e inicia el exploit solo después de una segunda verificación previa completa. El lanzador requiere al menos un 20% de batería y alimentación externa por defecto, luego el ejecutor vuelve a comprobar ambos inmediatamente antes de consumir el único intento del arranque. --min-battery 0 desactiva ambas compuertas de energía y está destinado únicamente a cuando se ha confirmado la estabilidad del suministro eléctrico de forma independiente.

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

Una verificación exitosa se ve así:

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 de exploit con 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 acepta únicamente pares con UID 0 autenticados por el kernel o con 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 root desde otro shell de ADB con:

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

Fallo y recuperación

El runner permite un intento por arranque del kernel. Si reporta un fallo, tiempo de espera agotado, desconexión, estado incierto, panic o reinicio, no reintentar en ese arranque. Reiniciar primero y ejecutar check de nuevo.

Si ADB aún responde:

adb -s YOUR_SERIAL reboot

Si el Pin está bloqueado y ADB no responde, desconecte toda la alimentación externa. El hardware comercial probado no dispone de un reinicio forzado fiable accesible para el usuario, por lo que la recuperación puede requerir esperar a que la batería se agote 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, incluidos los reclamos de intento atómico específicos del arranque:

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'

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 permisos 0700. Contienen un número de serie del dispositivo, identidad de arranque, direcciones del kernel y telemetría del exploit. Nunca adjuntes ese directorio ni un bugreport de Android sin procesar a un issue.

En su lugar, crea un informe reducido:

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