[DLL Injection] Code in fremden Prozess einschleusen

[Xerogon]

Hallo, ich beschäftige mich derzeit ein wenig mit DLL Injection und komme nicht weiter :evil:
Ich habe das kostenlose Spiel "Furby Speed" und den "Winject" Injector. Ich nutze Win7 x64.

Mein Code sieht derzeit so aus.

Delphi-Quellcode:

library Project1;

uses
  SysUtils, Windows,
  Classes;

{$R *.res}

Procedure HackMe;  stdcall;
var Data: Array[0..1] of Byte;
begin

  // zu schreibene Offsets
  Data[0] := $EB;
  Data[1] := $07;

    // Speicher Allocen
    VirtualAlloc(Ptr($0046A4A8), SizeOf(Byte)*2, MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    VirtualAlloc(Ptr($0046A589), SizeOf(Byte)*2, MEM_RESERVE, PAGE_EXECUTE_READWRITE);

    // Speicher umschreiben
    CopyMemory(Ptr($0046A4A8), @Data, SizeOf(Byte)*2);
    CopyMemory(Ptr($0046A589), @Data, SizeOf(Byte)*2);

end;

exports HackMe index 1;

begin
  HackMe;
end.

Warum stürzt das Programm immer ab wenn ich die DLL Injecte und wie könnte ich das überschreiben von Speicher in Inline Assembler lösen?
Vielen Dank für eure Antworten :thumb:

[Memnarch]

Meine Frage: Wo ziehlt den deine Adresse erstmal überhaupt hin`? Bist du dir sicher dass deine Adresse richtig ist?(bzw woher weißt du die? o.O)

EDIT: Und Hackme muss eig. nicht exportiert werden.
Wenn die DLL per winapi funktion in den Prozess geladen wird, wird automatisch das was zwischen begin...end steht ausgeführt.

[Xerogon]

Ich hab das Programm mit OllyDBG analysiert.
Nur manchmal kommt mir der Verdacht, das die DLL im falschen Modul was schreiben will :roll:

[himitsu]

Zitat:

Zitat von Xerogon (Beitrag 1101100)

Ich hab das Programm mit OllyDBG analysiert.
Nur manchmal kommt mir der Verdacht, das die DLL im falschen Modul was schreiben will :roll:

Es könnte auch der Verdacht aufkommen, daß das Gewünschte nicht immer an der selben Stelle/Adresse rumgammelt. :stupid:

[Neutral General]

Hallo,

Sicher dass das VirtualAlloc nötig/richtig ist?
Ich gehe ja mal davon aus, dass du einen vorhandenen (!) Speicherbereich überschreiben willst.
VirtualAlloc reserviert aber NEUEN Speicher.

Wenn an der Stelle die du bei VirtualAlloc angibst schon Speicher reserviert ist, passiert folgendes:

Zitat:

lpAddress
The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. If the memory is already reserved and is being committed, the address is rounded down to the next page boundary. To determine the size of a page and the allocation granularity on the host computer, use the GetSystemInfo function. If this parameter is NULL, the system determines where to allocate the region.

[Xerogon]

Zitat:

Es könnte auch der Verdacht aufkommen, daß das Gewünschte nicht immer an der selben Stelle/Adresse rumgammelt.

Das gammelt immer an der Stelle. Hab ich schon untersucht :-D

Zitat:

Zitat von Neutral General (Beitrag 1101109)

Hallo,

Sicher dass das VirtualAlloc nötig/richtig ist?
Ich gehe ja mal davon aus, dass du einen vorhandenen (!) Speicherbereich überschreiben willst.
VirtualAlloc reserviert aber NEUEN Speicher.

Wenn an der Stelle die du bei VirtualAlloc angibst schon Speicher reserviert ist, passiert folgendes:

Zitat:

lpAddress
The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. If the memory is already reserved and is being committed, the address is rounded down to the next page boundary. To determine the size of a page and the allocation granularity on the host computer, use the GetSystemInfo function. If this parameter is NULL, the system determines where to allocate the region.

Ok, ich probiere es mal.

[Xerogon]

[QUOTE=Xerogon;1101111]

Zitat:

Es könnte auch der Verdacht aufkommen, daß das Gewünschte nicht immer an der selben Stelle/Adresse rumgammelt.

Das gammelt immer an der Stelle. Hab ich schon untersucht :-D

Zitat:

Zitat von Neutral General (Beitrag 1101109)

Hallo,

Sicher dass das VirtualAlloc nötig/richtig ist?
Ich gehe ja mal davon aus, dass du einen vorhandenen (!) Speicherbereich überschreiben willst.
VirtualAlloc reserviert aber NEUEN Speicher.

Wenn an der Stelle die du bei VirtualAlloc angibst schon Speicher reserviert ist, passiert folgendes:

Zitat:

lpAddress
The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. If the memory is already reserved and is being committed, the address is rounded down to the next page boundary. To determine the size of a page and the allocation granularity on the host computer, use the GetSystemInfo function. If this parameter is NULL, the system determines where to allocate the region.

Ok, ich probiere es mal.

Edit: Nein, geht nicht. jetzt habe ich eine Zugriffsverletzung in der DLL

[himitsu]

Auf kurz und noch weiter gekürtzt, heißt die Antwort von Neutral General, soviel wie

Delphi-Quellcode:

Procedure HackMe; stdcall;
begin
  // Speicher umschreiben
  PWord($0046A4A8)^ := $EB07;
  PWord($0046A589)^ := $EB07;
end;

oder $07EB; :gruebel:

Zitat:

Nein, geht nicht. jetzt habe ich eine Zugriffsverletzung in der DLL

Kann es sein, daß die Zugriffsrechte nicht passen?
Schreibrechte würde man schon für sowas benötigen und diese Rechte ändert man nicht über VirtualAlloc.
VirtualAlloc = neuen virtuellen Speicher resservieren, aber wenn man mal bei VirtualAlloc ins MSDN guckt und da weiterklickt, dann landet man bei VirtualProtect :angle2:

[Neutral General]

@himitsu: Ich glaube es müsste $07EB sein.. Ist aber immer verwirrend :mrgreen:

Wenn das wirklich alles ist, dann würde ich mir den ganzen Mist mit der DLL-Injection sparen und einfach WriteProcessMemory benutzen ;)

Edit: Ergänzung zu himitsus Beitrag: Rechte ändert man mit VirtualQuery(Ex) VirtualProtect

[Xerogon]

Ja, Daten aus einer Anwendung mit WriteProcessMemory umschreiben kann ich. Es sollte nur mal als Übung dienen. :roll:

[himitsu]

Alloc = reservieren
Query = Infos abfragen
Protect = Zugriff anpassen
...

[Xerogon]

So, mal schnell als Win32 Anwendung gemacht. Da geht alles 8-)

Delphi-Quellcode:

var
  Form1: TForm1;
  ThreadID, ProcessID: Integer;
  WindowHandle: THandle;
  wnd: HWnd;
  write: Cardinal;
  Data: Array[0..1] of Byte;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin;

end;
procedure TForm1.Button1Click(Sender: TObject);
begin

  Data[0] := $EB;
  Data[1] := $07;

  wnd := FindWindow(nil, PChar('Ferby-Speed'));
  ThreadID := GetWindowThreadProcessID(wnd, @ProcessID);
  WindowHandle := Openprocess(PROCESS_ALL_ACCESS, false, processID);

  WriteProcessMemory(WindowHandle, Ptr($0046A4A8), @Data, SizeOf(Date), write);
  CloseHandle(WindowHandle);
end;

[Neutral General]

Wie kommt denn die DLL in den fremden Prozess?
Kannst du mal etwas Code zeigen?

PS: WindowHandle ist in deinem Beispiel kein guter Variablen-Name. Dein "WindowHandle" ist ein Prozess-Handle ;)

[Xerogon]

Ich benutze den Injector "Winject". http://www.cheat-project.com/cheats-...2/WinJect-1.7/

Mit dem Var Name: Das Programm habe ich auf die Schnelle gemacht. 8-)
Da Achte ich nicht auf Bezeichnungen.

[Neutral General]

Hallo,

Also davon ausgegangen, dass dieses Programm die DLL richtig in den fremden Prozess lädt.... hab ich keine Ahnung.

Aber per Inline-Assembler würde es wahrscheinlich auch einfach so gehen:

Delphi-Quellcode:

procedure HackMe; stdcall;
asm
  mov word [$0046A4A8], $07EB
  mov word [$0046A589], $07EB
end;

Ich weiß halt nicht, ob man in dem Prozess standardmäßig diese Pages beschreiben kann.
Ggf musst du halt noch VirtualProtect benutzen. Ansonsten wüsste ich nicht woran es noch liegen könnte.

[Xerogon]

Problem gelöst ;)

Wenn jemand die Lösung braucht:

Delphi-Quellcode:

library testdll;

uses
  SysUtils,
  Windows,
  Classes;

VAR
    dwOldDestProt: DWord = 0;  // Alter Protected Mode
    Data: Array[0..1] of Byte; // Zu schreibende Opcodes

{$R *.res}

Procedure MemSet; stdcall;
begin
  Data[0] := $EB;
  Data[1] := $07;


  // Protected Mode umstellen und alten Sichern
  VirtualProtect(Ptr($0046A4A8), SizeOf(Byte)*2, PAGE_EXECUTE_READWRITE, @dwOldDestProt);
  CopyMemory(Ptr($0046A4A8), @Data, SizeOf(Byte)*2);

  // Alten Modus wiederherstellen
  VirtualProtect(Ptr($0046A4A8), SizeOf(Byte)*2, dwOldDestProt, nil);


end;

exports MemSet;

begin
  MemSet;
end.

[Zacherl]

Ganz generell vielleicht noch zum "Memory Hacking". Hier zwar nicht so wichtig, weil der Code direkt in der EXE liegt, aber wenn du mal eine Anwendung hast, die DLLs nachläd und du in diese DLLs schreiben willst, dann immer relative Adressen der Form:

ImageBase + Offset

verwenden. Achso und wenn du wirklich nur einzelne Opcodes ändern willst, ist anstelle von CopyMemory der direkte Zugriff ganz hilfreich:

Delphi-Quellcode:

if VirtualProtect(Pointer($0046A4A8), 2, PAGE_EXECUTE_READWRITE, @dwOldDestProtect) then
try
  PByte($0046A4A8 + $00)^ := $EB;
  PByte($0046A4A8 + $01)^ := $07;
finally
  VirtualProtect(Pointer($0046A4A8), 2, dwOldDestProtect, nil);
end;

Dann musst du nicht groß mit Arrays rumbasteln und kannst bei eigenen Records sogar ganze Datenstrukturen bequem schreiben. Ich hatte vor einiger Zeit mal ein kleines Tutorial zum Thema verfasst:
http://opcodez.wordpress.com/2010/09...king-teil-1-5/

[Xerogon]

Danke, das Tutorial werde ich mir mal durchlesen :)