DLL-Injection - Frage !

[mr_emre_d]

Ich gehe gerade so ein Tutorial durch und komm irgendwie nicht drauf warum
beim ersten WriteProcessMemory die InitData übergeben werden ?!?!

Hier der Code dazu:

Code:

function InjectDllToTarget(dllName : string; TargetProcessID : DWORD ; code : pointer; CodeSize : integer ): boolean;
 var
  InitDataAddr , WriteAddr : pointer;
  hProcess  , ThreadHandle : Thandle;
  BytesWritten , TheadID : DWORD;
  InitData : TInjectDllData;
begin
 result := false;

 // it would probably be a good idea to set these
 // from the IAT rather than assuming kernel32.dll
 // is loaded in the same place in the remote process
 InitData.pLoadLibrary      := GetProcAddress(LoadLibrary('kernel32.dll'), 'LoadLibraryA');
 InitData.pGetProcAddress   := GetProcAddress(LoadLibrary('kernel32.dll'), 'GetProcAddress');
 InitData.pGetModuleHandle  := GetProcAddress(LoadLibrary('kernel32.dll'), 'GetModuleHandleA');


 hProcess := OpenProcess( PROCESS_ALL_ACCESS, FALSE, TargetProcessID );
 if (hProcess = 0) then exit;

// write the initdata strucutre to the remote prcess
 InitDataAddr := VirtualAllocEx(hProcess , 0, sizeof(InitData)  , MEM_COMMIT , PAGE_READWRITE) ;
 if ( InitDataAddr <> nil) then
 begin
  WriteProcessMemory(hProcess , InitDataAddr , (@InitData) , sizeof(InitData) , BytesWritten );
 end ;

 // alocate and write the dll name to the remote process
 InitData.lib_name := VirtualAllocEx(hProcess , 0, length(dllName) + 5  , MEM_COMMIT , PAGE_READWRITE) ;
 if ( InitData.lib_name <> nil) then
 begin
    WriteProcessMemory(hProcess ,  InitData.lib_name , pchar(dllName) , length(dllName) , BytesWritten );
 end ;

// write our proc that loads the dll into the remote process
// then execute it
 WriteAddr := VirtualAllocEx(hProcess , 0, CodeSize , MEM_COMMIT , PAGE_READWRITE) ;
 if (WriteAddr <> nil) then
 begin
   WriteProcessMemory(hProcess , WriteAddr , code , CodeSize , BytesWritten );

   if BytesWritten = CodeSize then
   begin
      ThreadHandle := CreateRemoteThread( hProcess , nil , 0, WriteAddr , InitDataAddr ,0 , TheadID );

     WaitForSingleObject( ThreadHandle , INFINITE);  //wait for the thread to execute

      VirtualFreeEx( hProcess , WriteAddr ,   0 , MEM_RELEASE); // free the memory we allocated
      result := true;
   end;
 end;

 // free the memory we allocated for the dll name
 VirtualFreeEx( hProcess , InitDataAddr ,  0 , MEM_RELEASE);
 VirtualFreeEx( hProcess , InitData.lib_name ,  0 , MEM_RELEASE);
 CloseHandle(hProcess);
end;

PS: Hat irgendwer iwelche Tutorials Richtung DLL-Injection ?
PS2: Ich weiß nicht so recht zu welcher Sparte es gehört -- bitte nicht bösen sein wenn es hier falsch ist

MfG

[OldGrumpy]

Wenn mich nicht alles täuscht, produziert der Code aus dem Tutorial ein fieses Resourcenleck: Der Aufruf von GetProcAddress mit LoadLibrary() als erstem Argument (wodurch LoadLibrary aufgerufen wird, ein Handle belegt wird usw.) sorgt IMHO dafür dass immer neue Handles belegt werden, diese aber niemals wieder freigegeben werden. Das ist ein fieses Leck weil mans erst bemerkt wenns zu spät ist.

[mr_emre_d]

hmmm

Kennst du zufällig irgendwelche Tutorials Richtung DLL-Injection ?

Im Inet ist nichts außer undokummentierter Code zu finden

EDIT: Außer das von mir Gepostete (Author: Rezmond)!

[brechi]

