Hey,

mir kam da grade eine Idee, wie ich einen Usermode Hook realisieren könnte, ohne eine Dll zu injizieren. Und zwar dachte ich mir, dass ich einfach wie bei einem normalen inline Hook vorgehe, dabei aber nicht in die eigene Dll zu springen, sondern in den Adressraum meiner eigenen EXE, bzw einer Art Shared Memory.

Ist sowas möglich?

Gruß Zacherl

Ich habe zwar nicht ganz verstanden, wie du das erreichen willst, aber es funktioniert auf jeden Fall. Du kannst zum Beispiel einen Thread injizieren, den du nicht bei LoadLibrary starten lässt, sondern bei einer selbst geschriebenen Funktion, die du mit VirtualAllocEx und WriteProcessMemory in den fremden Speicher beförderst. Das einzige Problem ist dabei, dass man nicht einfach auf fremde Routinen zugreifen kannst. Ich habe eine derartige Technik einmal verwendet, um die Places Bar in den Öffnen-Dialogen des BDS zu verändern. Dort habe ich das mit einer handcodierten Assembler-Funktion gelöst, die einfach Zeiger auf die Funktionen enthielt.

Meinte das bisschen anders. Einfach gesagt schreibe ich z.b. am Anfang des MessageBoxA Imports von notepad.exe ein JMP [Einsprungspunkt in meinem Prozess]. Also dass immer wenn notepad MessageBoxA aufgerufen wird erstmal ein JMP in meinen Prozess durchgeführt wird, dort dann mein Hook aufgerufen wird.

Und wie sorgst du dafür, dass dein Code in den fremden Prozess gemappt wird?

Du kannst auf das Mappen natürlich verzichten, indem du zum Beispiel mit Fensternachrichten arbeitest, aber das war wohl nicht deine Intention.

Ich geb zu, dass ich mich wahrscheinlich schlechter damit auskenne als du, aber soweit ich weiß, haben unter NT doch alle Prozesse ihren eignen virtuellen Prozessraum. Von daher würde ich mal schätzen, dass du nicht einfach in deinen eigenen Prozess springen kannst.

@NamenLozer: Ja genau das meinte ich. Meine Frage ist halt, ob ich irgendwo eine Art zentralen Hook installieren kann. Sprich alle Prozesse rufen die selbe Hook Callback Funktion auf, welche sich in meinem Prozess befindet.

@Apollonius: Das Mappen geht dann ganz normal mittels WriteProcessMemory, aber ohne, dass ich CreateRemoteThread verwende. Um den Einsprungspunkt zu finden, muss ich ja nur GetProcAddress und GetModuleHandle anwenden. Die Adressen sollten ja in jedem virtuellen Adressram der geladenen Dll gleich sein.

Ja, das geht auch ohne CreateRemoteThread. Aber die Funktionen erhältst du nicht so einfach. Schließlich brauchst du auch erst mal die Zeiger auf GetModuleHandle und GetProcAddress.

Wenn du viele Prozesse hooken willst, solltest du vielleicht über SendMessage nachdenken.

Okay, wie würde das denn konkret aussehen, wenn ich z.b. MessageBoxA in einem Prozess jetzt auf einen Callback in meinem eigenen Prozess umlenken möchte?

Was heißt für dich "in deinem Prozess"? Wenn du Zugriff auf globale Variablen brauchst, würde ich SendMessage nehmen. Alles andere wird sehr unschön. Wenn es dir nur darum geht, denn Code aus deinem Prozess zu holen, kannst du ihn ja einfach mit VirtualAllocEx und WriteProcessMemory hinüberschieben und dann diesen Funktionszeiger verwenden. Das Problem mit GetModuleHandle und GetProcAddress löst du z.B. folgendermaßen:

zusammenfalten · markieren

Delphi-Quellcode:

//nicht getestet
procedure AsmHelper({Parameters}); stdcall;
asm
  call @@Ahead
  @@GetProcAddr:
  dd 0
  @@GetModH:
  dd 0
  @Ahead:
  pop eax
  pop edx
  push [eax + 4]
  push [eax]
  push edx
  jmp RealProc
end;

procedure RealProc(GetProcAddr, GetModH: Pointer {; Parameters}); stdcall;
begin
end;

Dann musst du nur noch ein weiteres WriteProcessMemory verwenden, um die Adressen in AsmHelper einzufügen. Der Sprung am Ende müsste funktionieren, wenn du beide Routinen in einem Block belässt.

Danke dir, denke damit sollte ich was anfangen können.