SetWindowsHookEx не внедряет DLL

Question

SetWindowsHookEx не внедряет DLL

0

Все, что я пытаюсь сделать, это загрузить мою DLL в некоторые другие программы (во время создания процесса) и заставить ее выполнить функцию DllMain. К сожалению, независимо от того, какой код я пытаюсь, он никогда не работает.

Например, у меня есть этот код: http://pastebin.com/P4NzLb3X В основном, это просто использование SetWindowsHookEx для установки клавиатуры. Однако проверка с помощью процесса Hacker показывает мне, что DLL никогда не вводится в какой-либо процесс. :(

Я искал уже целый день для решения. Как я могу это решить?

Smaug 23 авг. 2014, в 18:47

Источник

1

Ваш код пишет сообщения о состоянии. Какое сообщение вы видите?
Logicrat 23 авг. 2014, в 15:54
0

@Logicrat Эти: ссылка (т.е. все успешно)
Smaug 23 авг. 2014, в 16:03
0

Хорошие отрицательные причины без причины, но может ли кто-то ответить на этот довольно важный вопрос ?!
Smaug 23 авг. 2014, в 18:14
0

Я бы посоветовал вам написать некоторые сообщения о состоянии изнутри вашей DLL, чтобы вы могли определить, насколько далеко зашло выполнение внутри DLL / либо того, либо использовать отладчик для перехода по коду DLL.
Logicrat 23 авг. 2014, в 18:44
0

Я сделал, но, как я писал выше, DLL не загружается, вложение никогда не выполняется (кроме как во время LoadLibrary внутри программы, которая внедряет хук), и программное обеспечение мониторинга процесса подтверждает, что DLL никогда не будет применена ни к какому процессу ,
Smaug 23 авг. 2014, в 19:00
3

Инжекция не происходит, пока вы не сфокусируете внимание на программе с графическим интерфейсом той же битности, а затем нажмете клавишу.
Raymond Chen 23 авг. 2014, в 19:52
0

Спасибо, я этого не знал! К сожалению, всякий раз, когда я нажимаю кнопку в такой программе, программа зависает, пока я не разгрузлю свой хук. И метод Hook, и функция DllMain никогда не выполняются. pastebin.com/5kXmzu9C
Smaug 23 авг. 2014, в 20:40
1

Если программа зависает, явно что-то происходит. Используйте Process Monitor (доступный на веб-сайте MS), чтобы проверить, загружается ли DLL или нет, или лучше использовать отладчик, чтобы увидеть, что именно происходит. Вы можете избежать поломки вашего отладчика, подключив только определенный поток или поместив отлаживаемую программу (и программу подключения) на отдельный рабочий стол; перехватить конкретный поток будет проще.
Harry Johnston 24 авг. 2014, в 01:57
0

Это замерзает , потому что вы делаете слишком много работы в функции DllMain. Вы не можете вызвать все эти функции. Не забудьте прочитать документацию
Cody Gray♦ 24 авг. 2014, в 07:33
0

Я использовал Process Monitor и могу подтвердить, что DLL НЕ загружается. Снижение DllMain до «return TRUE»; не влияет на результат.
Smaug 24 авг. 2014, в 08:32
0

Я решил это. :)
Smaug 24 авг. 2014, в 09:31

Показать ещё 9 комментариев

Теги:

c++

dll

windows

hook

inject

1 ответ

Ещё вопросы

