DLL-Injection

In der Informatik bezeichnet DLL-Injection eine Technik, mit der man Code im Adressraum eines anderen Prozesses zur Ausführung bringt, in dem 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 jeden 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.

#include <Windows.h>
#include <TlHelp32.h>
#include <iostream>
#include <memory>
#include <system_error>
#include <charconv>
#include <vector>

using namespace std;

using XHANDLE = unique_ptr<void, decltype([]( void *h ) { h && h != INVALID_HANDLE_VALUE && CloseHandle( (HANDLE)h ); })>;
using XHMODULE = unique_ptr<void, decltype([]( void *hm ) { hm && FreeLibrary( (HMODULE)hm ); })>;

MODULEENTRY32W getModule( char const *module );
[[noreturn]]
void throwSysErr( char const *str );
size_t maxReadableRange( void *pRegion );

int main( int argc, char **argv )
{
	try
	{
		if( argc < 4 )
			return EXIT_FAILURE;
		char const
			*processId = argv[1],
			*dllName = argv[2],
			*exportName = argv[3];
		DWORD dwProcessId = [&]() -> DWORD
			{
				DWORD dwRet;
				if( from_chars_result fcr = from_chars( processId, processId + strlen( processId ), dwRet ); fcr.ec != errc() || *fcr.ptr )
					throw system_error( (int)(!*fcr.ptr ? fcr.ec : errc::invalid_argument), generic_category(), "wrong process id");
				return dwRet;
			}();
		XHANDLE xhProcess( OpenProcess( PROCESS_ALL_ACCESS, FALSE, dwProcessId ) );
		if( !xhProcess.get() )
			throwSysErr( "can't open process unlimited" );
		XHMODULE xhmDll;
		unsigned mapRetries = 0;
		MODULEENTRY32W me;
		for( ; ; )
		{
			xhmDll.reset( LoadLibraryA( dllName ) );
			if( !xhmDll.get() )
				throwSysErr( "can't load library" );
			me = getModule( dllName );
			if( VirtualAllocEx( xhProcess.get(), me.modBaseAddr, me.modBaseSize, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE ) )
			{
				xhmDll.reset( nullptr );
				if( !VirtualAlloc( me.modBaseAddr, me.modBaseSize, MEM_RESERVE, PAGE_NOACCESS ) )
					throwSysErr( "can't reserve address range of previously mapped DLL" );
				++mapRetries;
				continue;
			}
			break;
		}
		LPTHREAD_START_ROUTINE procAddr = (LPTHREAD_START_ROUTINE)GetProcAddress( (HMODULE)xhmDll.get(), exportName );
		if( !procAddr )
			throwSysErr( "can't get procedure entry point" );
		size_t dllReadable = maxReadableRange( me.modBaseAddr );
		if( SIZE_T bytesCopied; !WriteProcessMemory( xhProcess.get(), me.modBaseAddr, me.modBaseAddr, dllReadable, &bytesCopied ) || bytesCopied != me.modBaseSize )
			throwSysErr( "can't copy DLL to remote process" );
		DWORD dwRemoteThreadId;
		XHANDLE xhRemoteThread( CreateRemoteThread( xhProcess.get(), nullptr, 0, procAddr, nullptr, 0, &dwRemoteThreadId ) );
		if( !xhRemoteThread.get() )
			throwSysErr( "failed to create remote thread" );
	}
	catch( system_error const &se )
	{
		cout << se.what() << endl;
		cout << "error code: " << (DWORD)se.code().value() << endl;
	}
}

MODULEENTRY32W getModule( char const *module )
{
	MODULEENTRY32W me;
	auto errRet = [&]() -> MODULEENTRY32W { me.dwSize = 0; return me; };
	wstring wModule;
	wModule.reserve( strlen( module ) );
	for( ; *module; wModule += (wchar_t)(unsigned char)*module++ );
	wstring moduleAbsolute( GetFullPathNameW( wModule.data(), 0, (LPWSTR)L"", nullptr ), L'\0' );
	if( moduleAbsolute.size()
		|| GetFullPathNameW( wModule.data(), moduleAbsolute.size(), (LPWSTR)moduleAbsolute.c_str(), nullptr ) + 1 != moduleAbsolute.size() )
		return errRet();
	XHANDLE xhToolHelp( CreateToolhelp32Snapshot( TH32CS_SNAPMODULE, GetCurrentProcessId() ) );
	if( xhToolHelp.get() == INVALID_HANDLE_VALUE )
		return errRet();
	me.dwSize = sizeof me;
	if( !Module32FirstW( xhToolHelp.get(), &me ) )
		return errRet();
	for( ; ; )
	{
		constexpr size_t PATH_LENGTH = 256;
		wchar_t modulePath[PATH_LENGTH];
		if( !GetModuleFileNameW( me.hModule, modulePath, PATH_LENGTH ) )
			return errRet();
		if( _wcsicmp( modulePath, moduleAbsolute.c_str() ) == 0 )
			return me;
		me.dwSize = sizeof me;
		if( !Module32NextW( xhToolHelp.get(), &me ) )
			return errRet();
	}
}

size_t maxReadableRange( void *pRegion )
{
	constexpr char const *VQ_ERR = "can't determine readable size of region";
	auto query = []( void *p ) -> MEMORY_BASIC_INFORMATION
	{
		MEMORY_BASIC_INFORMATION mbi;
		if( !VirtualQuery( p, &mbi, sizeof mbi) )
			throwSysErr( VQ_ERR );
		return mbi;
	};
	pRegion = query( pRegion ).AllocationBase;
	MEMORY_BASIC_INFORMATION mbi;
	constexpr DWORD MEMORY_TYPES = PAGE_EXECUTE_READ | PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_WRITECOPY | PAGE_READONLY | PAGE_READWRITE | PAGE_WRITECOPY;
	for( char *scn = (char *)pRegion; ; scn += mbi.RegionSize )
		if( (mbi = query( scn )).AllocationBase != pRegion || mbi.State != MEM_COMMIT && !(mbi.AllocationProtect & MEMORY_TYPES) )
			return scn - (char *)pRegion;
	return 0;

}

[[noreturn]]
void throwSysErr( char const *str )
{
	throw system_error( (int)GetLastError(), system_category(), str );
}

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 allokierte Speicher an derselben logischen Adresse allokiert werden. Obiger Code löst das so, dass wenn eine Speicherallokation an derselben Adresse im entfernten Prozess nicht möglich ist, die DLL entladen wird und der zuvor durch die DLL belegte Adressraum reserviert wird, dass beim nächsten Versuch, die 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.

Literatur

• Jeffrey Richter: Programming Applications for Microsoft Windows. 4th edition. Microsoft Press, Redmond WA 1999, ISBN 1-57231-996-8 (Microsoft Programming Series).