Erkennen einer dll-injection
-
Ja, klar, bloss musst du dazu irgendwie das Programm hijacken.
Ich meine irgend ein Thread muss ja deinen Code ausführen, und wenn du nicht selbst einen mittels CreateRemoteThread erstellst... welcher sollte es dann sein?
-
Die "normale" API bietet einen mächtigen Debugger-Support.
Einige dieser Funktionen "unkonventionell" angewendet, ermöglichen alles.
-
Wie kann man über die offiziell dokumentierten API Funktionen ein WriteProcessMemory erkennen? (Im Zielprozess natürlich. p.S.: oder in einem "Drittprozess".)
-
Ich meinte damit, dass die dokumentierten Debugger-Funktionen ein "Thread-Hijacking" ermöglichen.
Damit lässt sich Code ausführen ohne Remote-Thread. Sehr üble Sache sowas.Einen Remote-Thread kann ein Programm aber erkennen (z.B. via DLL). Hooks auch.
Aber einem Read/WriteProcessMemory () oder einem VirtualAllocEx () gegenüber ist ein Programm im Prinzip völlig hilflos ausgeliefert.
Dagegen gibt es weder eine dokumentierte noch eine undokumentierte API.
-
Wenn aber ein Debugger aktiv ist, kann man das zumindest auch feststellen in senem Programm. Auch hier ist man nicht hilflos.
-
Hallo,
was nützt einem eigentlich "nur" WriteProcessMemory() und VirtualAllocEx() bzw umgekehrt? eben ohne einen Thread ausführen zu können?
mfg
-
Wennman bestehenden Code liest und manipuliert, der ausgeführt wird nützt es einem was...
-
Wennman bestehenden Code liest und manipuliert, der ausgeführt wird nützt es einem was...
-
Mit WriteProcessMemory () kannst Du z.B. Code und Daten in Prozessen manipulieren.
Mit VirtualAllocEx () kannst Du z.B. zur Laufzeit Daten in Prozessen "verstecken".
Ob das einen "Nutzen" hat, mag jeder für sich selbst entscheiden. "Unschön" ist sowas allemal.
-
hustbaer schrieb:
Ja, klar, bloss musst du dazu irgendwie das Programm hijacken.
Ich meine irgend ein Thread muss ja deinen Code ausführen, und wenn du nicht selbst einen mittels CreateRemoteThread erstellst... welcher sollte es dann sein?Da gibt es noch weitere (un)schöne Möglichkeiten, z.B. APC
Schau mal hier unter "New techniques for codeinjection", ist von mir:
http://rootkit.com/Prinzipiell würde ich mal sagen ist es kein Problem Code/Daten unbemerkt in einen fremden Prozess zu laden, sie auszuführen dagegen schon eher.
Martin Richter schrieb:
Wenn aber ein Debugger aktiv ist, kann man das zumindest auch feststellen in senem Programm. Auch hier ist man nicht hilflos.
Und wie? Mit IsDebuggerPresent? PEB->BeingDebugged auf FALSE setzen und schon ist man wieder fein raus (= der Fremdprozess verarscht).
-
CreateFile (), RegOpenKey (), OutputDebugString (je länger, desto besser).
Möglichkeiten gibt es genug. Aber die Präsenz eines Debuggers bedeutet noch längst nicht "Gefahr".
Ein Debugger sollte schliesslich auf jedem PC installiert sein.
-
Prinzipiell würde ich mal sagen ist es kein Problem Code/Daten unbemerkt in einen fremden Prozess zu laden, sie auszuführen dagegen schon eher.
Eben das meinte ich. Die einzige mir bekannte "saubere" Möglichkeit die Ausführung injizierten Codes hinzubekommen ist eben CreateRemoteThread.
Ansonsten muss man schon etwas brutaleres machen, z.B. den Anfang einer Funktion zu überschreiben deren Adresse man kennt (irgendwas aus KERNEL32 oder GDI oder so), und die das Programm wohl verwendet (GetMessage/HeapAlloc/... irgendeine der "beliebten" Funktionen halt).
Das meinte ich mit "hijacken".----
was nützt einem eigentlich "nur" WriteProcessMemory() und VirtualAllocEx() bzw umgekehrt? eben ohne einen Thread ausführen zu können?
Naja, nicht viel eben, ausser man ist etwas "brutal" (siehe oben).
----
Aber einem Read/WriteProcessMemory () oder einem VirtualAllocEx () gegenüber ist ein Programm im Prinzip völlig hilflos ausgeliefert.
Dagegen gibt es weder eine dokumentierte noch eine undokumentierte API.Sicher? Ich bin mir nämlich fast sicher dass man für diese Funktionen globale Hooks setzen kann - wahrscheinlich bloss ausm Kernelmode raus, was u.U. einen Hilfstreiber nötig macht, aber naja. Gehen sollte es. Muss nochmal sehen ob ich genauere Infos dazu finde.
