
Exploit 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)
sous Android 14 build 03.00.06, noyau
5.10.218-android12-9-00041-g124993efd06e-ab12385094 (SM8450).
Il s'agit d'un portage de aquos-r6-ghostlock
(AQUOS R6, noyau 5.4.61-qgki). Chaque constante — gestion du 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 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é : ce source, compilé avec la chaîne d'outils ci-dessus, est identique
au niveau octet (MD5 fa896ebd361519766b46cc2bab70dea2) au binaire utilisé dans tous les
tests sur appareil. L'asset de release est la forme llvm-strip-ée de exactement ce binaire
(598 672 octets, SHA-256 d3056b65380da9fda68bc1891a08c6028ee1cbdb39ff2c3ca136b703f1b0bef7).
Poussez le binaire (asset de release ou votre propre compilation) 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 loopback (port 9999) ; aucun
shell root persistant n'est attaché. Les commandes sont basées sur des lignes, et imbriquer su
dans su ne fonctionne pas. Les programmes interactifs (vi, top, …) veulent un PTY ; un
mode su interactif au-dessus du 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 voie de nettoyage.
Les grandes entrées externes ne sont délibérément pas incluses dans ce dépôt :
vmlinux/System.map de la
build de noyau Android CI 12385094 ; l'identité au niveau octet avec le noyau
réellement en cours d'exécution sur l'appareil a été vérifiée via son image boot_a.--stamp3 / --use-setattr
s'en est inspirée (aucune licence indiquée dans ce dépôt).