Ваш код пишет сообщения о состоянии. Какое сообщение вы видите?
@Logicrat Эти: ссылка (т.е. все успешно)
Хорошие отрицательные причины без причины, но может ли кто-то ответить на этот довольно важный вопрос ?!
Я бы посоветовал вам написать некоторые сообщения о состоянии изнутри вашей DLL, чтобы вы могли определить, насколько далеко зашло выполнение внутри DLL / либо того, либо использовать отладчик для перехода по коду DLL.
Я сделал, но, как я писал выше, DLL не загружается, вложение никогда не выполняется (кроме как во время LoadLibrary внутри программы, которая внедряет хук), и программное обеспечение мониторинга процесса подтверждает, что DLL никогда не будет применена ни к какому процессу ,
Инжекция не происходит, пока вы не сфокусируете внимание на программе с графическим интерфейсом той же битности, а затем нажмете клавишу.
Спасибо, я этого не знал! К сожалению, всякий раз, когда я нажимаю кнопку в такой программе, программа зависает, пока я не разгрузлю свой хук. И метод Hook, и функция DllMain никогда не выполняются. pastebin.com/5kXmzu9C
Если программа зависает, явно что-то происходит. Используйте Process Monitor (доступный на веб-сайте MS), чтобы проверить, загружается ли DLL или нет, или лучше использовать отладчик, чтобы увидеть, что именно происходит. Вы можете избежать поломки вашего отладчика, подключив только определенный поток или поместив отлаживаемую программу (и программу подключения) на отдельный рабочий стол; перехватить конкретный поток будет проще.
Это замерзает , потому что вы делаете слишком много работы в функции DllMain. Вы не можете вызвать все эти функции. Не забудьте прочитать документацию
Я использовал Process Monitor и могу подтвердить, что DLL НЕ загружается. Снижение DllMain до «return TRUE»; не влияет на результат.

Smaug · Accepted Answer · 2014-08-24T08-36-00.000Z

Я решил проблему с помощью этих двух ссылок:

http://www.gamedev.net/topic/568401-problem-with-loading-dll--setwindowshookex/

Глобальный Keyhook на 64-битной Windows

Должно быть исправлено 3 вещи:

Добавьте файл.def для DLL и используйте там экспорт, поскольку Visual Studio, очевидно, любит делать странное имя с помощью extern "C" __declspec(dllexport) int - это исправляет загрузку DLL в 32-битных процессах
Добавить атрибут CALLBACK в функцию (extern "C" int CALLBACK meconnect(...)) - это исправление сбоя, которое происходит при 32-битных процессах после исправления выше.

Добавьте цикл сообщения в хост-процесс (процесс, вызывающий функцию SetWindowsHookEx) следующим образом:

MSG msg;
while(1) {
    // Keep pumping...
    PeekMessage(&msg, nullptr, 0, 0, PM_REMOVE);
    TranslateMessage(&msg);
    DispatchMessage(&msg);
    Sleep(10);
    SHORT v = GetKeyState(VK_RETURN);
    bool pressed = (v & 0x8000) != 0;
    if(pressed) 
        break;
}

это фиксирует замораживание в 64-битных процессах.

Обратите внимание, что первая проблема должна была быть обнаружена вашим кодом, так как он проверяет NULL возвращаемый GetProcAddress . Почему ты не упомянул это? Обратите внимание, что первые две проблемы не были в коде, который вы опубликовали.
Первая проблема не была обнаружена моим кодом. Я не могу объяснить, почему, поскольку я сам не знаю, я предполагаю, что это ошибка где-то в Visual Studio. Что касается исходного кода, я предоставил исходный код для DLL в комментариях к OP, так как не верил, что это связано с проблемой (поскольку в соответствии с различными мониторами процессов DLL никогда не открывались, я наивно полагал, что материал DLL никогда не исполнялся). Я просто пропустил, что может быть проблема с экспортом функций.
Я сомневаюсь, что вы нашли ошибку в Visual Studio
Хорошо, тогда это просто странное поведение в Visual Studio. Это, однако, явно не работает хорошо. Очевидно, что некоторые модули подходят для работы с декорированными функциями, в то время как более глубокий или более поздний модуль говорит «нет». Я могу воспроизвести эту проблему очень хорошо. Если вы не поместите экспорт в .def и вместо этого добавите к своей функции атрибут __declspec (dllexport), результатом будет «украшенная функция C», которая (im) будет (im) должным образом распознана / разрешена GetProcAddress, но, очевидно, не фактической инъекционной функцией (хотя эта функция даже не должна знать об этом имени ...).