AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Delphi Handle einer geladenen DLL in einem anderen Process finden
Thema durchsuchen
Ansicht
Themen-Optionen

Handle einer geladenen DLL in einem anderen Process finden

Ein Thema von Reddog · begonnen am 25. Jul 2004 · letzter Beitrag vom 31. Jul 2004
Antwort Antwort
Seite 3 von 4     123 4      
Benutzerbild von c113plpbr
c113plpbr

Registriert seit: 18. Nov 2003
Ort: localhost
674 Beiträge
 
Delphi 2005 Professional
 
#21

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 26. Jul 2004, 17:21
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
Philipp
There is never enough time to do all the nothing you want.
*HABENWILL*
  Mit Zitat antworten Zitat
Benutzerbild von Reddog
Reddog

Registriert seit: 18. Jul 2004
Ort: Würzburg
56 Beiträge
 
#22

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 26. Jul 2004, 20:33
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() 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.
All prime numbers are odd with the exception of two, which is an odd prime
  Mit Zitat antworten Zitat
NicoDE
(Gast)

n/a Beiträge
 
#23

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 26. Jul 2004, 23:52
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.
  Mit Zitat antworten Zitat
Benutzerbild von Reddog
Reddog

Registriert seit: 18. Jul 2004
Ort: Würzburg
56 Beiträge
 
#24

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 27. Jul 2004, 00:00
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.
All prime numbers are odd with the exception of two, which is an odd prime
  Mit Zitat antworten Zitat
Benutzerbild von Reddog
Reddog

Registriert seit: 18. Jul 2004
Ort: Würzburg
56 Beiträge
 
#25

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 27. Jul 2004, 00:30
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.
All prime numbers are odd with the exception of two, which is an odd prime
  Mit Zitat antworten Zitat
NicoDE
(Gast)

n/a Beiträge
 
#26

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 27. Jul 2004, 01:38
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;
  Mit Zitat antworten Zitat
Vjay

Registriert seit: 2. Dez 2003
Ort: Berlin/Eschede
481 Beiträge
 
Delphi 7 Professional
 
#27

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 27. Jul 2004, 09:44
c113plpbr würdest du den Trainer hier auch attachen?

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

Oder ist der gecopylefted?
Wer später bremst ist eher tot.
  Mit Zitat antworten Zitat
Benutzerbild von Reddog
Reddog

Registriert seit: 18. Jul 2004
Ort: Würzburg
56 Beiträge
 
#28

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 27. Jul 2004, 13:26
Danke für das asuführliche Beispiel.
All prime numbers are odd with the exception of two, which is an odd prime
  Mit Zitat antworten Zitat
Benutzerbild von c113plpbr
c113plpbr

Registriert seit: 18. Nov 2003
Ort: localhost
674 Beiträge
 
Delphi 2005 Professional
 
#29

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 27. Jul 2004, 22:06
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
Philipp
There is never enough time to do all the nothing you want.
*HABENWILL*
  Mit Zitat antworten Zitat
Benutzerbild von Reddog
Reddog

Registriert seit: 18. Jul 2004
Ort: Würzburg
56 Beiträge
 
#30

Re: Handle einer geladenen DLL in einem anderen Process find

  Alt 29. Jul 2004, 00:47
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.
All prime numbers are odd with the exception of two, which is an odd prime
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 4     123 4      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz