OutputDebugString überwachen

[Delphi Star]

Wie kann man den OutputDebugString überwachen, so wie bei diesem Tool von Sysinternals :?:

[Mephistopheles]

Indem du ganz gepflegt die gleiche Methode verwendest. Und die wäre diese:

1. Du lernst C/C++ und NT-Treiberprogrammierung (für Windoes 9x natürlich VXD-Programmierung)
2. Du schreibst einen Treiber und einen Service welcher mit dem Treiber kommuniziert
3. Der Treiber muß diverse APIs im Kernelmode hooken
4. Dein Tool zeigt die Ausgabe dessen an, was der Hook abfängt.

Voila. Das war's schon. Viel Erfolg.

Wenn irgendjemand meine "wilden Hypothesen" verifizieren möchte, mag er sich seinen Lieblingsressourceneditor/-betrachter zur Hand nehmen und in ebendiesem alle Ressourceneinträge unter "BINRES" betrachten. Für eine weitere Analyse empfiehlt sich dann ein Disassembler, wie z.B. IDA.

[Sprint]

Zitat:

Zitat von Mephistopheles

Wenn irgendjemand meine "wilden Hypothesen" verifizieren möchte [...]

Brauche ich nicht, Windows stellt diverse Win32API Funktionen aus der Debug-Abteilung zur Verfügung. So dass man das gewünschte Ergebnis sogar mit Visual Basic realisieren könnte.

PS: Für mich bist du aber der "Schlaumeier des Tages".

[Delphi Star]

Zitat:

Windows stellt diverse Win32API Funktionen aus der Debug-Abteilung zur Verfügung. So dass man das gewünschte Ergebnis sogar mit Visual Basic realisieren könnte.

Und wie geht das mit Delphi :?:

[Sprint]

CreateProcess
DEBUG_PROCESS
WaitForDebugEvent

[w3seek]

Zitat:

Zitat von Mephistopheles

Indem du ganz gepflegt die gleiche Methode verwendest. Und die wäre diese:

1. Du lernst C/C++ und NT-Treiberprogrammierung (für Windoes 9x natürlich VXD-Programmierung)
2. Du schreibst einen Treiber und einen Service welcher mit dem Treiber kommuniziert
3. Der Treiber muß diverse APIs im Kernelmode hooken
4. Dein Tool zeigt die Ausgabe dessen an, was der Hook abfängt.

Ich glaub du verwechselst das mit DbgPrint...

OutputDebugString kann man abfangen indem man den prozess debuggt, mit hilfe der funktion WaitForDebugEvent kann man dann auf diverse debug ereignisse warten, einschliesslich OutputDebugString (siehe OUTPUT_DEBUG_STRING_INFO).

[w3seek]

ok, Sprint war schneller ;)

[Mephistopheles]

@w3seek: Du hast insofern recht, als diese natürlich ebenfalls abgefangen werden können. Da du im ROS-Projekt dabei bist, kennst du ja quasi die Windows-Interna. Allerdings debuggt eben der DbgView von Sysinternals keinesfalls den Target, sondern setzt auf einer tieferen Ebene an.

__________________________________________________ ________
@Sprint:

Zitat:

Zitat von Sprint

Brauche ich nicht, Windows stellt diverse Win32API Funktionen aus der Debug-Abteilung zur Verfügung. So dass man das gewünschte Ergebnis sogar mit Visual Basic realisieren könnte.

:lol: ... das wäre der erste Treiber in VB, den ich in meinem Leben sehe. Danke, daß ich das noch erleben darf - ich wußte garnicht, daß die VB-Runtimes auch im K-Mode arbeiten.

Zitat:

Zitat von Sprint

PS: Für mich bist du aber der "Schlaumeier des Tages".

Das ist lieb von dir. :love:

Zitat:

Zitat von Sprint

CreateProcess
DEBUG_PROCESS
WaitForDebugEvent

Coole Methode.

Komisch, dann war ich wohl der einzige dumme Schlaumeier des Tages, der in der Fragestellung komischerweise genau das verstanden hat, was in ihr stand. Wie dumm von mir ...

Delphi Star schrieb (Hervorhebung Mephisto):

Wie kann man den OutputDebugString überwachen, so wie bei diesem Tool von Sysinternals :?:

Irgendwie muß ich den Punkt überlesen haben, wo er sagte, er wolle von einem Prozess den er debuggt die Ausgaben von OutputDebugString() überwachen. Es muß doch mit dem Teufel (sic!) zugegangen sein, daß ich die unsichtbare Zaubertinte übersah.

Ich bitte also untertänigst um Vergebung und werde mich sogleich aus diesem Thread entfernen.

[Delphi Star]

Delphi-Quellcode:

if WaitForDebugEvent(OUTPUT_DEBUG_STRING_EVENT,INFINITE)=true then
showmessage('test');

Was ist daran falsch :?:

[Mephistopheles]

Zitat:

Zitat von Delphi Star

Delphi-Quellcode:

if WaitForDebugEvent(OUTPUT_DEBUG_STRING_EVENT,INFINITE)=true then
showmessage('test');

Was ist daran falsch :?:

Keine Ahnung. Probier es aus, ob es klappt. Allerdings sagt die Doku zu dieser API eindeutig:

Im Platform SDK steht:

The WaitForDebugEvent function waits for a debugging event to occur in a process being debugged.

Ich entnehme dem, daß ich den Prozess vorher als Debugger unter meine Knute zwingen muß.

(Speziell an w3seek:)
Ich habe mir soeben mal die Implementation von Windows 2000's kernel32!OutputDebugString() angeschaut. Dabei ist mir aufgefallen, daß theoretisch auch wenn der Prozess nicht debuggt wird dieser String in eine MMF geschrieben wird. Zusätzlich werden 2 Ereignisse geöffnet und mglw. signalisiert. Und mit einem Mutex wird der Zugriff auf die MMF gesperrt (dieser scheint intern der Kernel32 zu gehören - zumindest kennt die Kernel32 sein Handle und öffnet ihn nicht explizit innerhalb der Funktion).

Die MMF heißt: "DBWIN_BUFFER"
Die Ereignisse heißen: "DBWIN_DATA_READY" und "DBWIN_BUFFER_READY"

Wie kompatibel (mit Windows 9x) und vorigen/späteren NT-Versionen ein solches Vorgehen ist, bleibt dahingestellt. Wenn eine tiefere Analyse erwünscht ist, kann ich die u.U. noch nachliefern. Aber auch kernel32!OutputDebugString() ruft ntdll!DbgPrint() auf, welches wiederum ntdll!DebugPrint() aufruft, welches wiederum ntdll!DebugService() aufruft, welches den Aufruf über SYSENTER bzw. INT 2Eh über die SSDT in den Kernelmode weiterleitet. Da ich keine Zeit habe, kann ich die auch nicht sagen, wie der Service-Index auf eine Kernelmodefunktion mappt. Zumindest gleicht sich der Code o.g. Funktionsaufrufe im Kernel- und im Usermode wie ein Ei dem anderen (NTOSKRNL.EXE vs. NTDLL.DLL).

PS: Das alles war ein sehr oberflächliches Anschauen des Codes. Könnte also Fehler in der Beschreibung enthalten.