Handle einer geladenen DLL in einem anderen Process finden

[Reddog]

Hallo,

ich habe hier ein recht verzwicktes Problemm. Wie der Titel schon sagt, möchte ich das Handle einer geladenen DLL auslesen. Die DLL wurde aber nicht vom Programm selbst, sondern von einem anderen Process geladen. Deswegen krieg ich mit GetModuleHandle das Handle nicht, da diese Funktion anscheinend nur den eigenen Process durchsucht. Und mit LoadLibrary ruft es, glaub ich, die DLL einfach neu auf, so dass ich keinen Einfluss auf den anderen Process nehmen kann.

Also, wenn mir jemand weiter helfen könnte, ich wäre sehr froh.

Reddog.

[Luckie]

Kuck dir mal meine SysInfo an, da habe ich Code drin der alle im System geladenen Module auflistet, auch die anderer Processe.

[Reddog]

Hmm das SysInfo kann ich irgendwie nicht runterladen.
Ist die Adresse: http://www.luckie-online.de/cgi-bin/...sysinfosfx.exe richtig?
Oder hab ich da was falsch verstanden?

Reddog.

EDIT: OK hab's jetzt von: http://www.luckie-online.de/Downloads/SysInfo3_2.zip

[kiar]

http://www.luckie-online.de/Downloads/

hier und ziemlich weit unten

[Reddog]

Hmm,

danke schon mal an Luckie, ich kann jetzt ein Handle der gewünschten DLL finden. Allerdings ist es ja nur innerhalb des aufrufenden Process gültig. Kann man aus diesem Handle jetzt irgendwie auf die globale Adresse schließen? Ansonsten nützt ja das Handle praktisch nichts. :(

Reddog.

[Luckie]

Wozu brauchst du denn das Handle überhaupt?

[Reddog]

Hätt ich vielleicht gleich schreiben sollen :wink:

Also eigentlich war das so gedacht:

Ich hab son kleines Spiel was diese DLL lädt. Ich möchte jetzt eine Funktion innerhalb dieser DLL benutzen. Von der Funktion weiß ich allerdings nur, an welcher Stelle relativ zum Anfang des DLL-Codes sie sich befindet(Naja und die Parameter, die sie erwartet). Jetzt hab ich mir gedacht ich könnte das Handle der DLL als die Adresse im Speicher benutzen und die Funktion direkt an der Stelle ansprechen. Wenn ich die DLL selbst lade, dann scheint die Methode auch ganz gut zu klappen (die Funktion die sonst das Spiel schließen soll, schließt dann mein Prog :D). Naja aber ich möchte ja das Spiel beeinflussen, deswegen müsste ich die vom Spiel geladene DLL ansprechen, oder?

Er könnte jetzt sein, dass das überhaupt keinen Sinn ergibt, weil ich mich mit sowas leider schlecht auskenne. Fällt dir dazu etwas ein?

[Luckie]

moment telefon

[Luckie]

Du willst also das fenster des Spieles schließen? Dann hol dir mit FindWindow das handle und schick mit SendMessage ein WM_CLOSE an das Fenster.

[Reddog]

Leider ist es nicht so einfach,

es war lediglich ein Beispiel, weil es einfach war das anhand dieser einen Funktion zu testen. Die DLL speichert bestimmte Variablen und beinhaltet einige Functionen, die im Spiel zum Einsatz kommen. Ich wollte eben diese von meinem Programm aus benutzen. Die sind aber in einem anderen Process, deswegen kann ich, obwohl ich den Entry Point dieser Functionen kenn, trotzdem nicht auf sie zugreiffen. Ich weiß aber nicht ob's überhaupt geht von meinem Programm aus auf den Speicher von dem anderen Programm zuzugreiffen.

Es geht bestimmt auch, wenn man bei dem Spiel eine DLL einschleust, aber das müsste man ja mit Assembler-Code machen (:( Dazu müsste ich mich ja wieder mit Assembler beschäftigen).

Ich hoffe das Problem ist klar geworden. :stupid:

[Luckie]

Du kannst auch eine DLL ohne ASM in den fremden Prozess einschleusen. Warum sollte man dazu ASM brauchen? Du muss ja Systemfunktionen aufrufen.

Was du willst ist also folgendes: In den Speicher des fremden Prozesses rein und dort Variablen auslesen? Dannmach dich mal über ReadProcessMemory und WriteProcessMemory schlau.

[Reddog]

Danke :D

genau aus diesem Grund frag ich hier nach. So schnell kriegt man kaum irgendwo eine Antwort.

Reddog. :dp:

[Luckie]

Ich sag dir aber gleich, das ist nicht gerade trivial. Kuckt dir mein LuckieDIPS von meiner Seite an. Ist mit Source und Kommentaren. Bei den LuckieDIPS funktioniert das so: Ich reserviere mir speicher im fremden Porzess, kopiere die Informationen da rein. In diesem Fall die Struktur und lese sie mit WriteProcessmemory aus und kopiere sie mir damit in eine identische Struktur in meinem Adressraum. Und dann kan ich damit machen, was ich will.

Dein Problem ist: Wie willst du die Variable in den von dir reservierten Speicher im fremden Prozess kopieren? Dafür aheb ich auch keine Lösung. Eventuell erklärst du noich, wozu du das brauchst bzw. warum du das machen willst. Willst du Spielstände öndern wäre ein Stichwort für die Suche hie rund bei Google Trainer.

[Reddog]

Also,
um genau zu sein will ich im Spiel einige Macros einbauen. Das kann ich aber nicht mit der Simulation von keystrokes machen, da ich vor allem auch zusätzliche Infos brauche, wo ich mich grad befinde, u.s.w. Aber wahrscheinlich kommt es einem Trainer ziemlich nahe, weil ich ja Zugriff auf die Spielvariablen und Funktionen haben möchte.

Reddog

[Luckie]

Also wenn das Spiel dazu keine Schnittstelle bietet, halte ich das für ein nahezu aussichtsloses Unterfangen.

[Reddog]

Warum denn?

Wenn das Spiel seine Funktionen benutzt und von denen weiß ich bereits die Entry Points, dann kann man, spätestens, wenn man eine DLL eingeschleust hat, diese auch benutzen. Es gibt ja bereits zahlreiche Hacks dazu, daher habe ich überhaupt die Infos über die Funktionen, aber ich wollte halt mal versuchen es ohne DLL-Einschleusen zu machen. Soll ja auch kein Hack werden, sondern einfach ein Macro-Prog.

BTW, wie würde man eigentlich eine DLL in einen anderen Process ohne ASM mappen?

Reddog.

[Luckie]

Schön du hast die Entry Points. Und weiter? Wie willst du da an die Variablen drankommen? Direkt den speicher auslesen dürfte schwierig werden. Und auch wenn du es schaffst, woher weißt du, wo die Variable liegt?

Was willst du denn immer mit deinem ASM? Es geht bei allem was mit dem OS zu tun hat schlicht und ergreifend nur um Betriebssystemfunktionsaufrufe. Das hat mit ASM gar nichts zu tun. Kuck dir hie rmal das DLL udn Hooking Tutorial von Assarbad an: http://www.luckie-online.de/Downloads/Importe/Assarbad/

[Reddog]

Guten Morgen,

ich markier das Thema mal als beantwortet, weil ja die eigentliche Frage längst beantwortet ist.

Zu den Variablen: Von denen weiß ich ja die Stellen an denen sie gespeichert werden, zumindest hab ich den Quell-Code von so nem Hack dazu und da steht, dass bei diesen Variablen kein DMA benutzt wird.(Und von da hab ich auch die Adressen, allerdings bin ich noch beim Entziffern, da es in c/asm geschrieben ist).

Wenn man jetzt eine DLL einschleusen wollte, dann muss sie ja praktisch in den Address-Space von dem bereits laufenden Programm rein. Man müsste also meiner Meinung nach das Spiel irgendwie dazu bringen die DLL zu laden. Deswegen hab ich das mit ASM gebracht. Ich hab mal irgendwo son Beispiel-Codefetzen gehabt, wo in eine andere Anwendung ASM-Code (per WriteProcessMemory?) eingefügt wurde, der dieses Programm dazu brachte eine DLL, praktisch wie mit LoadLibrary selbst zu laden. (Leider find ich das nicht, D'OH :wall: ).

Danke auf jeden Fall für die Hilfe,
auch wenn ich's letztendlich nicht schaffe, zumindest hab ich was neues gelernt :zwinker:

Reddog

[c113plpbr]

Kann man das eigentlich ned alles mit IPC Regeln? So wie ich das verstanden hab, willst du von einem externen Programm ein anderes beeinflussen. Mach halt in dein Programm irgendeine Kommunikationsmöglichkeit rein, und kommuniziere einfach über ipc, sei es über windowmessages, oder über mailslots. Oder hab ich da irgendwas falsch verstanden?

ciao, Philipp

[Luckie]

Dürfte schwer werden, wenn das andere Programm nicht von ihm ist.

[c113plpbr]

Na dann hab ich wohl was falsch verstanden ...
Aber: es gibt die möglichkeit eine DLL in das Spiel zu injezieren, und von dieser aus dann direkt im Speicher des Spiels zu handeln, als wäre man das Programm selbst. Für mehr dazu informierst du dich einfach mal über API/Function -Hooking, das hat viel damit zu tun.
Desweiteren kann ich dir den Quellcode eines in Delphi geschriebenen Trainers zukommen lassen, von dem man die Verwendung von ReadProcessMemory und WriteProcessMemory, genauso wie das systematische durchsuchen des Speichers nach einer variable sehr schön 'lernen' kann.

ciao, Philipp

[Reddog]

Es wäre tatsächlich echt hilfreich diesen Quelltext zu lesen. Kannst du ihn mir zukommen lassen?

Außerdem habe ich in dem Quellcode von einem Hack(:twisted:) zu einem anderen Spiel die von mir angesprochene Möglichkeit gefunden, es mit Hilfe von ASM-Injection zu machen.

Um genauer zu sein ermittelt das Programm ersteinmal die Adresse der Funktionen GetModuleHandleA, LoadLibraryA und FreeLibrary in der kernel32.dll. Diese sind ja für alle Processe gleich. Dann wird eine kleine ASM Sequenz geschrieben, die GetModuleHandle aufruft um festzustellen, ob die DLL geladen ist, und wenn nicht, dann wird sie mit LoadLibrary geladen, wenn ja dann wird sie wieder entladen. Diese ganze Sequenz wird per WriteProcessMemory an eine Stelle in den Memory Space des Spiel-Process geschrieben, und in der WndProc wird ein Call-Befehl hineingeschrieben, der diese Stelle aufruft.(Der Original-Code wird am Ende von dieser Stelle auch noch ausgeführt, so dass sich eigentlich nichts verändert). Die eigene DLL wird also von dem Spiel geladen, ohne dass es was merkt.

Ist leider in C++ und ASM, deswegen hat'S gedauert bis ichS' gecheckt habe. Außerdem bin ich grad noch beim rumprobieren, und weiß nicht ob ich's so anwenden kann. Eigentlich wollte ich ja ohne DLL-Injection auskommen. Aber , wenn's nicht anders geht mach ich's eben so.

Wie gesagt, wenn es irgendwie geht seine DLL von sem Spiel laden zu lassen ohne dieses ASM Zeug, würde ich das natürlich vorziehen.

Reddog.

[NicoDE]

Zitat:

Zitat von Reddog

Die eigene DLL wird also von dem Spiel geladen, ohne dass es was merkt.

Injezierte DLLs und Remote-Threads zu bemerken ist relativ simpel (habe vor ein paar Monaten für einen Kollegen mal eben eine generische Detection für einen relativ bekannten Cheat geschrieben).

Du brauchst eigentlich kein Assembler. Mit CreateRemoteThread (LoadLibrary und ThreadProc sind aufrufkompatibel) ist es relativ einfach - wird nur bei Win9x aufwendiger.

[Reddog]

Es geht ja auch nicht drum, ob die DLL dann entdeckt werden kann. Ich meinte nur, dass das Spiel ohne Veränderung weiter ausgeführt wird.

Danke für den Tip mit CreateRemoteThread, ich probier's mal aus.

[Reddog]

Delphi-Quellcode:

function MainProc(Param: DWORD): DWORD; stdcall;
begin
  LoadLibrary(...);
  while 1=1 do begin
  end;
end;

Delphi-Quellcode:

    ...

    SecAtt.nLength:= SizeOf(SECURITY_ATTRIBUTES);
    SecAtt.lpSecurityDescriptor:= nil;
    SecAtt.bInheritHandle:= True;
    HThread:= CreateRemoteThread(ProcessID, @SecAtt, 0, @MainProc, nil, THREAD_PRIORITY_NORMAL, TID);
    If HThread = 0 then
      RaiseLastOSError;

    ...

Hab ich da jetzt was falsch gemacht? Für HThread kommt immer 0 raus. Die ProcessID ist aber definiert und stimmt auch, hab mit SysInfo :) nachgekuckt.

[NicoDE]

Test-DLL:

Delphi-Quellcode:

library foo;

uses
  Windows;

{$IFNDEF CONDITIONALDEFINE}
// type def for Delphi 2-5
type
  TDLLProc = procedure(Reason: Integer);
{$ENDIF}

var
  DllProcNext: TDLLProc;  // nil

procedure LibraryProc(Reason: Integer);
var
  Filename: array [0..MAX_PATH] of Char;
begin
  Filename[0] := #0;
  GetModuleFileName(0, Filename, MAX_PATH);
  case Reason of
    DLL_PROCESS_ATTACH:
      begin
        DisableThreadLibraryCalls(HInstance);
        MessageBox(0, 'Attach', Filename, MB_OK or MB_SETFOREGROUND);
      end;
    DLL_PROCESS_DETACH:
      begin
        MessageBox(0, 'Detach', Filename, MB_OK or MB_SETFOREGROUND);
      end;
  end;
  if Assigned(DllProcNext) then
    DllProcNext(Reason);
end;

begin
  DllProcNext := TDLLProc(DllProc);
  TDLLProc(DllProc) := LibraryProc;
  LibraryProc(DLL_PROCESS_ATTACH);
end.

Beispiel-Code:

Delphi-Quellcode:

function LoadRemoteLibrary(Process: THandle; FileName: LPCTSTR): HMODULE;
var
  Size: DWORD;
  Buffer: Pointer;
  Written: DWORD;
  Thread: THandle;
  ThreadId: DWORD;
begin
  Result := 0;
  Size := (lstrlen(FileName) + 1) * SizeOf(FileName[0]);
  Buffer := VirtualAllocEx(Process, nil, Size, MEM_COMMIT, PAGE_READWRITE);
  if Assigned(Buffer) then
  try
    if WriteProcessMemory(Process, Buffer, Addr(FileName[0]), Size, Written) and
      (Written >= Size) then
    begin
      Thread := CreateRemoteThread(Process, nil, 0, TFNThreadStartRoutine(
{$IFDEF UNICODE}
        GetProcAddress(GetModuleHandle(kernel32), 'LoadLibraryW')
{$ELSE}
        GetProcAddress(GetModuleHandle(kernel32), 'LoadLibraryA')
{$ENDIF}
        ), Buffer, 0, ThreadId);
      if Thread <> 0 then
      try
        WaitForSingleObject(Thread, INFINITE);
        GetExitCodeThread(Thread, Result);
      finally
        CloseHandle(Thread);
      end;
    end;
  finally
    VirtualFreeEx(Process, Buffer, Size, MEM_RELEASE);
  end;
end;

function FreeRemoteLibrary(Process: THandle; Module: HMODULE): BOOL;
var
  Thread: THandle;
  ThreadId: DWORD;
begin
  Result := False;
  Thread := CreateRemoteThread(Process, nil, 0, TFNThreadStartRoutine(
    GetProcAddress(GetModuleHandle(kernel32), 'FreeLibrary')
    ), Pointer(Module), 0, ThreadId);
  if Thread <> 0 then
  try
    WaitForSingleObject(Thread, INFINITE);
    GetExitCodeThread(Thread, DWORD(Result));
  finally
    CloseHandle(Thread);
  end;
end;

////////////////////////////////////////////////////////////////////////////////

function OpenTarget: THandle;
const
  DesiredAccess = PROCESS_CREATE_THREAD or PROCESS_QUERY_INFORMATION or
    PROCESS_VM_OPERATION or PROCESS_VM_WRITE or PROCESS_VM_READ;
var
  Wnd: HWND;
  ProcessId: DWORD;
begin
  Result := 0;
  Wnd := FindWindow(nil, 'Unbenannt - Editor');
  if Wnd <> 0 then
  begin
    ProcessId := 0;
    GetWindowThreadProcessId(Wnd, ProcessId);
    if ProcessId <> 0 then
      Result := OpenProcess(DesiredAccess, False, ProcessId);
  end;
end;

var
  RemoteLibrary: HMODULE = 0;

procedure TForm1.Button1Click(Sender: TObject);
var
  Process: THandle;
begin
  Process := OpenTarget;
  if Process <> 0 then
  try
    RemoteLibrary := LoadRemoteLibrary(Process, 'C:\Temp\foo.dll');
    ShowMessage(IntToHex(RemoteLibrary, 8));
  finally
    CloseHandle(Process);
  end;
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  Process: THandle;
begin
  Process := OpenTarget;
  if Process <> 0 then
  try
    if FreeRemoteLibrary(Process, RemoteLibrary) then
      ShowMessage('TRUE')
    else
      ShowMessage('FALSE');
  finally
    CloseHandle(Process);
  end;
end;

[Vjay]

c113plpbr würdest du den Trainer hier auch attachen?

Mich und wahrscheinlich auch andere würde sowas zu studienzwecken interessieren.

Oder ist der gecopylefted?

[Reddog]

Danke für das asuführliche Beispiel. :hello:

[c113plpbr]

Zitat:

Zitat von Vjay

c113plpbr würdest du den Trainer hier auch attachen?

Mich und wahrscheinlich auch andere würde sowas zu studienzwecken interessieren.

Oder ist der gecopylefted?

Das Problem dabei is, dass der Trainer natürlich ned von mir is, und der Author den Quellcode komischerweise wieder zurückgenommen hat, warum auch immer. Daher weis ich ned, ob das dann OK wäre ...

aber ich glaub, dass ich den quellcode schonmal irgendwo gepostet hab ... jo, hier: http://www.delphipraxis.net/internal...=120285#120285
Es is unter der GPL veröffentlicht worden, also sollte das schon in ordnung sein ...

Das teil heißt Generic Game Trainer, und is im kompilierten zustand hier zu finden.

ciao, Philipp

[Reddog]

Hallo,

ich hoffe, dass das noch jemand liest, obwohl der Thread schon länger nicht mehr aktiv war.

Es funktioniert ganz gut mit dem Einfügen der DLL in den Process des Spiels. Danke an NicoDE.

Ich würde jetzt gerne einen Keyboard-Hook im Spiel installieren. Das würde ja ganz gut klappen, wenn das Spiel selbst die DLL lädt(Ich hab'S mal mit nem Test Programm statt dem Spiel ausprobiert). Aber wenn ich die DLL auf diesem Umweg lade, dann wird sie ja in einem anderen Thread geladen. Ich hab's mal probiert SetWindowsHookEx mit der Thread-ID des Spiels dem Pointer auf die Hook-Funktion und dem Handle der geladenen DLL aufzurufen. Das funktioniert so aber nicht warum auch immer. Deswegen wollte ich mal fragen, ob ich da was grundsätzliches übersehe.

Muss ich das jetzt mit einem globalen Hook machen?

Danke,
Reddog.

[Reddog]

[EDIT]: Sorry für Doppel-Post, die Seite hat sich bei mir seltsam aufgehängt. [/EDIT]

[c113plpbr]

Zitat:

Zitat von Reddog

Muss ich das jetzt mit einem globalen Hook machen?

Dies wäre ein weg, den ich aber nicht empfehle, da dieser ja global ist ... entweder kriegst du einen keybd-hook nur in das Spiel (frag mich ned wie), oder du fängst die Funktion die das Spiel verwendet um die Tastenanschläge zu bemerken ab, und 'missbrauchst' sie für deine eigenen Zwecke, oder, was ich immer zu testzwecken verwende, kannst du die Get(Async)KeyState-Funktion für eine Taste verwenden (quasi in einer Timerschleife), wobei die Async-Variation auch in anderen Programmen gesendete Tasten wahrnimmt.

ciao, Philipp

[NicoDE]

Wenn es sich um ein DirectX-Spiel handelt, kann es sein, dass Du mit einen Low Level Keyboard Hook an die Daten kommst.
Ansonsten kann es sein, dass das Spiel selbst einen Hook setzt oder Du die falsche ThreadId verwendet hast...


Gruss Nico

[Reddog]

Timer habe ich auch schon ausprobiert, mit SetTimer und einer TimerProc. Nur da die TiemrProc ja auch in der DLL drin ist, klappt das genauso wenig wie die Sache mit dem Hook, :(

[c113plpbr]

kapsle einfach einen thread ab, mach ne kleine endlosschleife rein, in der immer wieder z.B. GetKeyState abgefragt wird, und halte den thread dann mit z.B. Sleep(200) für 200ms an, und schon hast du eine Tastenabfrage!

Eine weitere Möglichkeit ist, wenn es sich um ein DX-Spiel handelt, dass die Input funktionen von DX verwendet, dass du die Input funktion einfach per Function-Hook abfängst, und das ergebnis für deine Zwecke verwendest.

ciao, Philipp

[Reddog]

Wie würde denn so ein Function-Hook funktionieren? Ich kann mir leider nicht Konkretes darunter vorstellen.

Das mit Endlosschleife und Sleep habe ich als Allererstes ausprobiert, aber es hält den Spiel-Thread auf, da es anscheinend nur einen aktiven Thread per Process geben kann.(Oder aus irgendeinem anderen Grund?).

Reddog.

[c113plpbr]

Du musst die Endlosschleife auch in einem neuen Thread unterbringt, sonst hälst du das spiel natürlich auf ...

Ein Function-Hook ist ein Hook, der eine funktion abfängt (wie der name schon sagt). Wenn du dies nun auf die Funktion von z.B. DirectInput die die Tasten ausliest anwendest, dann könntest du die tastatureingaben auch so abfangen.
Dies dürfte mit der MadCodeHook-Lib recht einfach gehen.

ciao, Philipp

[Reddog]

Gibt es eigentlich eine Möglichkeit das Spiel dazu zu bewegen die DLL selbst zu laden? Das wäre echt das Beste. Ich hab's versucht durch Überschreiben der ersten 5 Bytes der WndProc des Spiels mit einem CALL Aufruf zu einem Code-Stück, das dann die DLL laden soll. Aber irgendwas habe ich verpfuscht, da das Spiel gleich darauf Abstürzt, sogar, wenn ich den eigentlichen Code der die DLL lädt wegkommentiere. Also muss es an der Art und Weise liegen, wie ich die WndProc manipuliere.

Reddog.