mandiant/straceEin DTrace auf Windows Reimplementation
Steves Tracer. Eine DTrace-Neuimplementierung von Syscall-Hooks unter Windows. Stellen Sie sich das wie einen PatchGuard-kompatiblen SSDT-Hook vor, jedoch ohne Hacks. SSSDT (win32k-APIs) wird nicht unterstützt, da die DTrace-Systemaufruf-APIs selbst diese zusätzliche Tabelle nicht unterstützen. Zw*-Kernel-APIs können zusätzlich zu allen Usermode-SSDT-Syscalls verfolgt werden.
Bitte lesen Sie diese README bis zum Ende, wenn Sie neue Plugins für STrace entwickeln!
DTrace unter Windows unterstützt mehrere Probe-Typen. Dazu gehören syscall, fbt, etw, profile und möglicherweise weitere. Diese Neuimplementierung implementiert nur die Probe-Typen syscall und etw neu. Alle anderen Probe-Typen gelten als vollständig außerhalb des Umfangs dieses Projekts und werden niemals unterstützt. Bitte forken Sie das Projekt, wenn Sie zusätzliche Probe-Typen hinzufügen möchten. Der Umfang wurde aufgrund der Komplexität der anderen Probe-Typen und der von ihnen berührten Systeme auf nur syscall- und etw-Probes beschränkt.
Diese Neuimplementierung verwirft die D-Skriptsprache vollständig (Hinweis: NICHT DLang, die populärere moderne Sprache). Die Komplexität einer VM im Kernel wie in der ursprünglichen DTrace-Implementierung ist für dieses Projekt ungeeignet. Stattdessen setzt diese Implementierung direkt die relevanten C-Callbacks frei, die erforderlich sind, um in die DTrace-Windows-Kernel-Schnittstellen einzustecken. Um das 'Hot-Loading' von Skripten zu ermöglichen, wurde ein DLL-basiertes Plugin-System als Ersatz für die VM- und Skriptumgebung des ursprünglichen DTrace verwendet. Dieses Plugin-System akzeptiert eine 'normale' Usermode-DLL ohne aktivierte Sicherheitsprüfungen oder sonstige externe Abhängigkeiten und mappt sie manuell in den Kernel-Adressraum. Die Plugin-DLL verfügt über Exports, die beim Auftreten von Kernel-Syscall-Callbacks aufgerufen werden. Kernel-APIs werden über die normale Importtabelle (IAT) der DLL aufgelöst; Plugin-DLLs linken gegen ntoskrnl.lib, und der Treiber löst diese APIs zur Ladezeit auf, sodass innerhalb von Plugin-DLLs wie gewohnt beliebige System-APIs aufgerufen werden können. Die Leistung dieses Plugin-Systems ist ausgezeichnet, da nativer Code – statt eines Skript-Interpreters oder eines JIT – direkt zwischen Syscall-ENTRY und -RETURN ausgeführt wird. Dieses Design verbessert die Leistung im Vergleich zu der von Microsoft bereitgestellten DTrace-Implementierung.
Das Setzen von Hooks ist sehr einfach: Sie erhalten eine Routine zum Registrieren/Deregistrieren eines Hooks per API-Namen, mit einem Pre- und Post-Syscall-Callback. Callbacks besitzen Argumente und Rückgabewerte, die als reine Lesewerte zugänglich sind. Rückgabewerte können in Return-Probes gefälscht und Argumente in Entry-Probes modifiziert werden, aber der ursprüngliche Syscall kann normalerweise keinen Syscall ersetzen oder 'abbrechen' – diese API agiert als Beobachter. Es existiert jedoch ein Versehen, ähnlich dem in (https://github.com/everdox/InfinityHook und https://github.com/everdox/InfinityHook/raw/master/resources/perf.png) dokumentierten, das es erlaubt, den Syscall-Zeiger auf dem Stack zu ersetzen. Mit diesem Versehen ist es möglich, einen Syscall vollständig durch einen Zeiger auf eine Routine zu ersetzen, die Sie stattdessen kontrollieren. Wenn Ereignisse auftreten und Ihr Hook-Callback ausgelöst wird, kann getan werden, was auch immer Sie möchten. Callbacks sind synchron, das heißt, wenn Sie die Ausführung im Entry-Callback verzögern, etwa indem Sie in einer While-Schleife verharren, wird der Syscall-Aufruf um genau diesen Zeitraum verzögert. Die Ausführung des Systemaufrufs erfolgt unmittelbar nach der Rückkehr aus dem Entry-Callback und unmittelbar vor dem Eintritt in den Return-Callback. Dieses System ist vollständig PatchGuard-kompatibel; DSE muss jedoch deaktiviert sein, da Microsoft diese Art von Kernel-Erweiterung leider als Teil des NT-Kernels betrachtet und daher validiert, dass der Stammzertifikatsaussteller Windows ist. Dies funktioniert nicht mit Tricks wie dem Aktivieren benutzerdefinierter Kernel-Signer; DSE muss wirklich während des Kernel-Starts deaktiviert sein.
ValidationFlags=IMGP_LATEST_MS_ROOT_REQUIRED | IMGP_WINDOWS_ROOT_REQUIRED | IMGP_MS_SIGNATURE_REQUIRED
Scenario=ImgSigningScenarioWindows
Der Rust-Treiber verwirft das DLL-basierte Plugin-System des C++-Treibers und versucht stattdessen, einen WebAssembly-Interpreter zu verwenden, um wasm-Skripte im Windows-Kernel zu hosten. Dies soll der ursprünglichen DTrace-Implementierung, die eine VM verwendet, ähnlicher sein, jedoch mit einer besseren Sprache als DLang. Dies bietet Sandboxing und andere schöne Vorteile. Der POC ist vollständig und funktioniert, ist aber aufgrund von Leistungsproblemen bei der Interpretation von WASM mit WASMI leider nicht nutzbar. Für dieses alternative Design wäre eine NT-kernel-kompatible JIT-basierte wasm-Engine erforderlich. Es ist als nette Spielerei enthalten und könnte mit etwas Arbeit für etwas anderes nutzbar sein.
Dieses Projekt ist im Wesentlichen in seine C++- und Rust-Komponenten aufgeteilt. Der C-Treiber ist funktional vollständig und sollte bevorzugt werden. Auf hoher Ebene hat das Projekt die folgenden Komponenten:
Visual Studio mit DDK einrichten
Erstellen Sie den Treiber und die CLI, verschieben Sie die Dateien in denselben Ordner wie das Skript, und führen Sie dann das PowerShell-Skript im Installationsordner als Administrator aus:
./install_as_admin.ps1
Starten Sie neu, wählen Sie dann den STrace-Booteintrag und drücken Sie auf diesem Bildschirm F8 (nicht Enter!):
Das sollte diesen Bildschirm aufrufen; wählen Sie den Start mit deaktiviertem DSE:
Nach erfolgreichem Start kann die CLI verwendet werden, um Plugin-DLLs zu laden und zu entladen und mit dem Tracing zu beginnen. Zwei Beispiel-Plugins werden mitgeliefert. Lesen Sie die Details unten genau, wenn Sie auf Probleme stoßen. Beim ersten Mal müssen Sie möglicherweise erneut neu starten und den STrace-Dienst gegebenenfalls manuell auf Autostart beim Booten setzen, z. B. mit einem Tool wie Process Hacker.
Die ursprüngliche DTrace-Installation finden Sie hier: https://techcommunity.microsoft.com/t5/windows-kernel-internals/dtrace-on-windows-20h1-updates/ba-p/1127929. Das ursprüngliche DTrace erfordert die Konfiguration von Secure Boot und Virtualized Based Security. Bei STrace ist dies nicht der Fall, da es die Probe-Typen (FBT), die diese Funktionen erfordern, nicht implementiert.