Вопрос такой: Делаю перехватчик API функций в заданной программе. Запускаю исследуемый процесс функцией CreateProcess с флагами CREATE_NEW_CONSOLE or CREATE_SUSPENDED. Потом с помощью функции CreateRemoteThread внедряю свою dll для перехвата Api. Потом с помощью ResumeThread запускаю иследуюмый процесс. Но вызов фунции DllMain моей dll стартует после вызова функции DllMain всех статических dll определенных в иследуемом процессе, в результате чего приложение может противодействовать перехвату заранее на этапе загрузки определив точки входа перехватываемых функций, а также возможно и начальный фрагмент кода входа в функции. Есть ли мысли как обойти данное ограничение? Заранее благодарен за ответы.
Не получиться, так как выполнение кода в DllMain статических Dll происходит в системном потоке, сразу после его создания даже в случае наличия флага CREATE_SUSPENDED. Так что мой поток будет запущен примерно одновременно с системным и не факт что успеет установить перехват раньше, так как уйдет время на выделение памяти, побайтное копирование образа+настройка импорта и т.д.
Goldy Проверил, действительно - сразу после создания процесса с флагом CREATE_SUSPENDED в него не загружена ни одна DLL, но стоит вызвать CreateRemoteThread (неважно, для инжекта DLL, или вызова чистого кода), как система грузит весь импорт проги. Так что на CreateRemoteThread придется тоже забить. Пока я вижу такой (хотя и довольно сложный выход): запустить процесс с флагом DEBUG_PROCESS вместо CREATE_SUSPENDED, записать в него свой код (в том числе и перехватчики), потом ловить отладочное событие LOAD_DLL_DEBUG_EVENT, и при загрузке ntdll.dll и kernel32.dll (они грузятся первыми) править в них нужные байты (тебе ведь в них нужно функции перехватывать?). Такой способ гарантирует, что функции из ntdll.dll и kernel32.dll будут перехвачены до вызова DllMain "враждебных" тебе DLL. На более раннем этапе ты не сможешь перехватить нужные функции - нет DLL, нечего и перехватывать.
Спасибо. Попробую это вариант. Правда тогда IsDebugggerPresent скрывать прийдется, но это мелочь Правда у проги могут быть другие способы определения работы под отладчиком и возможности напакостить. Может будут еще варианты?
Goldy советую посмотреть как Armadillo запускает второй процесс, юзай GetThreadContext/SetThreadContext, т.е. копируешь свой код в адресное пространство процесса, потом манипуляции с контекстом
Goldy Вызови DebugActiveProcessStop после установки перехватов (WinXP & 2003 only). Asterix SetThreadContext можно использовать, чтобы при ResumeThread вызвался твой код. Но дело в том, что при вызове ResumeThread для этого потока система все равно сначала (в этом я не уверен - надо проверить) загрузит все длл-ки из импорта, если они еще не загружены. Хотя, они будут загружаться этим самым потоком (контекстом которого можно управлять), так что может получиться. В общем, надо просто попробовать.
я упустил условия задачи, если перехватчик собирается перехватывать функции в импорте exe то ему нет необходимости следить за dll'ками, если планируется перехватывать через таблицу экспорта то тогда действительно лучше использовать Debug API
Пральна, если длл ещё не промаплены, или рл крайней мере не прописаны в PEB, кто будет обрабатывать функции твоей DLL ? тут только установка контекста первичного потока в определённый момент.
Какие есть еще способы обнаружения того что процесс запущен под отладчиком кроме IsDebugPresent в случае его пассивной работы (Сброшен флаг трассировки,нет точек останова)? Насколько сильно затормозится исполнение отлаживаемого процесса, так как судя по всему скорость критична для данного приложения?
