GhostLock-Galaxy

中文: README_ZH.md

Questo è un repository separato perché questa route richiede il permesso shell di Android, ottenuto tramite adb shell o Shizuku. L'originale YuKongA/ghostlock-app non utilizza il permesso shell e segue una route di esecuzione diversa; i suoi requisiti e il suo percorso di codice non devono essere considerati intercambiabili con questo progetto.

Dispositivo supportato

All'avvio il kernel viene confrontato con la tabella degli offset tramite uname -r; i kernel non supportati vengono rifiutati immediatamente.

Avvio rapido

Per il percorso APK, avvia Shizuku tramite il debug wireless, concedi il permesso a GhostLock e tocca Run. Shizuku avvia il payload come utente shell di Android; l'APK stesso non è il contesto di esecuzione dell'exploit.

Debug da riga di comando

Il percorso diretto da riga di comando esegue lo stesso payload shell verificato senza richiedere Shizuku:

make ghostlock helper
adb push ghostlock /data/local/tmp/ghostlock
adb push ghostlock-helper /data/local/tmp/ghostlock-helper
adb push app/src/main/assets/ksud-zfold6-F9560ZCS4DZG3-samsung-main-no-patch-text-kdp /data/local/tmp/ksud-zfold6-F9560ZCS4DZG3-samsung-main-no-patch-text-kdp
adb shell chmod 755 /data/local/tmp/ghostlock
adb shell chmod 755 /data/local/tmp/ghostlock-helper
adb shell chmod 755 /data/local/tmp/ksud-zfold6-F9560ZCS4DZG3-samsung-main-no-patch-text-kdp
adb shell /data/local/tmp/ghostlock

L'helper è richiesto dalle fasi di root UMH e di late-load di KernelSU.

Note di build per KernelSU 6.1

Su alcuni kernel Samsung/Exynos 6.1, un modulo KernelSU generico può causare un panic EL2 durante ksud late-load perché il modulo tenta il patching live del testo. Per i target interessati, compila un modulo per la release firmware esatta e abilita l'opzione no-patch-text dell'albero del target:

CONFIG_KSU_SAMSUNG_NO_PATCH_TEXT=y

Abbina il kernelsu.ko e il ksud specifici per il target, e fai corrispondere il uname -r completo del dispositivo invece del solo KMI 6.1. Un riavvio durante il late-load può derivare dall'inizializzazione del modulo, non necessariamente dal loader ksud. Questa è una precauzione specifica per Samsung/Exynos; l'attuale target SM-F9560 è Snapdragon e deve essere validato separatamente. Vedi Root-My-Galaxy-Payloads per esempi di build specifici per target.

Estrazione degli offset

Sui dispositivi Qualcomm, tools/extract_target.py analizza gli offset da boot.img e xbl_config.img. Richiede Python 3 e una sorgente kallsyms (file --kallsyms o --kallsyms-finder). Passando --llvm-objdump (o avendo llvm-objdump nel PATH/NDK) disassembla inoltre il kernel per derivare automaticamente pselect_waiter_shift e off_slide_loggers_0_1:

python tools/extract_target.py `
  boot.img `
  --xbl-config xbl_config.img `
  --format c `
  --out offsets.h

Fattibilità della route pselect

core_sys_select copia solo 3 x FDS_BYTES(nfds) di dati fd_set utente sullo stack del kernel (qword 0..14 per nfds=320). Il futex waiter deve ricadere all'interno di quella zona controllabile: parola di inizio del waiter + 11 (campo lock) <= 14, cioè lo shift derivato (offset del waiter dal fd_set in qword) deve essere <= 3, altrimenti task/lock finiscono nella coda azzerata dal kernel e la route non può funzionare. Lo script fallisce con un errore chiaro quando il layout non è fattibile.

Ulteriori dettagli e contributi

Maggiori dettagli sulla ricerca del payload e sugli artefatti di supporto sono disponibili in Root-My-Galaxy-Payloads. Le pull request sono benvenute.

Crediti e licenza

Basato sui seguenti progetti, con licenza Apache License 2.0 (vedi LICENSE):

• NebuSec/CyberMeowfia
• JoinChang/ghostlock-oneplus
• x-spy/CVE-2026-43499-popsicle
• YuKongA/ghostlock-app
• BuSung-dev/Root-My-Galaxy