yukonga/ghostlock-app# Aplicación de Ejecución con un Solo Toque GhostLock (CVE-2026-43499)
中文: README_ZH.md
uname -r exacto y rechaza las compilaciones no compatibles, mostrando el estado en la parte superior. Los perfiles integrados se encuentran en app/src/main/assets/kernel_profiles/: un archivo HOCON por versión, index.conf como índice en tiempo de ejecución, y plantillas de familia de versiones <major.minor>-template.conf.Para el flujo de trabajo completo de portabilidad de dispositivos, los enlaces a las plantillas de familia de kernels y la justificación de los ajustes, consulta la Guía de portabilidad de perfiles de kernel.
Las filas marcadas explícitamente como Shizuku required se ejecutan a través de un UserService de shell. Inicia Shizuku con ADB y toca la tarjeta de estado para conceder acceso; todas las demás filas usan la ruta de ejecución normal de la aplicación.
Abre GhostLock y toca Run. KernelSU (me.weishu.kernelsu), ReSukiSU (com.resukisu.resukisu) o KowSU (com.kowx712.supermanager) proporcionan ksud para la carga de módulos; sin él, W1/W2 siguen otorgando uid 0 pero no se carga ningún módulo.
La cadena de ejecución es una canalización de tres componentes: un frontend (arranque/transferencia de root_child), un backend (la primitiva futex CVE-2026-43499) y una ruta de middleware. Las combinaciones catalogadas se instancian en tiempo de compilación; el perfil resuelto selecciona cuál se ejecuta. La ruta compite en dos núcleos: en los kernels tree-waiter 6.6/6.12 el hilo principal martillea select mientras un hilo consumidor perturba la prioridad del waiter; en los kernels compact-waiter 6.1 impulsa getsockopt(TCP_ZEROCOPY_RECEIVE) a través de una página punched-hole; los kernels 5.15 usan el waiter multicast. El par de CPU también proviene del perfil resuelto.
adb/shell no tiene filtro seccomp, por lo que se omite W3 - útil para una verificación rápida:
make -C src ghostlock
./gradlew exportKernelProfiles
adb push build/native/ghostlock /data/local/tmp/ghostlock
adb push build/kernel-profiles/<release>.bin /data/local/tmp/profile.bin
adb shell chmod 755 /data/local/tmp/ghostlock
adb shell /data/local/tmp/ghostlock --load-prebuilt-profile /data/local/tmp/profile.bin
tools/extract_rs deriva los offsets de un boot.img (más un xbl_config.img opcional), un ZIP de OTA completo, o una URL http(s) que apunte a uno. Los kallsyms provienen de --kallsyms o se recuperan de la tabla incrustada en la imagen. pselect_waiter_shift y off_slide_loggers_0_1 se derivan mediante el desensamblador arm64 integrado. Las imágenes MediaTek no tienen xbl_config.img y normalmente tampoco BTF: la dirección de carga física se deriva de _text en kallsyms (se puede sobrescribir con --phys).
Push-Location tools/extract_rs
cargo build --release
Pop-Location
build/extract/release/ghostlock-extract.exe boot.img --xbl-config xbl_config.img --format conf --out profile.conf
build/extract/release/ghostlock-extract.exe OTA.zip --format conf --out profile.conf
--format conf es la salida del extractor: un perfil aplanado y autocontenido (sin líneas include, las constantes compartidas de credenciales/KernelSnitch de 6.x insertadas en línea, la ruta seleccionada a partir de la evidencia de --analysis a menos que --route la sobrescriba). El extractor emite cada campo que la imagen realmente proporciona y omite el resto; nunca rellena huecos con conjeturas de una familia de kernels vecina (6.6 de familia no verificada, el -2 predeterminado, las constantes multicast de 5.15, o un valor phys predeterminado). Cada salida es un candidato no verificado: importable y analizable, con los campos faltantes o inválidos bloqueados por la validación previa a la ejecución de la aplicación, de modo que una ejecución exitosa nunca implica compatibilidad con el dispositivo. En 5.x también deriva la reparación de la referencia de credenciales a partir de init_cred y la geometría multicast a partir de BTF (consulta docs/analysis/extractor-5x-derivation-plan.md). --format json se mantiene para la ruta de importación v1. Para añadir un perfil integrado, completa y valida la plantilla de familia de versiones correspondiente, guárdala como un perfil .conf independiente y añádela a kernel_profiles/index.conf. El antiguo registro C offsets.h está obsoleto y se ha eliminado.
Las imágenes MediaTek no tienen xbl_config.img y normalmente tampoco BTF incrustado, por lo que el extractor no puede derivar las dos direcciones físicas (kernel_phys_load, kernel_phys_offset) a partir de la imagen y las deja como null. El tiempo de ejecución entonces recurre a la fórmula del SoC, que falla en W1 en MediaTek. Rellena ambas ejecutando el extractor independiente tools/mtk-phys/ en un dispositivo con root (lee /proc/iomem) y pegando los valores en las sobrescrituras avanzadas de la aplicación. Consulta MEDIATEK.md.
El extractor desensambla remove_waiter() antes de extraer los offsets. Los kernels con la corrección se rechazan con el código de salida 6; solo continúan los kernels vulnerables.
Una OTA completa se puede analizar enteramente en el teléfono: boot más xbl_config se extraen automáticamente. Pasa --work-dir un directorio con permisos de escritura para la aplicación cuando se ejecute dentro del sandbox de la aplicación. Compilación cruzada y push:
rustup target add aarch64-linux-android
$ndk = "$env:ANDROID_HOME\ndk\<version>\toolchains\llvm\prebuilt\windows-x86_64\bin"
$env:CC_aarch64_linux_android = "$ndk\aarch64-linux-android35-clang.cmd"
$env:AR_aarch64_linux_android = "$ndk\llvm-ar.exe"
$env:CARGO_TARGET_AARCH64_LINUX_ANDROID_LINKER = $env:CC_aarch64_linux_android
Push-Location tools/extract_rs
cargo build --release --target aarch64-linux-android
Pop-Location
adb push build/extract/aarch64-linux-android/release/ghostlock-extract /data/local/tmp/
adb shell /data/local/tmp/ghostlock-extract /sdcard/OTA.zip
Los nuevos kernels ya no necesitan recompilar la aplicación: toca Import offsets.conf (HOCON) y elige el .conf aplanado del extractor, o usa Import offsets.json (v1) para un informe JSON más antiguo. El JSON v1 se convierte dentro de la aplicación, por lo que no hay que hacer push de nada al dispositivo: el nativo siempre parte del documento GLK1 que la aplicación envía por stdin, y compara el uname -r actual con el perfil resuelto antes de rechazar el kernel. Las importaciones se fusionan entre archivos; si una versión ya está almacenada, se pide confirmación antes de sobrescribir.