hwbp/ntdll-unhookправильное снятие хуков с секции .text библиотеки ntdll через нативный API. в отличие от других средств снятия хуков, это не оставляет загруженными 2 ntdll. поддерживается x86/x64/wow64.
правильное снятие хуков с секции .text ntdll через нативный API. Поддерживаются x86/x64/wow64.
Программа обходит PEB для поиска базового адреса ntdll.dll и вручную разбирает таблицу экспорта PE для разрешения NT API функций без обращения к Import Address Table. Затем она использует NtOpenFile для открытия чистой ntdll.dll с диска, создаёт объект секции с помощью NtCreateSection и отображает его в процесс через NtMapViewOfSection, чтобы получить источник для снятия хуков без фактической загрузки второй dll через LoadLibrary. Секция .text с хуками изменяется на PAGE_EXECUTE_READWRITE через NtProtectVirtualMemory, чистый .text копируется поверх хукованного с помощью пользовательского memcpy, затем защита восстанавливается до исходных флагов. После побайтовой проверки того, что снятие хуков сработало, чистая копия корректно отображается с помощью NtUnmapViewOfSection, чтобы в памяти не осталось второй загруженной ntdll.
Большинство публичного кода для снятия хуков буквально скопировано из одного и того же дерьмового источника (например, пример на ired.team и практически все опенсорсные анхукеры на github) и имеет огромные проблемы, которые делают их бесполезными против любого реального EDR. Они используют VirtualProtect вместо нативных API, что сводит на нет весь смысл, поскольку вы вызываете хукованные функции для снятия хуков, устанавливают права RWX на секцию .text, что является огромным IOC, который EDR мгновенно обнаруживают, и они фактически не отображают чистую копию, потому что CloseHandle на отображении секции не освобождает память. Вам нужно UnmapViewOfFile или NtUnmapViewOfSection, но все забывают об этом, поэтому они оставляют две копии ntdll загруженными в процесс, что по сути является гигантской неоновой вывеской «я малварь». Они также пытаются использовать FreeLibrary на основной ntdll, что даже не работает и вызывает утечки дескрипторов, плюс они меняют защиту на RWX дважды без необходимости, когда одного раза достаточно, если правильно её восстановить.
Эта реализация исправляет распространённые ошибки в публичном коде анхуков, используя нативные API на всём протяжении (NtOpenFile, NtCreateSection, NtMapViewOfSection, NtProtectVirtualMemory), корректно отображая чистую копию с помощью NtUnmapViewOfSection, чтобы избежать загрузки двух копий ntdll, не используя FreeLibrary на основной ntdll, и проверяя успех сравнением памяти. Однако она НЕ избегает фундаментальных IOC, которые обнаруживают современные EDR. Использование NtOpenFile на C:\Windows\System32\ntdll.dll — это IOC, который логируется, NtCreateSection с SEC_IMAGE, указывающим на ntdll.dll, отслеживается через ETW, изменение защиты памяти на секции .text ntdll — огромный красный флаг даже с нативными API, а запись в .text обнаруживается через колбэки записи в память. Эта техника широко известна, и современные EDR, такие как CrowdStrike и SentinelOne, имеют сигнатуры на весь паттерн. Продвинутые EDR, такие как Microsoft Defender for Endpoint и Elastic, вообще не используют пользовательские хуки, так как полагаются на колбэки ядра и телеметрию ETW, поэтому снятие хуков буквально ничего не делает против них. Этот метод работает против базовых EDR, которые используют только инлайн-хуки и старые продукты безопасности, но терпит неудачу против всего, что имеет компоненты уровня ядра или поведенческий анализ. Более хорошие альтернативы включают прямые системные вызовы (syscalls), где вы никогда не вызываете хукованные функции, heaven's gate для пересечения границы wow64, ручное извлечение системных вызовов из .text ntdll во время выполнения или просто избегание подозрительных API, так как снятие хуков в 2024/2025 годах в целом является мёртвой техникой против реальных корпоративных EDR.
Работает в x64 нативных процессах, x86 нативных процессах и wow64 процессах (x86 на x64 Windows). Он автоматически определяет wow64 и использует правильный системный каталог (System32 vs SysWOW64), чтобы вам не пришлось об этом думать.
Затрагивается только секция .text ntdll.dll, потому что именно там находится весь фактический код функций и где EDR размещают хуки в виде инлайн-хуков функций (инструкции jmp в прологах функций). Другие секции, такие как .data и .rdata, остаются нетронутыми, потому что нет причин их трогать, и это только создаёт дополнительные IOC без выгоды.
cl /EHsc /std:c++17 main.cpp /Fe:unhook.exe
или как угодно, любой современный компилятор C++ подойдёт. Требуются windows.h и winternl.h.
Несанкционированный доступ к компьютерным системам незаконен. Используйте только на системах, которыми вы владеете или на которые у вас есть разрешение тестировать. Федеральная тюрьма — это реально.
Код использует макрос CONTAINING_RECORD для корректного обхода списков LDR, обращается к PEB через сегментные регистры (gs на x64, fs на x86), выполняет жёстко заданный поиск секции .text по имени, что могло бы быть более элегантно, но работает, обрабатывает ошибки через коды NTSTATUS и макрос NT_SUCCESS, и оборачивает операции с памятью в SEH try/except для безопасности. Если вы не умеете читать C++ и понимать внутренности формата PE, вам, вероятно, не стоит этим пользоваться.