хук DLL не обновляет callstack правильно при возврате - PullRequest
0 голосов
/ 18 марта 2020

Я слежу за процессом создания батута, чтобы подключить функцию dll (в моем случае Direct3DCreate9 из d3d9.dll), как описано здесь: https://www.malwaretech.com/2015/01/inline-hooking-for-programmers-part-1.html и https://www.malwaretech.com/2015/01/inline-hooking-for-programmers-part-2.html

Мой код немного отличается, так как я обрабатываю смещенные байты вручную, используя дизассемблер, а не функцию hde32_disasm.

Кажется, все работает нормально, процесс жертвы вызывает мою введенную dll Функция-обертка, новая функция выполняет некоторые вещи, затем вызывает исходную функцию (Direct3DCreate9), как только оригинал возвращает, оболочка должна затем вызывать некоторые другие вещи, прежде чем вернуться к процессу жертвы.

К сожалению, когда исходная функция вызывается из обработчика ловушек, он возвращает обратно в приложение-жертву, а не упаковщик подключений, это означает, что он пропускает часть кода из упаковщика.

Пройдя через разборку, он выглядит так, как будто стек вызовов перезаписывается, поэтому, когда Direct3DCreate9 возвращает его р возвращается к приложению жертвы вместо моей функции перехвата, которая сделала вызов.

Я полагаю, мне нужно вручную sh перехватить функцию перехвата в стек вызовов? Как бы я go об этом?

Другая потенциально важная информация: и процесс жертвы, и ловушка были встроены в режиме отладки. Direct3DCreate9 является __stdcall, и я использую vs2010 для подключения DLL, но процесс жертвы был скомпилирован с vs2015.

1 Ответ

0 голосов
/ 25 марта 2020

Оказывается, что стек вызовов был заблокирован графическим драйвером NVidia nvd3d9wrap.dll. Эта dll внедрялась в приложение d3d9 так же, как я пытался это сделать. Это привело к безумию, объясненному в оригинальном сообщении.

Решением было открыть диспетчер устройств в windows и отключить графический драйвер NVidia. К счастью, мой p c имеет встроенный графический чип, так что я могу его использовать.

...