yukonga/ghostlock-app# App di esecuzione con un tocco GhostLock (CVE-2026-43499)
中文: README_ZH.md
uname -r esatto e rifiuta le build non supportate, mostrando lo stato in alto. I profili integrati si trovano in app/src/main/assets/kernel_profiles/: un file HOCON per release, index.conf come indice di runtime e i template di famiglia di versione <major.minor>-template.conf.Per il flusso di lavoro completo di porting del dispositivo, i link ai template di famiglia kernel e la motivazione del tuning, consulta la Guida al porting dei profili kernel.
Le righe contrassegnate esplicitamente con Shizuku richiesto vengono eseguite tramite uno shell UserService. Avvia Shizuku con ADB e tocca la scheda di stato per concedere l'accesso; tutte le altre righe usano il normale percorso di esecuzione dell'app.
Apri GhostLock e tocca Run. KernelSU (me.weishu.kernelsu), ReSukiSU (com.resukisu.resukisu) o KowSU (com.kowx712.supermanager) fornisce ksud per il caricamento dei moduli; senza di esso, W1/W2 concedono comunque uid 0 ma nessun modulo viene caricato.
La catena di esecuzione è una pipeline di tre componenti: un frontend (avvio/handoff di root_child), un backend (la primitiva futex CVE-2026-43499) e una rotta middleware. Le combinazioni catalogate vengono istanziate in fase di build; il profilo risolto seleziona quale viene eseguita. La rotta mette in competizione due core: sui kernel 6.6/6.12 con tree-waiter il thread principale martella select mentre un thread consumer perturba la priorità del waiter; sui kernel 6.1 con compact-waiter pilota getsockopt(TCP_ZEROCOPY_RECEIVE) attraverso una pagina punched-hole; i kernel 5.15 usano il waiter multicast. Anche la coppia di CPU proviene dal profilo risolto.
adb/shell non ha filtro seccomp, quindi W3 viene saltato - comodo per una verifica rapida:
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 ricava gli offset da un boot.img (più un xbl_config.img opzionale), da uno ZIP OTA completo o da un URL http(s) che punta a uno di essi. I kallsyms provengono da --kallsyms oppure vengono recuperati dalla tabella incorporata nell'immagine. pselect_waiter_shift e off_slide_loggers_0_1 sono derivati dal disassembler arm64 integrato. Le immagini MediaTek non hanno xbl_config.img e di solito nemmeno BTF: l'indirizzo di caricamento fisico è derivato da kallsyms _text (sovrascrivibile 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 è l'output dell'estrattore: un profilo appiattito e autosufficiente (nessuna riga include, le costanti condivise 6.x credential/KernelSnitch inline, la rotta selezionata dalle evidenze di --analysis a meno che --route non la sovrascriva). L'estrattore emette ogni campo che l'immagine effettivamente fornisce e omette il resto; non colma mai le lacune con le ipotesi di una famiglia di kernel vicina (6.6 di famiglia non verificata, il -2 predefinito, le costanti multicast 5.15 o un valore phys predefinito). Ogni output è un candidato non verificato: importabile e analizzabile, con i campi mancanti o non validi bloccati dalla validazione pre-esecuzione dell'app, quindi un'esecuzione riuscita non implica mai il supporto del dispositivo. Su 5.x deriva anche la riparazione del riferimento alle credenziali da init_cred e la geometria multicast dal BTF (vedi docs/analysis/extractor-5x-derivation-plan.md). --format json resta per il percorso di importazione v1. Per aggiungere un profilo integrato, completa e valida il template di famiglia di versione corrispondente, salvalo come profilo .conf autonomo e aggiungilo a kernel_profiles/index.conf. Il vecchio registro C offsets.h è deprecato e rimosso.
Le immagini MediaTek non hanno xbl_config.img e di solito nemmeno BTF incorporato, quindi
l'estrattore non può derivare i due indirizzi fisici (kernel_phys_load,
kernel_phys_offset) dall'immagine e li lascia null. Il runtime quindi
ricade sulla formula SoC, che fallisce a W1 su MediaTek. Compila entrambi
eseguendo l'estrattore separato tools/mtk-phys/ su un dispositivo con root (legge
/proc/iomem) e incollando i valori nelle sovrascritture avanzate dell'app. Vedi
MEDIATEK.md.
L'estrattore disassembla remove_waiter() prima di estrarre gli offset. I kernel con
la correzione vengono rifiutati con codice di uscita 6; solo i kernel vulnerabili continuano.
Un OTA completo può essere analizzato interamente sul telefono: boot più xbl_config
vengono estratti automaticamente. Passa a --work-dir una directory scrivibile dall'app quando
esegui all'interno della sandbox dell'app. Cross-compila e invia:
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
I nuovi kernel non richiedono più una ricompilazione dell'app: tocca Import offsets.conf (HOCON)
e scegli il .conf appiattito dell'estrattore, oppure usa Import offsets.json (v1)
per un vecchio report JSON. Il JSON v1 viene convertito nell'app, quindi non serve
inviare nulla al dispositivo: il codice nativo parte sempre dal documento GLK1 che l'app invia
su stdin e confronta l'attuale uname -r con il profilo risolto
prima di rifiutare il kernel. Le importazioni si fondono tra i file; una release già
memorizzata richiede conferma prima della sovrascrittura.
L'app può anche generare il profilo da sola — Parse OTA link (URL completo dello ZIP OTA)
e Parse image (boot.img + xbl_config.img opzionale) eseguono
l'estrattore in-process e scrivono un .conf appiattito nella directory dati dell'app in
caso di successo: