Suche: Tutorial zu Dll Injection

[Lesco]

ich suche nen tutorial zu dll injection für delphi
hab bis jetzt nur das gefunden:
http://www.codeproject.com/threads/winspy.asp
und das is für c++ und davon hab ich keine ahnung
ich will keine fertige unit die hab ich selber schon gefunden

[perle]

Tutorials dafür hab ich leider keins parat, aber vielleicht hilft dir ein Projekt dafür weiter?

http://iamaphex.net/downloads/DllInjection.zip

Willst du genau wissen wie es funktioniert oder willst du es "nur" anwenden? Ist zweiteres der Fall kann ich dir die MadCollection empfehlen.

[Lesco]

ich verstehe lieber die funktionsweise von etwas bevor ich es benutze

[c113plpbr]

Zitat:

Zitat von Lesco

ich verstehe lieber die funktionsweise von etwas bevor ich es benutze

In dem von Perle verlinkten Projekt ist ein ellenlanger comment drinne (auf englisch) und dazu vielleicht 10 zeilen code ... schaus dir doch einfach mal an ...

ciao, Philipp

[opfer.der.genauigkeit]

Zitat:

Zitat von c113plpbr

In dem von Perle verlinkten Projekt ist ein ellenlanger comment drinne (auf englisch) und dazu vielleicht 10 zeilen code ... schaus dir doch einfach mal an ...

Würd ich auch sagen. :mrgreen:

*angeguckt hat*
Na wenn das nicht zum Verstehen reicht. :gruebel:

[Lesco]

jo der comment hat geholfen denke ich habs jetzt verstanden

[NicoDE]

Die CRT-Methode verursacht Probleme bei Programmen (32-Bit) die unter WoW64 (Win32-Emulator von Windows x64) laufen.
Da EliCZ den Quelltext nicht veröffentlicht hat, solltest Du _vorher_ Abfragen, ob der Zielprozess 64-Bit ist...

[Speedmaster]

Im Delphi-Forum gibt es glaube ich einen wunderschönen Thread dazu!

Edit:

http://www.delphi-forum.de/viewtopic...ghlight=dll+in

[NicoDE]

Zitat:

Zitat von Speedmaster

Im Delphi-Forum gibt es glaube ich einen wunderschönen Thread dazu!

Von der dort verwendeten CRT-Methode (Thread-Hijacking) würde ich abraten.

[perle]

warum?

[NicoDE]

Zitat:

Zitat von perle

warum?

Zu unsicher. Funktioniert in 99% ohne Probleme, Nebenwirungen sind aber nicht ausgeschlossen. Die Implementierungen von CreateRemoteThread für Win9x von Madshi und EliCZ sind besser.

[Kedariodakon]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von perle

warum?

Zu unsicher. Funktioniert in 99% ohne Probleme, Nebenwirungen sind aber nicht ausgeschlossen. Die Implementierungen von CreateRemoteThread für Win9x von Madshi und EliCZ sind besser.

Hmm ok dafür kostet abver der Code von Madshi was und EliCZ sagt mir nix...

Bye

[NicoDE]

Zitat:

Zitat von Kedariodakon

Hmm ok dafür kostet abver der Code von Madshi was und EliCZ sagt mir nix...

Es gibt AFAIK keine entsprechende OpenSource-Variante für CRT9x, sorry.
Ich habe anno dazumal mit einem befreundeten Entwickler an einer eigenen Implementation gearbeitet. Die Methode ist letztendlich der von Madshi ziemlich ähnlich (ich habe kurz danach Madshis Quellen erworben).

EliCZ ist der Nickname von Radim Picha. http://www.apihooks.com

[MartinA]

Die einfachste Methode is meiner Neinung nach einen Denkanstos werfe ich einfach einen Hook in den Raum.

Vorraussetzung: Ich kenne den Namen der EXE in die Injiziert werden soll.

Verfahren:

1. Einen Messagehook aufsetzen:

Code:

Irgendwas := SetWindowsHookEx(WH_GETMESSAGE, @MsgHook, hInstance, 0);

2.1 Im Hook selbst wird bereits gemacht

Code:

function MsgHook(Code: Longint; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
if (extractexename(getcommandline)='MEINEXENAME.EXE') then
  begin
    :
    code hier
    :
  end;
 Result := CallNextHookEx(msghookc, Code, wParam, lParam);

2.2 Im Hook wird der zu injizierende Code nachgeladen.

Code:

function MsgHook(Code: Longint; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
if ((extractexename(getcommandline)='MEINEXENAME.EXE')) and (pruefung=false) then
  begin
    hinstance := Loadlibrary ('INJIZIERTE.DLL');
  end;
 Result := CallNextHookEx(msghookc, Code, wParam, lParam);

Als Schmankerl stelle ich dann noch folgende Procdeduren zur Verfügung.

Code:

Procedure WriteSecureBuffer(Addr: DWord; Data: Pointer; Len: Word);
Var
  Written: DWord;
  ToPos  : Pointer;
begin
  ToPos:= Pointer(Addr);
  WriteProcessMemory(GetCurrentProcess, ToPos, Data, Len, Written);
end;

procedure MakeJump(ZielAddr, JumpAddr, NOPS: DWord);
Var
 Buffer  : Array[1..5] of Byte;
 Data    : DWord;
 X       : Byte;
begin
  Data:= ZielAddr - (JumpAddr + 5);
  Move(Data, Buffer[2], 4);
  Buffer[1]:= $E9;
  WriteSecureBuffer(JumpAddr, @Buffer, 5);
  For X:= 1 to NOPS do WriteSecureByte(JumpAddr + 4 + X, $90);
end;

Gruß
Martin

[NicoDE]

Zitat:

Zitat von MartinA

1. Einen Messagehook aufsetzen:

Es kann (und wird, je nach Windows-Version) passieren, dass die Hook-DLL erst geladen wird, wenn die Anwendung den Eingabefokus erhält.

Zitat:

Zitat von MartinA

Im Hook wird der zu injizierende Code nachgeladen.

Performance-Overkill. Message-Hook-Callbacks werden sehr oft aufgerufen. Warum nicht einfach in der LibraryProc der DLL?

Zitat:

Zitat von MartinA

Als Schmankerl stelle ich dann noch folgende Procdeduren zur Verfügung.

Du hast vergessen die Attribute der Speicherseite zu prüfen und notfalls temporär zu ändern.

[Lesco]

Zitat:

Zitat von MartinA

Die einfachste Methode is meiner Neinung nach einen Denkanstos werfe ich einfach einen Hook in den Raum.

Vorraussetzung: Ich kenne den Namen der EXE in die Injiziert werden soll.

Verfahren:

1. Einen Messagehook aufsetzen:

Code:

Irgendwas := SetWindowsHookEx(WH_GETMESSAGE, @MsgHook, hInstance, 0);

[/code]

Gruß
Martin

wieso denn einen systemweiten hook?
prozessweit würde auch reichen oder?

//EDIT: Habs jetzt mit nem prozessweiten Message-Hook hinbekommen. Diese Sachen mit VirtualAllocEx und Co. hab ich nie wirklich hinbekommen. Zu dem Punkt dass das Fenster die Nachrichten erst beim durch Focus empfängt: Trat bei mir nur bei SendMessage() auf, bei PostMessage() nicht.

[c113plpbr]

So ... ich hab mir jetzt kurzerhand meine eigene DLL-Injektions Library geschrieben (vorallem für ein Jugend forscht Projekt). Sie läuft (bisher) nur unter NT-Systemen, aber dort eigentlich recht stabil (laut meinen tests ;) ).
Die Library kann Dll's injezieren, und auch wieder uninjezieren.
Wer will kann sie sich ja mal anschauen, und ggf. auch kritisieren (aber bitte nur konstruktive Kritik).

Für den Fall, dass jemand den Code der RemoteThreads Debuggen will, den Kommentar des defines (break_in_remotethread) ganz oben aufheben & neucompilieren (dann wird in jedem RemoteThread ein "hartgecodeter" Breakpoint aufgerufen).

Ich denke, dass ich das ganze einigermaßen verständlich kommentiert habe, also könnte es auch als "Tutorial" dienen. Dazu sollte man sich aber zmd. mit den Grundlagen von Assembler auskennen.

ciao, Philipp

[NicoDE]

Zitat:

Zitat von c113plpbr

Wer will kann sie sich ja mal anschauen, und ggf. auch kritisieren (aber bitte nur konstruktive Kritik).

Die ganze Arbeit musst Du dir nicht machen...

Der Trick bei CreateRemoteThread besteht ja darin, dass die TThreadFunc aufrufkompatibel zu LoadLibrary ist.
Das heisst, dass Du per CreateRemoteThread einen Thread an der Adresse von LoadLibrary erzeugst und als 'Thread'-Parameter die Adresse des Dateinamens im entfernten Prozess angibst. Und das schöne darin ist, dass man anhand des ExitCodes des Threads (= Rückgabe von LoadLibrary) feststellen kann, ob das Laden erfolgreich war.

Das gleiche gilt für FreeLibrary.

ps: wie oben schon erwähnt, sollte man nicht versuchen aus einem 32-Bit Programm einen RemoteThread in einem 64-Bit Prozess zu erzeugen, da sich die LoadLibrary-Funktion dort an einer anderen Adresse befindet (man müsste also die Adresse aus der 64-Bit-Version der kernel32.dll auslesen - nicht sonderlich trivial).

[c113plpbr]

Zitat:

Zitat von NicoDE

Der Trick bei CreateRemoteThread besteht ja darin, dass die TThreadFunc aufrufkompatibel zu LoadLibrary ist.
Das heisst, dass Du per CreateRemoteThread einen Thread an der Adresse von LoadLibrary erzeugst und als 'Thread'-Parameter die Adresse des Dateinamens im entfernten Prozess angibst. Und das schöne darin ist, dass man anhand des ExitCodes des Threads (= Rückgabe von LoadLibrary) feststellen kann, ob das Laden erfolgreich war.

Das gleiche gilt für FreeLibrary.

Hmm ... ja, wäre eine überlegung wert, aber bei dieser Methode müsste ich mir ja dann zwangsweise das Modulehandle, das LoadLibrary zurückgibt merken, oder? Außerdem könnte ich doch (so wie es jetzt ist) z.B. DLL's die ich nicht geladen habe, damit entladen, oder? :gruebel:
Hmm ... naja, wie auch immer, es war mal interessant soetwas zu programmieren ... ^^ ... und es ist ja nicht "falsch" ;)

Zitat:

Zitat von NicoDE

ps: wie oben schon erwähnt, sollte man nicht versuchen aus einem 32-Bit Programm einen RemoteThread in einem 64-Bit Prozess zu erzeugen, da sich die LoadLibrary-Funktion dort an einer anderen Adresse befindet (man müsste also die Adresse aus der 64-Bit-Version der kernel32.dll auslesen - nicht sonderlich trivial).

Hmm ... ja ... bisher hab ich noch nicht viel mit 64-Bit systemen (oder auch mit deren prozessen) am hals, obwohl ich nen AMD64 hab ^^ (M$'s gratis testversion von xp64 hab ich schon, nur noch keine zeit gefunden es zu installieren ...)
BTW, wie kann ich herausfinden, ob ich einen 64-Bit Prozess vor mir hab?

Andere Frage, wie schauts da eigentlich bei .NET Programmen aus? Ich mein, die arbeiten doch nicht mehr mit DLL's, oder?

ciao, Philipp

[NicoDE]

Zitat:

Zitat von c113plpbr

ja, wäre eine überlegung wert, aber bei dieser Methode müsste ich mir ja dann zwangsweise das Modulehandle, das LoadLibrary zurückgibt merken, oder?

Jupp, das wäre ratsam.

Zitat:

Zitat von c113plpbr

Außerdem könnte ich doch (so wie es jetzt ist) z.B. DLL's die ich nicht geladen habe, damit entladen, oder?

Man kommt zu Beispiel per ToolHelp32-API an die Modul-Handles. Aber warum sollte man DLLs entladen, die man selbst nicht geladen hat?

Zitat:

Zitat von c113plpbr

BTW, wie kann ich herausfinden, ob ich einen 64-Bit Prozess vor mir hab?

Mittels IsWow64Process. Die Funktion sollte allerdings dynamisch geladen werden, da sie nicht auf allen Windows-Versionen vorhanden ist.

Zitat:

Zitat von c113plpbr

Andere Frage, wie schauts da eigentlich bei .NET Programmen aus? Ich mein, die arbeiten doch nicht mehr mit DLL's, oder?

Funktioniert (auf Win32) genauso.

[c113plpbr]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von c113plpbr

Außerdem könnte ich doch (so wie es jetzt ist) z.B. DLL's die ich nicht geladen habe, damit entladen, oder?

Man kommt zu Beispiel per ToolHelp32-API an die Modul-Handles. Aber warum sollte man DLLs entladen, die man selbst nicht geladen hat?

Naja ... vielleicht eine andere DLL entladen, die so geladen wurde? Oder "DLL-Wrapping" nur im Speicher durchführen? Es wird immer irgendwelche Anwendungsgebiete geben ... ^^

Zitat:

Zitat von NicoDE

Zitat:

Zitat von c113plpbr

Andere Frage, wie schauts da eigentlich bei .NET Programmen aus? Ich mein, die arbeiten doch nicht mehr mit DLL's, oder?

Funktioniert (auf Win32) genauso.

Hmm ... aber API-Hooking kann ich da wohl nicht auf die gewohnte "alte" art betreiben, oder? Gibts da überhaupt "gute" möglichkeiten?

ciao, Philipp

[NicoDE]

Zitat:

Zitat von c113plpbr

vielleicht eine andere DLL entladen, die so geladen wurde?

Ich würde keine DLL entladen, von der eine Anwendung denkt, dass sie noch geladen ist.

Zitat:

Zitat von c113plpbr

API-Hooking kann ich da wohl nicht auf die gewohnte "alte" art betreiben, oder?

Solange die Net-Module bzw. die RunTime Win32-API-Funktionen aufruft - warum nicht...