# DLL-Injection

In der Informatik bezeichnet DLL-Injection eine Technik, mit der man Code im Adressraum eines anderen Prozesses zur Ausführung bringt, indem man diesen Prozess zwingt, eine programmfremde Dynamic Link Library (DLL) zu laden. Im Prinzip ist diese Technik bei allen Betriebssystemen verfügbar, die dynamische Bibliotheken unterstützen, der Begriff DLL-Injection bezieht sich jedoch gewöhnlich auf das Betriebssystem Microsoft Windows.
Diese Technik wird nur benötigt, wenn der Quellcode eines Programms, dessen Verhalten man beeinflussen möchte, nicht verfügbar ist. Somit wird DLL-Injection häufig von sogenannten Third-Party Anbietern genutzt, um das Verhalten eines Programms in einer Weise anzupassen, die vom Entwickler des ursprünglichen Programms nicht vorgesehen wurde. Ein typisches Beispiel für eine die Technik der DLL-Injection nutzende Anwendung ist ein Profiler.

## Verfügbare Techniken unter Windows

Unter Microsoft Windows gibt es verschiedene Techniken, eine DLL-Injection zu bewerkstelligen. Die wichtigsten sind dabei folgende:
* Windows-Registry: In der Registrierung (registry) können unter dem key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs" DLLs angegeben werden, die global bei dem Start jedes Programms zusätzlich geladen werden.
* Hooks: Durch die Nutzung von Windows-Hooks ist es möglich, eigene DLLs an fremde Prozesse (sowohl selektiv, als auch global) anzuhängen. Zusätzlich lassen sich mithilfe dieser Technik gleich bestimmte Programmaktionen abfangen/verhindern (siehe Windows-Hooks).
* CreateRemoteThread: Die CreateRemoteThread API ermöglicht es, einen Thread von einer beliebigen Speicheradresse mit der Übergabe eines Arguments zu starten. Dadurch ist es möglich, bei Aufruf der Speicheradresse, in welcher die LoadLibrary API eines Prozesses liegt, mit dem Argument des zu ladenden DLL-Namens diese DLL in einen fremden Prozess zu laden.
* Direkter Speicherzugriff: Mithilfe der Windows-Funktionen AllocMemory und WriteMemory ist es möglich, direkt auf den Speicher fremder Prozesse zuzugreifen. So lässt sich neuer Speicher (AllocMemory) anfordern und in diesen eine eigene Funktion zum Nachladen der eigenen DLL schreiben.
* Durch Nutzung von Betriebssystemfunktionen (APIs) zur Manipulation von Prozessen (process manipulations functions) kann das Nachladen einer zusätzlichen DLL erreicht werden.

## Nutzung durch bösartige Software

Die Nutzung von DLL-Injection ist für bösartige Software sehr attraktiv. Diese Technik ermöglicht es, Code unter dem Deckmantel eines anderen Programms auszuführen. Dies ist deshalb interessant, da dadurch Zugriffe auf das Internet vor einer Desktop-Firewall verschleiert werden können. Hierüber können beispielsweise auf dem infizierten Computer ausgespähte Passwörter unbemerkt versendet werden. Um diesem Problem zu begegnen, versuchen einige Desktop-Firewalls, durch eine Analyse des Systems eine DLL-Injection zu erkennen, was ihnen jedoch nicht immer gelingt.

## Gegenmaßnahmen

* Auf geschützte Prozesse (protected process, mit Windows Vista für den Protected Media Path eingeführt) kann nicht zugegriffen werden, sofern der schreibende Prozess nicht auch ein geschützter Prozess ist

## Injizieren einer beliebigen DLL

Der folgende Code zeigt den minimalen Weg, eine beliebige DLL in einen entfernten Prozess zu injizieren und auf einem Einstiegspunkt dieser DLL einen eigenen Thread zu starten.
Das wesentliche Problem beim Injizieren einer beliebigen DLL in einen entfernten Prozess ist, dass man mit LoadLibary nur DLLs in den eigenen, aber nicht in entfernte Prozesse laden kann, d. h. man muss die DLL in den eigenen Prozess laden und in den entfernten in entsprechend ausführbaren Speicher kopieren. Ein Folgeproblem daraus ist, dass jeglicher ausführbarer Code, der vom Kernel in den Adressraum eines Prozesses gemappt wird, mittels Relokation auf diese Ladeadresse angepasst wird, d. h. wenn man die DLL in einen entfernten Prozess kopieren will, dann muss der im entfernten Prozess allozierte Speicher an derselben logischen Adresse alloziert werden. Obiger Code löst das so, dass, falls eine Speicherallokation an derselben Adresse im entfernten Prozess nicht möglich ist, die DLL entladen und der zuvor durch die DLL belegte Adressraum reserviert wird, so dass beim nächsten Versuch, diese DLL zu laden, LoadLibary diese nicht wieder an dieselbe Adresse lädt.
Des Weiteren belegt die geladene DLL in der Regel mehr Adressraum als tatsächlich physisch Pages des Executables gemappt sind, d. h. man kann nicht so ohne weiteres dem oben in der Funktion getModule zurückgegebenen Parameter über den durch die DLL belegten Speicher trauen. Daher gibt es zusätzlich die Funktion maxReadableRange, die die Läge der tatsächlich aus dem Executable gemappten Pages mit VirtualQuery ermittelt. Würde man sich auf den Parameter von getModule verlassen, dann würde das Kopieren der DLL in den entfernten Prozess gegebenenfalls fehlschlagen, weil der belegte Adressraum länger sein kann als die Läge der tatsächlich aus dem Executable gemappten Pages.