pirosap/aquos-r7-ghostlockExploit root du noyau Linux 5.10 spécifique à l'appareil Sharp AQUOS R7 (CVE-2026-43499), accordant un UID 0 temporaire avec SELinux permissif et un démon su.
Portage Linux 5.10 spécifique à l'appareil de GhostLock (CVE-2026-43499) pour le Sharp
AQUOS R7. La cible validée est l'AQUOS R7 (Mineva, SGA202SH/A202SH)
exécutant Android 14 build 03.00.11, noyau
5.10.237-android12-9-00013-gd09ef2e980e0-ab13968955 (SM8450).
La cible validée précédente, build 03.00.06 / noyau
5.10.218-android12-9-00041-g124993efd06e-ab12385094, est préservée dans
le tag git v1.0-030006.
Il s'agit d'un portage de aquos-r6-ghostlock
(AQUOS R6, noyau 5.4.61-qgki). Chaque constante — gestion de KASLR, la
fenêtre de fuite selinux_state, les offsets task/cred, la région de travail zero-BSS —
a été redérivée et validée contre le noyau du R7 ; la géométrie de pile du R6
n'a servi que de référence de départ.
Une exécution réussie vous donne l'UID 0 avec SELinux en mode permissif et démarre un petit
démon de commande su. Cela n'accorde pas un ensemble complet de capacités Linux et la
modification n'est pas persistante : un redémarrage restaure l'état du noyau d'origine.
Le clang du NDK Android ciblant aarch64-linux-android29 est requis (testé
avec le NDK r30) :
make build/ghostlock510 # ~3.4 MB static binary
make strip # optional; ~0.6 MB, same behaviour
Reproductibilité (calibration 03.00.11) : cette source, compilée avec la chaîne d'outils ci-dessus, est identique octet pour octet (MD5 25fc1d5d0e92d36c56f00f983a49667d) au binaire utilisé lors du test 03.00.11 sur l'appareil. L'asset de release est la forme llvm-strip-ée de exactement ce binaire (598 672 octets, SHA-256 5c413a80e9fcc41032412f4e0e5183bc723dde9a2e0ace5a6d9c79681b04b9cd). Pour la build 03.00.06, voir le tag v1.0-030006 (MD5 non strippé fa896ebd361519766b46cc2bab70dea2).
Poussez le binaire (asset de release ou votre propre build) et exécutez-le une fois :
adb push ghostlock510 /data/local/tmp/ghostlock510
adb shell chmod 755 /data/local/tmp/ghostlock510
adb shell "setsid nohup /data/local/tmp/ghostlock510 --use-setattr --stamp3 --perm-pc --cred-swap --install-su --stamp-off 0xf0 --log /data/local/tmp/ghostlock510.log </dev/null >/dev/null 2>&1 &"
Utilisez le client su installé pour les commandes root (chemin complet requis) :
adb shell "/data/local/tmp/su -c 'id; getenforce'"
# uid=0(root) gid=2000(shell) groups=2000(shell) context=u:r:kernel:s0
# Permissive
su communique avec le démon de l'exploit via TCP sur l'interface loopback (port 9999) ; aucun shell root persistant n'est attaché. Les commandes sont basées sur des lignes, et l'imbrication de su dans su ne fonctionne pas. Les programmes interactifs (vi, top, …) nécessitent un PTY ; un mode su interactif par-dessus le démon est laissé comme travail futur.
Mesuré sur cette build exacte (voir VERIFICATION.md) :
Donc : redémarrez, exécutez ghostlock510 une fois, et ne le relancez pas tant que cette session est active. Le redémarrage est la procédure de nettoyage.
Les entrées externes volumineuses ne sont délibérément pas incluses dans ce dépôt :
vmlinux/System.map de la build de noyau Android CI 13968955 ; l'identité octet par octet avec le noyau réellement exécuté sur l'appareil a été vérifiée via son image boot_b (les 23 segments PT_LOAD, comparaison segment par segment). Le correctif de la CVE (backport 5.10.y du 2026-07-21) est postérieur à cet arbre (HEAD 2025-08-20), et kernel/futex/core.c est identique au blob près à la build 03.00.06 — la vulnérabilité est toujours présente.v1.0-030006) : les offsets provenaient de la build de noyau Android CI 12385094, vérifiés octet par octet via l'image boot_a de l'appareil.--stamp3 / --use-setattr s'en est inspirée (aucune licence indiquée dans ce dépôt).