GhostLock-App

中文 : README_ZH.md

Documentation

• Guide de portage des profils de noyau - ajouter la prise en charge d'un nouveau noyau. GhostLock fait correspondre les noyaux par uname -r exact et rejette les builds non pris en charge, en affichant le statut en haut. Les profils intégrés se trouvent dans app/src/main/assets/kernel_profiles/ : un fichier HOCON par version, index.conf comme index d'exécution, et des modèles de famille de versions <major.minor>-template.conf.
• Appareils pris en charge - la liste des noyaux intégrés.
• Valeurs par défaut d'exécution partagées - chaque champ de réglage d'exécution, sa valeur par défaut et sa justification.
• Schéma de profil - structure complète du profil et flux de données.
• Ajouter un composant - guide du développeur pour un nouveau middleware natif / backend / frontend (chinois).

Pour le workflow complet de portage d'appareil, les liens vers les modèles de famille de noyaux et la justification des réglages, voir le Guide de portage des profils de noyau.

Les lignes explicitement marquées Shizuku requis s'exécutent via un UserService shell. Démarrez Shizuku avec ADB et appuyez sur la carte de statut pour accorder l'accès ; toutes les autres lignes utilisent le chemin d'exécution normal de l'application.

Démarrage rapide

Ouvrez GhostLock et appuyez sur Run. KernelSU (me.weishu.kernelsu), ReSukiSU (com.resukisu.resukisu) ou KowSU (com.kowx712.supermanager) fournit ksud pour le chargement des modules ; sans cela, W1/W2 accordent toujours l'uid 0 mais aucun module n'est chargé.

La chaîne d'exécution est un pipeline de trois composants : un frontend (démarrage/passation de relais root_child), un backend (la primitive futex CVE-2026-43499) et une route middleware. Les combinaisons cataloguées sont instanciées au moment de la compilation ; le profil résolu sélectionne celle qui s'exécute. La route fait la course sur deux cœurs : sur les noyaux tree-waiter 6.6/6.12, le thread principal martèle select tandis qu'un thread consommateur perturbe la priorité du waiter ; sur les noyaux compact-waiter 6.1, elle pilote getsockopt(TCP_ZEROCOPY_RECEIVE) à travers une page trouée ; les noyaux 5.15 utilisent le waiter multicast. La paire de CPU provient également du profil résolu.

Débogage en ligne de commande

adb/shell n'a pas de filtre seccomp, donc W3 est ignoré - pratique pour une vérification rapide :

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

Extraction des offsets

tools/extract_rs dérive les offsets à partir d'un boot.img (plus éventuellement xbl_config.img), d'un ZIP OTA complet, ou d'une URL http(s) pointant vers l'un d'eux. Les kallsyms proviennent de --kallsyms ou sont récupérés depuis la table intégrée de l'image. pselect_waiter_shift et off_slide_loggers_0_1 sont dérivés par le désassembleur arm64 intégré. Les images MediaTek n'ont pas de xbl_config.img et généralement pas de BTF : l'adresse de chargement physique est dérivée de _text dans kallsyms (à remplacer avec --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 est la sortie de l'extracteur : un profil aplati et autonome (aucune ligne include, les constantes partagées 6.x credential/KernelSnitch intégrées, la route sélectionnée à partir des preuves de --analysis sauf si --route la remplace). L'extracteur émet chaque champ que l'image fournit réellement et omet le reste ; il ne comble jamais les lacunes avec les suppositions d'une famille de noyaux voisine (6.6 de famille non vérifiée, le -2 par défaut, les constantes multicast 5.15, ou une valeur phys par défaut). Chaque sortie est un candidat non vérifié : importable et analysable, avec les champs manquants ou invalides bloqués par la validation pré-exécution de l'application, de sorte qu'une exécution réussie n'implique jamais la prise en charge de l'appareil. Sur 5.x, il dérive également la réparation de la référence credential depuis init_cred et la géométrie multicast depuis BTF (voir docs/analysis/extractor-5x-derivation-plan.md). --format json reste pour le chemin d'import v1. Pour ajouter un profil intégré, complétez et validez le modèle de famille de versions correspondant, enregistrez-le comme profil .conf autonome, et ajoutez-le à kernel_profiles/index.conf. L'ancien registre C offsets.h est obsolète et supprimé.

MediaTek

Les images MediaTek n'ont pas de xbl_config.img et généralement pas de BTF intégré, donc l'extracteur ne peut pas dériver les deux adresses physiques (kernel_phys_load, kernel_phys_offset) depuis l'image et les laisse à null. L'exécution retombe alors sur la formule SoC, qui échoue à W1 sur MediaTek. Remplissez les deux en exécutant l'extracteur séparé tools/mtk-phys/ sur un appareil rooté (il lit /proc/iomem) et en collant les valeurs dans les overrides avancés de l'application. Voir MEDIATEK.md.

Preflight

L'extracteur désassemble remove_waiter() avant d'extraire les offsets. Les noyaux avec le correctif sont rejetés avec le code de sortie 6 ; seuls les noyaux vulnérables continuent.

Analyse sur l'appareil

Un OTA complet peut être analysé entièrement sur le téléphone : boot plus xbl_config sont extraits automatiquement. Passez --work-dir un répertoire accessible en écriture par l'application lorsque vous exécutez dans le bac à sable de l'application. Compilation croisée et 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

Importer des offsets sans recompiler l'application

Les nouveaux noyaux ne nécessitent plus de recompiler l'application : appuyez sur Import offsets.conf (HOCON) et choisissez le .conf aplati de l'extracteur, ou utilisez Import offsets.json (v1) pour un ancien rapport JSON. Le JSON v1 est converti dans l'application, donc rien n'a besoin d'être poussé vers l'appareil : le natif démarre toujours à partir du document GLK1 que l'application envoie sur stdin, et fait correspondre le uname -r actuel au profil résolu avant de rejeter le noyau. Les imports fusionnent entre les fichiers ; une version déjà stockée demande confirmation avant écrasement.