Un modo migliore per importare le API Win32 dallo shellcode iniettato

Question

Un modo migliore per importare le API Win32 dallo shellcode iniettato

#1 da (3 voti)

9

Inserisco il codice x86 nativo in un'applicazione .NET, tramite una callback TLS nell'immagine binaria. Sfortunatamente, gli eseguibili .NET importano solo mscorlib.dll all'interno del PE e hanno kernel32.dll mappato automaticamente nello spazio di memoria in fase di runtime. Non voglio iniettare nessuna importazione. Questo rende trovare gli indirizzi di LoadLibrary e GetProcAddress awkward.

Il mio primo pensiero per una soluzione è stato trovare il PEB tramite mov eax, dword ptr [fs:030h] , quindi caricare PEB->Ldr e PEB->Ldr.InMemoryOrderModuleList.Flink da lì e usarli per trovare il modulo in memoria. Da lì ho potuto prendere l'indirizzo di base di kernel32.dll in memoria e spostato sull'intestazione PE e sulla directory di esportazione RVA. Da lì ho potuto scorrere le voci di importazione per l'esportazione per nome e trovare l'indirizzo.

Questo ha i seguenti problemi:

Un sacco di codice per qualcosa di banale come una chiamata API.
La stringa ASCII che rappresenta il nome dell'API dovrebbe essere incorporata nel codice.
Memorizzare nella cache gli indirizzi trovati su un lungo runtime / thread multipli è scomodo.

C'è un modo più pulito per fare ciò che risolve questi problemi, senza ricorrere all'iniezione di importazione? Tieni presente che non riesco a modificare l'EP dell'immagine, perché il CLR si basa sul fatto che l'EP è un salto verso l'IL gestito.

windows assembly x86 injection shellcode

posta Polynomial 27.11.2012 - 10:52

fonte

1 risposta

Leggi altre domande sui tag windows assembly x86 injection shellcode

Test di penetrazione per le app di Windows Phone 8 senza fonte Verifica visiva delle impronte digitali

score 3 · Accepted Answer

Esiste un buon modo per risolvere i problemi (2) e (3) nel processo di associazione manuale descritto, ma sono riluttante a pubblicare un buon ed elaborato tutorial pubblico sulla progettazione dello shellcode qui su StackExchange. ^ _ ^ Quindi, c'è un suggerimento per voi di usare crcs per (2) e le chiamate indirette per (3) - sembri abbastanza familiare con il processo di bind manuale per dedurre il modo esatto di applicare questi due concetti.

Per quanto riguarda (1), non si tratta di un problema ma di un'assunzione errata: vincolare le esportazioni alle importazioni e fornire una capacità del programmatore di chiamare l'API di sistema è non banale con qualsiasi mezzo. La domanda è solo chi farà tutto il lavoro sporco. Non appena decidi di rifiutare il servizio di linker di Windows per fare affidamento sui nomi di testo in chiaro, sei il solo a implementare i dettagli sporchi a modo tuo.

L'importazione di iniezione sembra essere il modo più pulito mentre modifichi comunque il file binario, ma aggiunge nomi di API in chiaro, quindi suppongo che questo non sia il tuo corrispettivo.