Qué se hizo

1. Análisis del código fuente → extracción de offsets de estructuras

Extraído de arch/arm64/include/asm/memory.h + include/linux/fs.h + android/abi_gki_aarch64.xml:

• Disposición de memoria: KIMAGE_TEXT_BASE = 0xffffffc008000000, VA_BITS=39, DIRECT_MAP=256GB
• task_struct: 36864 bits, completamente analizado (ABI XML layout-offset-in-bits)
• file_operations: sin iopoll (android13 GKI), IOCTL=0x48, open=0x68
• cred: atomic_t usage = 4 bytes, uid=0x04
• struct page: 64 bytes, slab_cache=0x18

Hallazgo clave: el código fuente es android15 GKI, el dispositivo es android13 GKI — los offsets de task_struct difieren en 0x40~0x88 bytes, no se pueden copiar directamente del código fuente.

2. Desempaquetado del firmware → extracción de símbolos

Símbolos extraídos de dos versiones de firmware (15.2.7.6 / 15.2.10.2) — el mismo símbolo difiere entre versiones en 10KB~200KB, hay que usar la versión correcta.

3. Verificación por desensamblado → capstone confirma offsets clave

Esto confirma que la disposición de task_struct es de la rama android15, no la android13 de frankel.

4. Compilación → funciona

NDK r29, make PROJECT=android_15.0_kernel_MT6985 → preload.so (150KB).

5. Ejecución → fallos repetidos

Instrucción del fallo (capstone):

Por qué falló

Causa raíz 1: KernelSnitch no es fiable en MTK

KernelSnitch es la puerta de entrada de todo el exploit — filtra la dirección de mm_struct mediante la diferencia de temporización en los buckets hash de futex:

1. La detección de colisiones funciona — con umbral bajo se encuentran 5 colisiones
2. La coincidencia por bruteforce casi siempre falla — el problema central está en:

Los dispositivos Pixel no tienen KASAN_HW_TAGS, este mecanismo funciona allí. En MTK no.

Causa raíz 2: CONFIG_PANIC_ON_OOPS es el asesino

Y el bootloader está bloqueado (flash.locked=1) → no se puede flashear un kernel personalizado para eliminar esta opción.

Causa raíz 3: Deriva de versión del kernel

Aunque el número de versión mayor es 5.15.178 en ambos, la rama GKI es diferente (android13 vs android15), por lo que la disposición de estructuras clave como task_struct/cred no coincide. Se alternó repetidamente entre los dos conjuntos de offsets (frankel/android15), y solo se pudo confirmar mediante desensamblado.

Ajustes probados (todos inútiles)

Estado actual de target.h

En exploit/targets/android_15.0_kernel_MT6985/target.h:

El ensamblado compila, se ejecuta, pero se pierde en el último kilómetro.

Si quieres continuar

Requisitos necesarios (todos imprescindibles)

1. Eliminar CONFIG_PANIC_ON_OOPS — o flashear un kernel personalizado (requiere desbloquear el bootloader), o encontrar un dispositivo MT6985 que tenga esta opción desactivada por defecto
2. Resolver KernelSnitch — se necesita calibración de temporización de caché para MTK Dimensity 9200, o reemplazar completamente KernelSnitch por otro método de filtración de mm_struct en el exploit

Posibles enfoques alternativos

• /proc/self/pagemap — restringido en este dispositivo (devuelve todo ceros)
• Interfaces de depuración específicas de MTK (/proc/mtk_*) — existen pero requieren más análisis
• Vulnerabilidades de ioctl en los drivers de cámara/GPU de MTK — una vía de escalada más simple
• Esperar a que la comunidad adapte una variante MTK

Valor residual de este repositorio

• symbols/kallsyms_PD2241_15.2.10.2.txt — tabla de símbolos completa de 15.2.10.2, utilizable directamente por otros
• device_config.txt — configuración real del kernel del dispositivo, se puede ver qué cambió el vendor
• exploit/targets/android_15.0_kernel_MT6985/target.h — offsets de estructuras verificados
• scripts/server_compile.py — compilación automatizada, recompilar tras cambiar parámetros es rápido

Lista de tropiezos (para que otros los eviten)

1. Descomprimir archivos en Windows: tar -xf puede fallar con zips grandes, usar Python zipfile o descomprimir primero manualmente
2. Conflicto de versión de protobuf en payload_dumper: el update_metadata_pb2.py generado requiere protobuf 5.x, hay que eliminar manualmente la línea de importación de runtime_version
3. Ejecutar ./preload.so directamente causa segfault: hay que usar /system/bin/linker64 /data/local/tmp/preload.so
4. El ABI XML es más preciso que el código fuente: layout-offset-in-bits lo calcula el compilador, es 100 veces más preciso que contar 5000 bytes a mano
5. La rama GKI afecta a la disposición: task_struct es diferente en android13/14/15, no se pueden copiar offsets entre ramas
6. Versiones de firmware distintas → offsets de símbolos distintos: 15.2.7.6 y 15.2.10.2 difieren en 10KB~200KB
7. El vendor vivo añade muchos campos OEM: CONFIG_ANDROID_VENDOR_OEM_DATA=y, CONFIG_SCHED_INFO=y, CONFIG_RSC_* → se desvía del GKI estándar
8. Cadena de herramientas de extracción de símbolos: boot.img → kernel.bin → descompresión LZ4 → Image → kallsyms-finder → tabla de símbolos

Cronología

2026-07-29, viví para contarlo

2026-07-31 Continuación: verificación y corrección tras tener el código fuente

Tras obtener android_15.0_kernel_MT6985.tar.gz (árbol de código fuente 5.15.178 + ABI XML) se realizó una validación cruzada completa, ver VERIFICATION.md. Resumen:

1. MT6985 = Dimensity 9200 (MT6989 es el 9300), corregido más arriba.
2. Offsets de símbolos 23/23 correctos (verificado con kallsyms), los offsets de task_struct / cred / waiter / page / pipe / configfs coinciden todos con el ABI del árbol de código fuente.
3. Los offsets de FOPS eran erróneos: el valor original se copió de frankel (android13 GKI, sin iopoll, ioctl=0x48); pero la disposición de task_struct del dispositivo (pi_blocked_on=0x8b0, confirmado por desensamblado en tiempo de ejecución) coincide con este árbol de código fuente, por lo que el file_operations del mismo kernel debería tener iopoll@0x30, ioctl=0x50, open=0x70, etc. — se ha corregido target.h, y se utiliza el leak_kernel_base() integrado en el exploit como verificación automática en el dispositivo real.
4. Parche de compatibilidad MTK para KernelSnitch (patches/kernelsnitch_mtk_fixes.patch):
   • El tamaño de la tabla hash de futex en espacio de usuario se ajusta al del kernel (posible CPU + 2 redondeado a potencia de 2), evitando que el bruteforce falle inevitablemente cuando possible≠online;
   • El recorrido de tags MTE añade 0xf (sin tag), y hace que KSNITCH_MTE_ENABLED=1 surta efecto real (el util.c original tenía mte=0 hardcodeado);
   • No afecta a los targets que no son MTK.
5. El punto de fallo rt_mutex_adjust_prio_chain+0x1b0 se encuentra en la fase de la cadena pselect/pi, antes de la autoverificación de FOPS; tras las correcciones anteriores merece la pena volver a probar en el dispositivo.

2026-07-31 Prueba en dispositivo real: KernelSnitch ya funciona, la fase slide sigue siendo un muro

Dispositivo (PD2241, compiler251203103903) — 8+ rondas de pruebas en hardware real:

• KernelSnitch corregido y verificado: MM_STRUCT_SZ=0x400 (el 0x500 original causaba una cuadrícula de escaneo desalineada y solo producía falsos positivos) + recorrido de tags MTE 0..15 (el tag del puntero mm del dispositivo cambia) + direcciones falsas sin tag. Ahora encuentra de forma estable el mm_struct real.
• Cada ronda sigue fallando en rt_mutex_adjust_prio_chain+0x1b0: carrera de temporización en la cadena pselect/pi (el waiter falso no cae en el offset correcto de la pila del kernel). El planificador RSC de vivo modificó la ruta futex/pi, lo que probablemente rompe esta carrera de raíz. La alineación de la pila slide se ha parametrizado como variable de entorno SLIDE_SHIFT, el escaneo no se ha completado.
• Las fases FOPS/pipe/cred aún no se han alcanzado, la verificación en dispositivo real queda pendiente.

Decisión final: optar por desbloquear el bootloader de pago (ya no se depende de esta ruta).