Es wird nur der Referenz-Counter erhöht von daher ist es bei der kernel32.dll egal (da sie soweiso nicht entladen werden kann egal wie oft man FreeLibrary darauf aufruft). Schöner wär es allerdings doch nur einmal LoadLibrary aufzurufen und dann FreeLibrary am Schluss wieder. Das gilt inbesondere für Dlls die Extra geladen werden (wie z.B. opengl32.dll). Bei der user32 / ntdll / kernel32 ist es aber im Grunde egal (user32 wenn es ein Window-Programm ist)).

LoadLibrary liefert in dem Sinne kein Handle zurück, sondern nur die Speicheradresse der DLL und erhöht den Loadcounter, wenn der bei 0 (oder wars -1??) ist wird die Dll wieder entladen.

Zu deiner Frage: Wie sieht denn das TInjectDllData überhaupt aus?

Zu 99.9% wird TInjectDllData in das Zielprogramm geschrieben und dann per CreateRemoteThread ausgeführt. D.h. bei TInjectDllData handelt es sich um Assemblercode bei dem nur die Adressen vorher angepasst werden. Das ist für das Injeten aber ziemlich überflüssig! Es muss nur der String in das Zielprogramm gespeichert werden, dann kann CreateRemoteThread direkt auf LoadLibraryA /bzw. W) ausgeführt werden. Das funktioniert deshalb, weil ein Thread (genau wie LoadLibraryA) einen Parameter hat. Dieser Parameter (in dem Fall die Adresse des Strings) kann auch bei CRT angegeben werden. Man spart sich also das Schreiben des Assembler Codes in den ZielProzess.

InjectProgram:
Schreibe DLL-String in Zielprozess
Rufe CRT im Zielprozess auf, wobei Start = LoadLibraryA und Parameter = Adresse des Dll-Strings im Zielprozess
Warte bis Thread zu ende und gebe Speicher im Zielprozess wieder frei.

Dazu kannst du dir rauch mal meine Units anschauen da ist alles genauer erklärt. (uallCollection @ google bzw hier im Forum)

uallHook.InjectLibrary von
http://omorphia.cvs.sourceforge.net/...p&sortdir=down

PS: der Code ist super alt (2Jahre??) und mittlerweile eher schlecht, sieht man z.B. an der Version da net mal das Handle vom Thread wieder geschlossen wird (hab aber schon seit ewigkeiten nicht mehr die Zeit die Bugs alle zu fixen, aber is ja OpenSource )

[Neotracer64]

OffTopic:

Zitat von brechi:

Es wird nur der Referenz-Counter erhöht von daher ist es bei der kernel32.dll egal (da sie soweiso nicht entladen werden kann egal wie oft man FreeLibrary darauf aufruft).

Da halt ich gegen. *g*
Folgendes PoC unmapped kernel32.dll vom Prozess. *scnr*

[mr_emre_d]

Danke euch beiden

[Win32.API]

Zitat von Neotracer64:

OffTopic:

Zitat von brechi:

Es wird nur der Referenz-Counter erhöht von daher ist es bei der kernel32.dll egal (da sie soweiso nicht entladen werden kann egal wie oft man FreeLibrary darauf aufruft).

Da halt ich gegen. *g*
Folgendes PoC unmapped kernel32.dll vom Prozess. *scnr*

So ein Beispiel ist ohne Source nutzlos, zumal brechi nur von FreeLibrary sprach

[Neotracer64]

Zitat von Win32.API:

Zitat von Neotracer64:

OffTopic:

Zitat von brechi:

Es wird nur der Referenz-Counter erhöht von daher ist es bei der kernel32.dll egal (da sie soweiso nicht entladen werden kann egal wie oft man FreeLibrary darauf aufruft).

Da halt ich gegen. *g*
Folgendes PoC unmapped kernel32.dll vom Prozess. *scnr*

So ein Beispiel ist ohne Source nutzlos, zumal brechi nur von FreeLibrary sprach

Du siehst das falsch.
So ein Beispiel ist mit Source langeweilig.
Ich hab noch einige andere Sachen darin verwendet, und benutze teile davon für mein crackme.

Ausserdem war das einfach nur ein "just-for-fun" Offtopic geblubber von mir . Nichts wichtiges.