Tag.

Ich möchte gerne Debug Events verarbeiten und ausgeben.
Dabei benutze ich die DebugActiveProcess() API-Funktion.

Es funktioniert auch eigentlich. Das Problem ist, Detailinformationen
zu bekommen. Z.B. wenn ich als Event 'LOAD_DLL_DEBUG_EVENT' bekomme.
Auf MSDN steht, dass das Member der Struktur TLoadDllDebugEvent
lpImageName keine Informationen hat, wenn man mit DebugActiveProcess()
arbeitet. Das ist übrigens bei den anderen Strukturen auch so.

Meine Frage ist nun, wie ich denn an diese Informationen sonst
herankommen könnte. Wäre nett, wenn mir Jemand helfen könnte.

Danke im Voraus.

MfG

Im Member lpBaseOfDll solltest Du über GetModuleNameEx den Image-Name abfragen können. Ansonsten über das File-Handle.

Bin aber leider in die Debug-API nicht weit genug eingearbeitet, um da wesentlich mehr zu sagen.

Ach ja:

msdn2.microsoft.com/...ibrary/ms809754.aspx :

Even more difficult is the task of determining which DLL is being loaded in the process being debugged when LOAD_DLL_DEBUG_EVENT occurs. During this debug event, the debugger receives the base address for the DLL being loaded, but only a module file handle with which to identify the DLL. Fortunately, the file handle can be used to read information about the file. To identify the file as the correct DLL, the debugger must determine the name of the DLL by extracting the filename, assigned by the linker, from the executable image. The name is found after tracing through a maze of offsets and tables of data embedded within the executable file. A limitation, though, exists in this technique. Since the name of the executable is embedded in the file during the link process, there is no way of knowing whether a user renamed the file after linking. Unfortunately, there is no way around this limitation. No other way exists to determine the name of the DLL that is being loaded in the debugger—yet, one can always hope that this will be a feature included in a future release of Windows NT.

Da gibt's aber einen einfachen Weg, den man nutzen könnte:
1. Man schreibt sich eine Funktion (in ASM), diealle alleinig die Aufgabe hat, alle Module des aktuellen Prozesses zu listen. Diese muss Offset-Unabhängig sein (relociierbar).
Im zu debuggenden Prozess reserviert man mit VirtualAllocEx einen Speicher-Bereich, der groß genug ist, diese Funktion aufzunehmen, sowie 3 Pointer: LoadLibrary, GetProcAddress und einen Zeiger auf einen weiteren Speicherbereich. Mit GetProcAddress holt man sich von benötigten API-Funktionen jeweils die Adresse, mit LoadLibrary deren Handles und legt dann im dritten Zeiger nen Verweis auf alle vorhandenen DLLs ab (samt Namen\Modulpfad). Diese Namen kann man (innerhalb des Prozesses mit GetModuleName(HMODULE) recht einfach abfragen. Iterieren über die DLLs geht recht einfach mit VirtualQuery und ansonsten halt noch ein Event ggf. mitgeben, damit man nach Abschluss der Arbeiten den Speicher wieder aufräumen kann.

Wie man die Adresse von LoadLibrary und GetProcAddress ohne aufruf dieser Funktionen findet, findet man in der uallCollection ganz einfach erklärt.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hi,

mit dem Member 'hFile' habe ich es schon probiert, aber es klappt leider nicht.

Über lpBaseOfDll habe ich mir noch keine Gedanken gemacht. Wie soll ich den Member
in GetModuleFileNameEx() benutzen? Es ist ja kein Handle, sondern ein Pointer.

Danke im Voraus.

MfG

Ganz einfacher Grundsatz: (Steht auch im verlinkten Artikel indirekt drin:
Unter Windows ist das Module-Handle (HMODULE) einer DLL seine Basis-Adresse im Speicher (virtuellen Adressraum) des Prozesses, der die DLL geladen hat.

D.h. (HMODULE)dll = (HMODULE)deinfo->lpBaseAddr;

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Danke für die Antwort, du hattest recht. lpBaseOfDll ist das Handle. Danke sehr.
Damit konnte ich die DLL Namen einfach über GetModuleFileNameEx via OpenProcess auslesen. Thx.