pirosap/aquos-r7-ghostlockExploit de root del kernel Linux 5.10 específico para el dispositivo Sharp AQUOS R7 (CVE-2026-43499), que otorga UID 0 temporal con SELinux en modo permisivo y un daemon su.
Port específico para el dispositivo de GhostLock (CVE-2026-43499) sobre Linux 5.10 para el Sharp AQUOS R7. El objetivo validado es el AQUOS R7 (Mineva, SGA202SH/A202SH) ejecutando Android 14 build 03.00.11, kernel 5.10.237-android12-9-00013-gd09ef2e980e0-ab13968955 (SM8450). El objetivo validado anterior, build 03.00.06 / kernel 5.10.218-android12-9-00041-g124993efd06e-ab12385094, se conserva en la etiqueta git v1.0-030006.
Este es un port de aquos-r6-ghostlock (AQUOS R6, kernel 5.4.61-qgki). Cada constante —el manejo de KASLR, la ventana de fuga de selinux_state, los offsets de task/cred, la región scratch de BSS cero— fue rederivada y validada contra el kernel del R7; la geometría de pila del R6 sirvió únicamente como referencia inicial.
Una ejecución exitosa te otorga UID 0 con SELinux en modo permisivo e inicia un pequeño daemon de comandos su. No concede un conjunto completo de capacidades de Linux y el cambio no es persistente: un reinicio restaura el estado del kernel original.
Se requiere el clang del Android NDK con objetivo aarch64-linux-android29 (probado con NDK r30):
make build/ghostlock510 # ~3.4 MB static binary
make strip # optional; ~0.6 MB, same behaviour
Reproducibilidad (calibración 03.00.11): este código fuente, compilado con la cadena de herramientas anterior, es idéntico byte a byte (MD5 25fc1d5d0e92d36c56f00f983a49667d) al binario utilizado en la prueba en dispositivo 03.00.11. El recurso de la release es la forma llvm-strip-eada de exactamente ese binario (598.672 bytes, SHA-256 5c413a80e9fcc41032412f4e0e5183bc723dde9a2e0ace5a6d9c79681b04b9cd). Para la compilación 03.00.06 véase la etiqueta v1.0-030006 (MD5 sin strip fa896ebd361519766b46cc2bab70dea2).
Envía el binario (recurso de la release o tu propia compilación) y ejecútalo una vez:
adb push ghostlock510 /data/local/tmp/ghostlock510
adb shell chmod 755 /data/local/tmp/ghostlock510
adb shell "setsid nohup /data/local/tmp/ghostlock510 --use-setattr --stamp3 --perm-pc --cred-swap --install-su --stamp-off 0xf0 --log /data/local/tmp/ghostlock510.log </dev/null >/dev/null 2>&1 &"
Use el cliente su instalado para los comandos de root (se requiere la ruta completa):
adb shell "/data/local/tmp/su -c 'id; getenforce'"
# uid=0(root) gid=2000(shell) groups=2000(shell) context=u:r:kernel:s0
# Permissive
su se comunica con el daemon del exploit a través de TCP en loopback (puerto 9999); no se adjunta un shell root persistente. Los comandos se basan en líneas, y anidar su dentro de su no funciona. Los programas interactivos (vi, top, …) requieren un PTY; un modo su interactivo sobre el daemon queda como trabajo futuro.
Medido en esta compilación exacta (ver VERIFICATION.md):
Por lo tanto: reinicia, ejecuta ghostlock510 una vez y no lo vuelvas a ejecutar mientras esa sesión siga viva. El reinicio es la vía de limpieza.
Las entradas externas de gran tamaño se omiten deliberadamente en este repositorio:
vmlinux/System.map de la compilación del kernel de Android CI 13968955; la identidad a nivel de byte con el kernel que realmente se ejecuta en el dispositivo se verificó mediante su imagen boot_b (los 23 segmentos PT_LOAD, comparación segmento por segmento). La corrección de la CVE (backport de 5.10.y del 2026-07-21) es posterior a este árbol (HEAD 2025-08-20), y kernel/futex/core.c es idéntico a nivel de blob respecto a la compilación 03.00.06 — la vulnerabilidad sigue presente.v1.0-030006): los offsets provinieron de la compilación del kernel de Android CI 12385094, verificados a nivel de byte mediante la imagen boot_a del dispositivo.--stamp3 / --use-setattr se inspiró en él (no se declara licencia en ese repositorio).