Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
RootMyVivo-Exploit — GhostLock (CVE-2026-43499) fork de exploit para RootMyVivo Neo — iQOO Neo 11 (PD2520, SM8750, 6.6.89). Solo para investigación autorizada en dispositivos propios. | Kitploit
Herramientas/GitHubGitHub/zenyxx-xd/rootmyvivo-exploit
Seguridad AndroidEscalada de PrivilegiosForensia de MemoriaExplotaciónPost-ExplotaciónSeguridad MóvilDesarrollo de PayloadsExplotación de Binarios
GitHubzenyxx-xd/rootmyvivo-exploit

RootMyVivo-Exploit

GhostLock (CVE-2026-43499) fork de exploit para RootMyVivo Neo — iQOO Neo 11 (PD2520, SM8750, 6.6.89). Solo para investigación autorizada en dispositivos propios.

Ver Repositorio
2hace 16h 39mAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

RMV Exploit — compilación limpia de CVE-2026-43499 para iQOO Neo 11 (PD2520)

Fork de boxiaolanya2008/CVE-2026-43499-Neo11Plus, reelaborado para RootMyVivo Neo: se eliminó todo lo que no necesita nuestro escenario, se conservó el núcleo verificado del exploit sin cambios en los timings.

Qué se eliminó del upstream

ComponenteMotivo
Cambio de fondo de pantalla + matar system_serverprincipal fuente de soft reboot "espontáneos" y cambios de fondo tras el root
io-daemon (puerto 39555)solo lo necesitaba el kernelapp de depuración; la aplicación funciona vía su
overlay tmpfs en /apex/com.android.virt/binpodía colgar zygote/system_server durante el soft reboot (pantalla negra)
Instalación de su en el mount-namespace de adbdla aplicación invoca /data/local/tmp/su por ruta completa
Servicio de arranque 10-neo11-su.shla persistencia la hace la aplicación: persist.adb.tcp.port + adb_keys + ksud
Tablas de offsets de otros dispositivossolo PD2520-BP2A.250605.031.A3
kernelapp (app/)reemplazado por la funcionalidad de la aplicación

Qué se dejó sin cambios

  • Núcleo del exploit: futex PI UAF → pselect fake lock route → heap spray → pipe physrw → root (timings, hilos, estrategia de reclaim — como en la compilación verificada)
  • posture: panic_on_oops=0, panic_on_warn=0 (protección contra pánicos), kptr_restrict/dmesg_restrict, envenenamiento AVC (permissive sin romper policycap)
  • su-daemon: binario cliente + daemon con unix socket, PTY interactivo, forwarding a KernelSU /system/bin/su, cuando este aparece

Instalación de su (nuestro esquema)

El exploit coloca /data/local/tmp/su (0755, root:root, system_file context) y arranca el daemon con socket /data/local/tmp/temp_su.sock. La aplicación invoca su por ruta completa — /apex no se toca en absoluto.

Compilación (en el dispositivo, Termux)

root@kitploit:~
cd exploit
PATH=/data/data/com.termux/files/usr/bin:$PATH \
  make HOST_CLANG=/data/data/com.termux/files/usr/bin/clang \
       NDK_ROOT=/root/android-sdk/ndk/26.1.10909125
  • Termux clang-21 (aarch64, android-host) + NDK r26 sysroot — los wrappers x86_64 del NDK no se ejecutan en el dispositivo, y el sysroot es arquitectónicamente independiente
  • API 34: en NDK r26 no existe el directorio 35, con 35 lld toma silenciosamente libc.a estático desde la raíz (7 MB y bionic dentro del .so)
  • Salida: build/PD2520-BP2A.250605.031.A3/bin/preload.so (~140 KB) y build/embed/su_daemon_aarch64_pie (su, ~11 KB)

Requisitos del entorno de ejecución

  • Kernel 6.6.89-android15-8-g1f71897ac249-abogki467805059-4k (offsets de kallsyms+BTF de este boot.img; cambiar el kernel = regenerar target.h)
  • Ejecución desde el dominio shell (adb): cd /data/local/tmp/rmv && LD_PRELOAD=$PWD/preload.so /system/bin/true

Capa de estabilización (v2)

Qué se añadió sobre el upstream

Configuración por entorno

  • RMV_ATTEMPTS=N — número de intentos completos (por defecto 3)
  • RMV_RETRY_DELAY=N — pausa entre intentos en segundos (por defecto 8)
  • NEO11_* — controles de upstream (delay/nice/attempts) conservados

De dónde vienen los pánicos (análisis)

  1. Fallo de timing — CONFIG_INIT_STACK_ALL_ZERO sobrescribe el stack: el fake waiter se destruye antes de dispararse → rb-tree rebalance sobre un nodo basura → oops. Se mitiga con quiesce + retry (en upstream había una sola oportunidad).
  2. Escritura en dirección basura — tras un reclaim fallido de pipe_buffer el escaneo encuentra un objetivo falso. cred-guard corta los más peligrosos.
  3. panic_on_oops=1 en stock — cualquier oops = reinicio. posture lo pone a 0 justo después del root, pero antes del root la única protección es la precisión.
Descargar herramienta
MecanismoQué haceDe qué protege
safety_quiesceantes de la ruta PI espera loadavg < 4 (hasta 10 s)waiter en un frame ajeno → panic con alta carga del sistema
cred-guardantes de escribir cred verifica que los punteros sean direcciones kernel canónicasescritura de un puntero basura → corrupción instantánea de task_struct → panic
ciclo de reintentoshasta 3 ejecuciones completas (cada una en un fork nuevo) con pausa de 8 slotería de timings: el segundo intento suele pasar, upstream simplemente se rendía
spin adaptativohilos consumer: 200 iteraciones yield → nanosleep(0.2 ms)100% CPU durante todo el exploit