Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
PageTableInjection — Iniezione di codice, inietta payload malevolo tramite pagetables pml4. | Kitploit
Strumenti/GitHubGitHub/kkent030315/pagetableinjection
Memory ForensicsExploitBinary Exploitation
GitHubkkent030315/pagetableinjection

PageTableInjection

Iniezione di codice, inietta payload malevolo tramite pagetables pml4.

Vedi RepositorySito web
244605 anni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

PageTableInjection

Iniezione di codice, iniettare payload malicioso attraverso le pagetable pml4.

Introduzione

Questa è solo una prova di concetto della tecnica di iniezione delle page table per iniettare codice malicioso in processi utente arbitrari.
Su Windows (e su alcuni sistemi operativi moderni), ogni processo ha il suo PML4, noto anche come Directory Table Base. Quindi il processo A non può accedere al processo B senza API. Ma cosa succederebbe se potessimo iniettare un entry PML4 arbitrario? Ovviamente l'entry PML4 punterà all'indirizzo fisico corrispondente delle entry, PDP, PD e PT, esattamente come nel processo di supporto.

Per iniettare un entry PML4 malicioso nel processo di destinazione, abbiamo bisogno di avere una pagina effettiva residente (memoria fisica) che sostenga l'entry PML4 malicioso. Quindi letteralmente la pagina residente deve essere residente, altrimenti il sistema si bloccherà o diventerebbe instabile, perché durante la traduzione MMU all'indirizzo fisico, non c'è nulla che MMU si aspetta, così come non c'è nulla che il memory manager di Windows si aspetta.

Diamo un'occhiata ai buffer sia del processo di supporto che del processo di destinazione. In questo caso, i buffer sono:

  • Processo di supporto VA: 0x1A45F810000
  • Processo di destinazione (iniettato) VA: 0x6EA45F810000

Prima di procedere, alcuni di voi potrebbero pensare che il secondo indirizzo (0x6EA45F810000) sembri strano, perché di solito allocavamo un buffer tramite malloc o VirtualAlloc, e l'indirizzo virtuale dovrebbe assomigliare a 0x17C7CAC0000 0x23BE9D80000 0x19FE76F0000 o simili. Questo perché l'entry PML4 malicioso non è coinvolto nel memory manager di Windows e non è gestito nemmeno. Ovviamente ogni indirizzo virtuale su un processo Windows a 64 bit potrebbe potenzialmente avere qualsiasi valore all'interno dell'intervallo di memoria utente.

Quindi, se osserviamo entrambi gli indirizzi...

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.

Entrambi gli indirizzi corrispondono alle stesse identiche voci di page table, PDP, PD, PT e un indirizzo fisico. Pertanto, se modifichiamo il buffer del processo di supporto, la modifica si riflette anche sul processo di destinazione. Questo è molto simile alla memoria condivisa su Windows, ma la differenza è che la regione di memoria nel processo di destinazione non sarà mai visualizzata in nessuna voce VAD del suo processo. D'altro canto, se il buffer del processo di supporto viene liberato, ciò vale anche per il processo di destinazione, ma senza pulire le voci di page table del processo di destinazione, il che significa che il memory manager causerà un bugcheck MEMORY_MANAGEMENT, o peggio, innescherà un triplo fault sulla CPU.

Il problema

Questa tecnica presenta enormi problemi di stabilità, come ho detto, l'entry PML4 malicioso iniettato non è coinvolto nel memory manager di Windows né nel kernel. E non c'è garanzia che il processo di supporto rimanga vivo fino alla terminazione del processo di destinazione, o che il processo di destinazione abbia modo di pulire l'entry PML4 malicioso quando il processo di supporto termina.

Licenza

MIT Copyright Kento Oki <[email protected]>

I codici sorgente possono contenere contenuti esterni; tali contenuti appartengono ai rispettivi detentori del copyright.

Scarica lo strumento