hwbp/ntdll-unhookKorrektes Unhooking der ntdll .text-Sektion über die native API. Anders als andere Unhooker bleiben hierbei keine zwei ntdlls geladen. x86/x64/wow64 werden unterstützt.
Sauberes Unhooking der .text-Sektion von ntdll über die native API. x86/x64/wow64 unterstützt.
Das Programm durchläuft den PEB, um die Basisadresse von ntdll.dll zu lokalisieren, und parst manuell die PE-Exporttabelle, um NT-API-Funktionen aufzulösen, ohne die Import Address Table zu berühren. Anschließend wird mit NtOpenFile die saubere ntdll.dll von der Festplatte geöffnet, mit NtCreateSection ein Section-Objekt erstellt und mit NtMapViewOfSection in den Prozess gemappt, um eine Unhook-Quelle zu erhalten, ohne tatsächlich eine zweite DLL per LoadLibrary zu laden. Die gehookte .text-Sektion wird per NtProtectVirtualMemory auf PAGE_EXECUTE_READWRITE geändert, der saubere .text wird mit einem eigenen memcpy über den gehookten kopiert, und anschließend wird der Schutz auf die ursprünglichen Flags zurückgesetzt. Nach einer byteweisen Verifikation, dass das Unhooking funktioniert hat, wird die saubere Kopie ordnungsgemäß mit NtUnmapViewOfSection wieder unmapped, sodass keine zweite ntdll im Speicher geladen bleibt.
Der meiste öffentliche Unhook-Code ist buchstäblich von derselben Müllquelle kopiert (wie dem ired.team-Beispiel und praktisch jedem Open-Source-Unhooker auf GitHub) und hat massive Probleme, die ihn gegen jedes echte EDR nutzlos machen. Sie verwenden VirtualProtect statt nativer APIs, was den ganzen Zweck zunichtemacht, da man gehookte Funktionen aufruft, um Funktionen zu unhooken. Sie setzen RWX-Berechtigungen auf die .text-Sektion, was ein massiver IOC ist, den EDRs sofort flaggen. Und sie unmappen die saubere Kopie nicht wirklich, weil CloseHandle auf ein Section-Mapping den Speicher nicht freigibt. Man braucht UnmapViewOfFile oder NtUnmapViewOfSection, aber jeder vergisst diesen Teil, sodass zwei Kopien von ntdll im Prozess geladen bleiben – im Grunde ein riesiges Neonschild mit der Aufschrift „ich bin Malware“. Sie versuchen außerdem, FreeLibrary auf die Haupt-ntdll anzuwenden, was nicht einmal funktioniert und Handle-Leaks verursacht. Dazu ändern sie den Schutz unnötigerweise zweimal auf RWX, obwohl einmal reicht, wenn man ihn ordentlich zurücksetzt.
Diese Implementierung behebt die häufigen Bugs im öffentlichen Unhook-Code, indem sie durchgehend native APIs verwendet (NtOpenFile, NtCreateSection, NtMapViewOfSection, NtProtectVirtualMemory), die saubere Kopie ordnungsgemäß mit NtUnmapViewOfSection unmappt, um zu vermeiden, dass zwei ntdll-Kopien geladen bleiben, kein FreeLibrary auf die Haupt-ntdll anwendet und den Erfolg per Speichervergleich verifiziert. Sie vermeidet jedoch NICHT die grundlegenden IOCs, die moderne EDRs erkennen. Die Verwendung von NtOpenFile auf C:\Windows\System32\ntdll.dll ist ein IOC, das protokolliert wird. NtCreateSection mit SEC_IMAGE, das auf ntdll.dll zeigt, wird über ETW getrackt. Das Ändern des Speicherschutzes auf der .text-Sektion von ntdll ist selbst mit nativen APIs eine riesige rote Flagge, und das Schreiben in .text ist über Memory-Write-Callbacks erkennbar. Diese Technik ist allgemein bekannt, und moderne EDRs wie CrowdStrike und SentinelOne haben Signaturen für das gesamte Muster. Fortschrittliche EDRs wie Microsoft Defender for Endpoint und Elastic verwenden ohnehin keine Usermode-Hooks mehr, da sie auf Kernel-Callbacks und ETW-Telemetrie setzen – Unhooking bewirkt gegen sie also praktisch nichts. Das funktioniert gegen einfache EDRs, die nur Inline-Hooks verwenden, und gegen ältere Sicherheitsprodukte, scheitert aber an allem mit Kernelmode-Komponenten oder Verhaltensanalyse. Bessere Alternativen sind direkte Syscalls, bei denen man gehookte Funktionen von vornherein nie aufruft, Heaven's Gate für die wow64-Grenze, manuelle Syscall-Extraktion aus dem ntdll-.text zur Laufzeit oder einfach das Vermeiden verdächtiger APIs ganz allgemein, da Unhooking 2024/2025 gegen echte Enterprise-EDRs im Grunde eine tote Technik ist.
Funktioniert mit nativen x64-Prozessen, nativen x86-Prozessen und wow64-Prozessen (x86 auf Windows x64). Er erkennt wow64 automatisch und verwendet das korrekte Systemverzeichnis (System32 vs. SysWOW64), sodass man sich nicht darum kümmern muss.
Nur die .text-Sektion von ntdll.dll wird angefasst, weil dort der gesamte tatsächliche Funktionscode liegt und dort EDR-Hooks als Inline-Funktionshooks (jmp-Anweisungen an Funktionsprologen) platziert werden. Andere Sektionen wie .data und .rdata bleiben unberührt, weil es keinen Grund gibt, sie anzufassen, und es nur mehr IOCs ohne Nutzen erzeugt.
cl /EHsc /std:c++17 main.cpp /Fe:unhook.exe
oder was auch immer, jeder moderne C++-Compiler funktioniert. Benötigt windows.h und winternl.h.
Unbefugter Zugriff auf Computersysteme ist illegal. Nur auf Systemen verwenden, die einem gehören oder für die man eine Testgenehmigung hat. Das Bundesgefängnis ist real.
Der Code verwendet das CONTAINING_RECORD-Makro, um LDR-Listen korrekt zu durchlaufen, greift über Segmentregister auf den PEB zu (gs auf x64, fs auf x86), führt eine hartkodierte .text-Sektionssuche über Namensvergleich durch, was eleganter sein könnte, aber egal, es funktioniert. Fehler werden über NTSTATUS-Codes und das NT_SUCCESS-Makro behandelt, und Speicheroperationen sind zur Sicherheit in SEH try/except gekapselt. Wenn man kein C++ lesen und das PE-Format nicht intern verstehen kann, sollte man das ohnehin nicht verwenden.