GhostLock — OnePlus 15T

Exploit de kernel dirigido a dispositivos OnePlus 15T con bootloader bloqueado. Utiliza CVE-2026-43499 para obtener acceso root sin desbloquear el bootloader ni modificar boot.img.

Solo para investigación de seguridad autorizada y fines educativos.

Modificado a partir del repositorio original GhostLock-for-OnePlus, adaptado para el diseño de memoria física y la temporización de CPU del OnePlus 15T (PLZ110 / SM8850 / Snapdragon 8 Elite).

---

Tabla de contenidos

• Resumen de la vulnerabilidad
• Dispositivos compatibles
• Requisitos previos
• Compilación
• Uso
• Modos de ejecución
• Detalles técnicos
• Estructura de archivos
• Añadir nuevos dispositivos
• Preguntas frecuentes

---

Resumen de la vulnerabilidad

Elemento	Detalle
CVE	CVE-2026-43499
Tipo	Use-After-Free de Futex PI (herencia de prioridad)
Alcance	Kernel de Linux 2.6.39 ~ 7.1
Corregido en	Mainline 7.1 (commit 3bfdc63936dd)
Estado en Android	GKI 6.12.x sigue siendo vulnerable

Causa raíz

La llamada al sistema pselect6 copia fd_set a la pila del kernel. Cuando se combina con el mecanismo de espera de futex PI, un marco de pila liberado puede reasignarse como una estructura rt_mutex_waiter. Durante el recorrido de la cadena PI, el reequilibrado del árbol rb escribe datos controlados en direcciones arbitrarias del kernel.

Cadena

futex PI UAF (CVE-2026-43499)
  ├─ Forge rt_mutex_waiter object
  ├─ Control kernel stack via pselect/select fd_set layout
  ├─ Trigger rt_mutex PI operation for arbitrary write
  ├─ Write 1: selinux_state.enforcing = 0
  └─ Write 2: cred → init_cred (uid=0, full capabilities)

---

Dispositivos compatibles

Dispositivo	Nombre clave	SoC	Kernel	Firmware	Estado
OnePlus 15T	PLZ110	SM8850 (Snapdragon 8 Elite)	6.12.38-android16-5-g844001fb8721-ab14552068-4k	ColorOS 16.0.9.400	✅ Verificado

Para Ace 6T y OnePlus 15, consulta el repositorio original.

---

Requisitos previos

ksud (requerido para KernelSU)

GhostLock gestiona la escalada de privilegios. La instalación de KernelSU requiere ksud (incluido junto con kernelsu.ko específico de KMI):

Fuente	Notas
APK de ReSukiSU (recomendado)	Instala ReSukiSU; el APK incluye libksud.so
Lanzamiento de CI	Descárgalo de CI de ReSukiSU (ksud-aarch64-linux-android.zip)

Sin ksud, el exploit sigue obteniendo una shell root con uid=0, pero KernelSU no se instalará y su no persistirá.

---

Compilación

Requisitos previos

• Android NDK (r25+)
• Configura ANDROID_NDK_HOME o ANDROID_NDK_ROOT

Compilar

# Default (API 35)
make

# Specify API level
make API=34

# Specify NDK path
NDK=/path/to/android-ndk make

Artefacto

ghostlock — ejecutable ELF ARM64 enlazado estáticamente.

---

Uso

Configuración inicial

# 1. Enable ADB TCP mode
adb tcpip 5555

# 2. Push ADB key (required for bootstrap mode)
adb push ~/.android/adbkey /data/local/tmp/a/adbkey

# 3. Push the exploit
adb push ghostlock /data/local/tmp/a/e
adb shell chmod 755 /data/local/tmp/a/e

Tras el primer éxito, resetprop establece automáticamente persist.adb.tcp.port=5555, lo que permite ejecuciones totalmente automáticas en reinicios posteriores.

---

Modos de ejecución

Exploit completo (contexto de shell ADB)

/data/local/tmp/a/e

