Injection de DLL avec CreateRemoteThread

Si vous jetez un oeil à la suite de code de travail d'une simple injection de DLL:

  //Open the target process with read , write and execute priviledges
   Process = OpenProcess(PROCESS_CREATE_THREAD|PROCESS_QUERY_INFORMATION|PROCESS_VM_READ|PROCESS_VM_WRITE|PROCESS_VM_OPERATION, FALSE, ID); 

   //Get the address of LoadLibraryA
   LoadLibrary = (LPVOID)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA"); 

   //Allocate space in the process for our DLL 
   Memory = (LPVOID)VirtualAllocEx(Process, NULL, strlen(dll)+1, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); 

   //Write the string name of our DLL in the memory allocated 
   WriteProcessMemory(Process, (LPVOID)Memory, dll, strlen(dll)+1, NULL); 

   //Load our DLL 
   CreateRemoteThread(Process, NULL, NULL, (LPTHREAD_START_ROUTINE)LoadLibrary, (LPVOID)Memory, NULL, NULL); 

   //Let the program regain control of itself
   CloseHandle(Process);

La chose qui me confond, c'est que GetProcAddress renvoie la LoadLibraryA fucntion adresse de le processus actuel, comment pouvez-vous passer en tant que paramètre à CreateRemoteThread et attendre le processus cible pour le faire fonctionner?

Parce que CreateRemoteThread prend LoadLibrary en tant que paramètre et l'appelle. Depuis il prend également Memory comme un paramètre, le paramètre passe à LoadLibrary.
Qui ne peuvent toujours pas expliquer pourquoi vous avez besoin de la LoadLibrary fonction de l'adresse de le processus actuel. Le Memory est l'adresse pour le nom de la dll, Pourquoi ne pas simplement passer LoadLibrary comme un string tout simplement si vous voulez l'appeler?
Parce que le décalage est exactement la même dans les autres processus. Si l'autre est x32 et de votre processus x32, le décalage de kernel32 est le même. Si votre processus est de 64 bits et l'autre processus est de 64 bits, le décalage est encore la même chose. Si l'autre est x32 et le vôtre est de 64 bits ou vice-versa, le décalage sera différente et l'injection sera un échec. Je crois User32.dll est toujours aussi chargé en même décalage. Semblable à Kernel32.dll

OriginalL'auteur James King | 2014-03-30

c++dll dll-injection visual-c++visual-studio

16

Il fonctionne par accident. C'est un très accident commun, Microsoft a fait beaucoup d'efforts pour s'assurer que la Dll du système d'exploitation, comme kernel32.dll ont une adresse de base qui n'entre pas en conflit avec une autre Dll. En outre, renforcée par kernel32.dll prise en charge très tôt à l'initialisation du processus, de sorte que de faibles probabilités qu'il a du se battre pour obtenir son adresse de base préférée.

Vous allez sortir avec facilement. Il est notable que ce a va mal dans le passé, il y avait un XP mise à jour de sécurité oops qui a causé gdi32.dll pour obtenir déménagé et fait beaucoup de machines tombent plus au démarrage. La manière correcte est assez douloureux, CreateToolhelp32Snapshot() + Module32First/Next() pour trouver la relocalisation de décalage n'est pas d'une grande joie. Franchement, vous avez probablement devrait pas le faire du tout si le système d'exploitation est "bizarre", comme ça.

attendez... il fonctionne parce que LoadLibrary satisfait LPTHREAD_START_ROUTINE signature et se trouve être à la même adresse à tous les processus? donc DllMain est appelée à l'intérieur de l'autre espace de processus... j'ai pu l'essayer.

OriginalL'auteur Hans Passant
2

LoadLibraryA vit dans kernel32.dll, un module qui est toujours chargé dans chaque processus et se trouve également être chargé à la même adresse à tous les processus.

LoadLibraryA ... happens to also be loaded at the same address in every process Existe-il des documents ou des références sur cette phrase?
Probablement, mais je n'ai pas de référence à portée de main. Depuis ntdll.dll et kernel32.dll sont tous deux chargés automatiquement par Windows comme les deux premiers modules en outre la principale exe, il n'y a pas de possibilité pour la meilleure adresse de chargement pour ces deux modules à être occupé par autre chose.
Quelques références: blogs.msdn.com/b/calvin_hsia/archive/2007/07/27/... et nynaeve.net/?p=198 Mais il serait mieux de trouver de la doc à partir de MSDN officiel non pas seulement de certains blogs.
C'est le mal raison. ASLR ferai pas être chargés à leur adresse. Mais l'ASLR seules les modifications de l'adresse de chargement une fois par session.
Je corrige la position des mains. Merci de me rappeler au sujet de l'ASLR. Comme vous l'indiquez, l'effet reste le même, cependant.

OriginalL'auteur 500 - Internal Server Error
1

Address Space Layout Randomisation (ASLR) est un anti-possibilité d'atténuation de la fonctionnalité gérée par Windows, et il permet d'adresse de réinstallation afin d'empêcher les attaquants de déterminer l'adresse de l'exploitation de quelque chose dans la mémoire (arrête de coder en dur des adresses/offsets). Cependant, les modules Windows seulement, un changement d'adresse par session.

Si vous avez un processus qui utilise l'kernel32.dll (pas tous les procédés d'utilisation kernel32.dll et je vais vous expliquer cela plus en quelques minutes), l'adresse à une routine pourrait être 55AA1122 comme un exemple (c'est un invalide exemple d'adresse). Maintenant, le prochain processus avec kernel32.dll, auront la même adresse pour 55AA1122 pour la même routine que la précédente.... Seulement si les processus sont tous les deux de la même architecture.

Les processus 32 bits auront les mêmes adresses pour kernel32.dll les exportations, entre autres Windows module exportations (par exemple NTDLL, USER32, etc.). 64-bit processus ont des adresses différentes pour le processus 32 bits, cependant les processus 64 bits va tous avoir les mêmes adresses pour les modules Windows, trop!

Distance de création de thread n'était pas un "accident", Microsoft intentionnellement mis en œuvre. Pourquoi? Microsoft utiliser beaucoup au cours de Windows eux-mêmes, aussi pour les Appels de Procédure Asynchrone. Microsoft a également chaud patch choses souvent pour leurs propres routines comme un anti-inversion de truc, ou si ils perdent le code source de leurs propres projets, haha.

Maintenant en ce qui concerne kernel32.dll d'être chargés dans un processus, il est chargé dans les processus qui utilisent l'API Win32. Cela comprend 99% des programmes dans le monde, cependant, il est possible de compiler un processus natif qui ne l'utilisez pas. Ce sera toutefois vous forcer à utiliser les API Natives et non de l'API Win32 complètement, et d'un processus de Windows appelé smss.exe fait exactement cela. Vous pouvez aussi compiler Dll Natives qui n'ont même pas normal Win32 API d'Entrée de la DLL de routine.

Pour faire court, les adresses pour Windows module routines de changer une fois par amorçage. Il va maintenir le même jusqu'au redémarrage suivant, et ainsi de suite. Les processus 32 bits ont leurs propres partagé adresses de Windows modules pour chaque processus, de même que processus 64 bits. Par conséquent, vous ne pouvez pas utiliser LoadLibraryA adresse d'un processus 64 bits tout en ciblant d'injection de DLL pour un processus 32 bits, sauf si vous utilisez la version 32 bits Kernel32.dll LoadLibraryA adresse. Une meilleure idée serait d'utiliser LdrLoadDll de toute façon, ou tout simplement shell-injection de code d'une réflexion chargeur de DLL stub.

OriginalL'auteur PspSetProcessPpmPolicy
0

Si vous lancez Visual Studio, créez un projet vide, ajouter de nouveaux main.cpp fichier, écrire:
```
#include <windows.h>
void main()
{
}
```
Et puis compiler ce programme, ne pas s'attendre à ce que l'exécutable ne fait rien, il ne le fait pas.

Peut-être que le compilateur Visual C++ ne pas écrire n'importe quelle commande dans le fichier d'objet, car il n'y a pas de commande dans le code source, mais l'éditeur de liens n'écrivez-le dans le début de la procédure principale de l'exécutable LoadLibrary appels à user32.dll, kernel32.dll, gdi32.dll et etc.

De sorte que chaque application est écrite en Visual Studio C++, au départ, de nombreux et les mêmes appels à LoadLibrary dans le même ordre, peu importe ce qui était le code source de ce fichier exécutable.

Le code source détermine uniquement les commandes qui doivent venir après le LoadLibrary appels.

De sorte que chaque Visual Studio C++ de l'application des charges LoadLibrary de kernel32.dll dans le début de l'exécution et donc LoadLibrary a le même point d'entrée ou à l'adresse de tous les processus relatifs à l'adressage du processus.

Théoriquement, vous pouvez faire de l'injecteur, le programme malveillant qui tente d'injecter votre programme, échouer si vous relier certains kernel32.lib qui ne charge pas kernel32.dll's LoadLibrary procédure dans la mémoire de votre programme.

L'injecteur ne peut pas la cause de votre programme de manière dynamique lors de l'exécution des charges de certaines dll si votre programme ne peut pas dynamiquement lors de l'exécution de charger la dll, parce que la procédure qui suppose pour ce faire, LoadLibrary, n'est pas présent dans la mémoire du processus.

Donc la distance thread créé par l'injecteur ne peut pas exécuter LoadLibrary qui n'existe pas dans la mémoire de la victime.

Mais c'est possible que l'attaquant ne VirtualAllocEx de créer un peu de bloc dans la mémoire de la victime, WriteProcessMemory un certain code exécutable, puis CreateRemoteThread pour l'exécuter.

OriginalL'auteur user9820482

Vous devez vous connecter pour publier un commentaire.