Нужен пользовательский поток, чтобы в его контексте исполнять код(и апк доставлять тоже). Можно попробовать потыкать UserpActivateDebugger (чтобы вручную не ковыряться в ядре, разбирая сст). Код (Text): Port = ObReferenceObjectByName("\Windows\ApiPort") ; or EPROCESS.ExceptionPort LpcRequestWaitReplyPort(Port, UserpActivateDebugger) ; ACTIVATEDEBUGGERMSG{} Тока в версиях номер сервиса меняется на 1 и структура сообщения изменялась, но это не проблема.
expert А что там такого, наверно как обычно - парсим сст, находим NtCreateThread() etc. Это унылые древние методы. Ну явно эти малвари не трассируют юзермодный код, не используют интеграцию етц. Уровень ксакепа в общем.
создал проект dll библиотеку , проект собирается, но после инжекта, dll не отрабатывает, не выводит сообщение в DbgView с помощью DbgPrint. содержимое файла sources: TARGETNAME= inject TARGETTYPE= DYNLINK TARGETPATH= obj INCLUDES= $(DDK_INC_PATH) DLLENTRY= DllMain SOURCES= inject.cpp BUFFER_OVERFLOW_CHECKS= 0 USE_NTDLL= 1 TARGETLIBS= $(SDK_LIB_PATH)\kernel32.lib \ $(DDK_LIB_PATH)\ntoskrnl.lib ---------------------------------------------------------------- #include <ntifs.h> #include <windef.h> BOOL WINAPI DllMain( HINSTANCE DllInstance, DWORD Reason, LPVOID Reserved ) { DbgPrint("Hello World!"); return TRUE; }
возможно, программа не находит точку входа в dll, но она указана: DLLENTRY= DllMain неправильные заголовок у функции ?
У тебя при сборке модуля пользовательского режима используются такие вещи, как DbgPrint() $(DDK_INC_PATH) #include <ntifs.h> $(DDK_LIB_PATH)\ntoskrnl.lib Тебе не кажется это подозрительным? И, наконец, почему бы .dll не собирать в VS?
Я даже и не пытался, мне ни к чему. Я вообще dkkbuild не пользуюсь, драйвера собираю build обычным из консоли, а пользовательские модули пишу в VS и собираю там же без каких-либо сторонних инструментов.
а собирать dll с использованием ntifs.h не пробовали? я могу использовать в dll функции windows.h и ntifs.h ?