• perf disponible, fuga precisa de la task_struct del proceso hijo
• Dos etapas: W1 desactiva SELinux → W2 escalada de privilegios → carga de KernelSU

Modo bootstrap (contexto de app, seccomp restringido)

/data/local/tmp/a/e --bootstrap

1. Escritura 1 → desactivar SELinux
2. Usa los permisos liberados para habilitar ADB TCP 5555 mediante setprop
3. El cliente Mini ADB integrado se conecta a 127.0.0.1:5555
4. Autenticación RSA con la clave transferida previamente
5. Ejecución del exploit completo a través de la shell ADB (sin seccomp)

Solo escritura 1

/data/local/tmp/a/e --write1

• Hasta 20 intentos
• Útil para depuración o para desactivar SELinux temporalmente

---

Detalles técnicos

1. Coincidencia del kernel en tiempo de ejecución

Los offsets se almacenan en la tabla de búsqueda src/devices/offsets.h, indexada por uname -r. El programa realiza la coincidencia automáticamente al iniciarse; los kernels desconocidos se rechazan.

static const struct kernel_offsets known_offsets[] = {
  OFFSETS_ENTRY("6.12.38-android16-5-...-ab14275539-4k", ...),
  OFFSETS_ENTRY("6.12.38-android16-5-...-ab14552068-4k", ...),
  OFFSETS_ENTRY("6.12.23-android16-5-...-ab14541642-4k", ...),
  { .uname_r = NULL }  /* sentinel */
};

Fuentes de offsets

Tipo	Cantidad	Extracción
Símbolos globales de kallsyms	28	tools/extract_target.py
Campos de estructuras BTF	57	tools/extract_btf.py
Valores derivados	9	Calculados automáticamente
Constantes fijas	12	Codificadas (hardcoded)

Estructuras verificadas por BTF

Estructura	Campos	Propósito
task_struct	17	Descriptor de proceso, cred, seccomp
rt_mutex_waiter	6	Objetivo de falsificación del UAF
cred	4	Credenciales, capacidades
seccomp	3	Estado del filtro de seccomp
pipe_inode_info	11	Operaciones de búfer de pipe
file_operations	13	Tabla fops falsa
mm_struct	1	Propietario del descriptor de memoria

2. Evasión de KASLR

Modo SLIDE — fuga de boot_id

Cuando los punteros del kernel están restringidos (kptr_restrict), la dirección base se filtra a través de boot_id sobrescrito con una dirección del kernel:

Read /proc/sys/kernel/random/boot_id
  └─ UUID contains nfulnl_logger address
      └─ KASLR slide = leaked_addr - image_offset
          └─ kaslr_base

Modo FOPS/CFI — fuga de la tabla fops

Cuando el dispositivo ashmem es accesible, usa las primitivas de lectura/escritura de configfs para leer los punteros a función de la tabla fops de ashmem y calcular el offset de KASLR.

3. Heap spray del kernel

Falsifica objetos del kernel en páginas de orden 3 (32KB):

• file_operations falsa — secuestra el puntero fops del miscdevice ashmem
• rt_mutex_waiter falsa — simula el nodo waiter de la cadena PI
• task_struct falsa — referencia de tarea durante el recorrido de PI
• rt_mutex falsa (bloqueo) — información correcta de waiter/owner

Implementado mediante SKB (socket buffer) + KernelSnitch:

• KernelSnitch — colisión de hash de futex para filtrar direcciones de mm_struct
• SKB spray — sendmsg para llenar el heap del kernel

4. Lectura/escritura de memoria física (pipe)

Tras obtener la base de KASLR, usa los búferes de pipe para acceder a la memoria a nivel físico:

1. Locate pipe buffer in physmap
2. Forge pipe_buffer ops table pointing to known pipe_buf_ops
3. Hijack pipe_buffer.page to target physical address
4. Arbitrary physical read/write via normal pipe operations

Soportadas: pipe_read64, pipe_write64, pipe_phys_read_data, pipe_phys_write_data

5. Escritura en dos etapas

Escritura 1 — desactivar SELinux