Bedingten Haltepunkt für alle vom Modul aufgerufenen Funktionen setzen? (WINDBG x64)

Question

Was ich tun möchte, ist, einen bedingten Haltepunkt für alle Funktionen in Nt, die von dem angegebenen Modul aufgerufen werden.

Mein Ziel dabei ist es, den Callstack jedes Mal zu schreiben, wenn das X-Modul die x nt-Funktion aufruft, um so zu erkennen, was in dem verschleierten Code vor sich geht.

Nach dem Einbruch am Eintrittspunkt, setze ich einen Haltepunkt auf X nt-Funktion. Nach meinem Haltepunkt wieder aufzunehmen getroffen wird, und die Aufrufliste sieht so etwas wie

nt! Funktion

moduleIspecified! 0x123

....

Meine Idee war dann, dass ich diese verwenden könnte zu schreiben ein Code für einen bedingten Breakpoint, etwa wie folgt: "Wenn der Aufrufer ein x-Modul ist und das Modul eine Funktion in y-Modul aufruft, DANN, log-Callstack.".

Es ist erwähnenswert, dass Watch und Trace im x64 Kernel-Modus nicht unterstützt wird. Es ist auch erwähnenswert, dass ich diesen Ansatz gewählt habe, dass ich diesen Ansatz verwende, weil ich nicht in der Lage war, die Aufrufe zu bestimmen, indem ich sie statisch analysiere, und eine Analyse durch Schrittweise auch nicht möglich ist.

Und auch: wäre es ein besser/idealer Ansatz, um dies zu erreichen?

Grüße

Answer 1

Sie können, dass genau das nicht tun, aber es gibt ein paar Alternativen, die Sie sich anschauen sollten.

Zuerst - warum nicht einfach Sysinternals' Process Monitor oder vielleicht Rohitab's API Monitor verwenden?

Wenn Sie auf eigene Faust arbeiten, sind die ersten Probleme, denen Sie gegenüberstehen, dass die Anzahl der Breakpoints, die der Kernel-Debugger setzen kann, gering ist (32 ist die letzte Nummer, an die ich mich erinnere). Diese Einschränkung ist nicht auf den Host WinDbg/kd, sondern auf die Kernel-Debugger-Komponente auf dem Zielcomputer zurückzuführen. Sie können dies in der WRK sehen. Aber selbst wenn Sie könnten, wäre es enorm langsam.

Die erste Alternative Sie haben, ist, sondern ein Haltepunkt in der syscall/sysenter Routine (nt!KiFastCallEntry, nt!KisystemCall64, oder was auch immer es heute ist), und es setzen Sie Ihre Befehle. Wie gesagt, es wird extrem langsam sein. Sie können es gerne selbst ausprobieren, wenn Sie mir nicht glauben (auch ohne den cleveren Zustand, setzen Sie einfach einen Befehl dorthin, auch nur einen einfachen gc, nicht zu sprechen von .echo ...).

Die zweite Alternative, die ich mir vorstellen kann, ist das Schreiben eines Treibers, der die Systemaufrufe anhängt, an denen Sie interessiert sind (oder die syscall Routine). Dies erspart Ihnen den Roundtrip zwischen Host- und Zielrechner. Beachten Sie, dass Sie noch einen Debugger anhängen müssen, um KPP (PatchGuard) zu deaktivieren oder einen 32-Bit-Computer zu verwenden. Und es ist wahrscheinlich komplizierter als die Verwendung von ProcMon, API Monitor oder vielleicht xperf/WPT.

Ich würde vorschlagen, die einfachen und offensichtlichen Dinge (ProcMon/API Monitor) zu verwenden, bevor Sie sich für die übermäßig komplizierten.