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
PageTableInjection — Injection de code, injecter un payload malveillant via les tables de pages pml4. | Kitploit
Outils/GitHubGitHub/kkent030315/pagetableinjection
Criminalistique MémoireExploitationExploitation de Binaires
GitHubkkent030315/pagetableinjection

PageTableInjection

Injection de code, injecter un payload malveillant via les tables de pages pml4.

Voir le dépôtSite web
24460il y a 5 ansVérifié par Kitploit

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

PageTableInjection

Injection de code, injecter une charge utile malveillante via les tables de pages PML4.

Introduction

Ceci n'est qu'une preuve de concept de la technique d'injection par table de pages pour injecter du code malveillant dans des processus utilisateur arbitraires.
Sous Windows (et certains systèmes d'exploitation modernes), chaque processus possède sa propre PML4, également appelée Directory Table Base. Ainsi, le processus A ne peut pas accéder au processus B sans utiliser d'API. Mais que se passerait-il si nous pouvions injecter une entrée PML4 arbitraire ? Bien sûr, l'entrée PML4 pointera vers l'adresse physique correspondante des entrées, PDP, PD et PT, exactement comme dans le processus de support.

Afin d'injecter une entrée PML4 malveillante dans le processus cible, nous avons besoin d'une véritable page résidente (mémoire physique) qui soutient l'entrée PML4 malveillante. Ainsi, littéralement, la page résidente doit être résidente, sinon le système plantera ou deviendrait instable, car pendant la traduction MMU vers l'adresse physique, il n'y a rien que la MMU attend, et le gestionnaire de mémoire Windows n'attend rien non plus.

Regardons les tampons du processus de support et du processus cible. Dans ce cas, les tampons sont :

  • VA du processus de support : 0x1A45F810000
  • VA injectée dans le processus de déploiement : 0x6EA45F810000

Avant de passer à l'étape suivante, certains d'entre vous pourraient penser que la deuxième adresse (0x6EA45F810000) semble étrange, comme si nous allouions habituellement un tampon via malloc ou VirtualAlloc, l'adresse virtuelle devrait ressembler à 0x17C7CAC0000, 0x23BE9D80000, 0x19FE76F0000 ou quelque chose du genre. C'est parce que l'entrée PML4 malveillante n'est pas impliquée dans le gestionnaire de mémoire de Windows, et n'est pas non plus gérée. Bien sûr, toute adresse virtuelle sur un processus Windows 64 bits pourrait potentiellement avoir n'importe quelle valeur dans la plage de mémoire utilisateur.

Alors, si nous examinons les deux adresses...

root@kitploit:~
0: kd> .process ffff9803d8037080
Implicit process is now ffff9803`d8037080
0: kd> db 0x6EA45F810000 l2
00006ea4`5f810000  4d 5a       MZ

0: kd> !vtop 7968b000 0x6EA45F810000
Amd64VtoP: Virt 00006ea45f810000, pagedir 000000007968b000
Amd64VtoP: PML4E 000000007968b6e8
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 6ea45f810000 translates to physical address 14306000.
root@kitploit:~
0: kd> .process ffff9803d9f6b080
Implicit process is now ffff9803`d9f6b080
0: kd> db 0x1A45F810000 l2
000001a4`5f810000  4d 5a       MZ

0: kd> !vtop 564f6000 0x1A45F810000
Amd64VtoP: Virt 000001a45f810000, pagedir 00000000564f6000
Amd64VtoP: PML4E 00000000564f6018
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 1a45f810000 translates to physical address 14306000.

Les deux adresses correspondent exactement aux mêmes entrées de table de pages, PDP, PD, PT et une adresse physique. Par conséquent, si nous modifions le tampon du processus de support, la modification sera également visible dans le processus cible. Cela ressemble beaucoup à la mémoire partagée sous Windows, mais la différence est que la région mémoire du processus cible n'apparaîtra jamais dans les entrées VAD de son processus. D'un autre côté, si le tampon du processus de support est libéré, cela affecte également le processus cible, mais sans nettoyer les entrées de table de pages du processus cible, ce qui signifie que le gestionnaire de mémoire provoquera un bugcheck MEMORY_MANAGEMENT, ou déclenchera une triple faute encore plus grave sur le CPU.

Le problème

Cette technique présente d'énormes problèmes de stabilité, comme je l'ai dit, l'entrée PML4 malveillante injectée n'est impliquée ni dans le gestionnaire de mémoire de Windows ni dans le noyau. Et il n'y a aucune garantie que le processus de support reste actif jusqu'à ce que le processus cible soit terminé, ou que le processus cible ait quoi que ce soit à faire pour nettoyer l'entrée PML4 malveillante lorsque le processus de support se termine.

Licence

MIT copyright Kento Oki <[email protected]>

Le code source peut contenir du contenu externe ; ces contenus appartiennent à leurs détenteurs respectifs.

Télécharger l’outil