Re: [WinAPI]Проблема
А в чем проблема-то, собственно?
google "dll injection"
Хотя если ты ставишь вопрос "как узнать те места памяти, где он лежит", то, вероятно, тебе нужно начинать с какого-нибудь мануаля про виртуальную память.
Хотя если ты ставишь вопрос "как узнать те места памяти, где он лежит", то, вероятно, тебе нужно начинать с какого-нибудь мануаля про виртуальную память.
собственно?Какая функция-то нужна?
И мануалы я вроде бы уже прочита про все.
Если брать задачу в лоб, то читать надо _очень_ много. Одной функцией не обойдешься, это гарантированно. Сверху тебе уже посоветовали, где.
Нельзя в свой процесс загрузить ехе файл.
Почему? Что тут страшного (только один, причем больше ничего не нужно)?
При том, что этого просто нельзя сделать. Тут один грамотный человек порекомендовал попробовать загрузить пустой exe с заглушечной dll. Внутри dll заменить содержимое заглушечного exe на нужное содержимое и вызвать точку входа в exe.
> google "dll injection"
проще через ReadProcessMemory/WriteProcessMemory
проще через ReadProcessMemory/WriteProcessMemory
У него задача не просто лазить в памяти другого процесса. Ему ещё SEH'и ловить надо. Судя по тому, что он написал в приватах.
тогда проще зацепить debug-api.
основное приложение выступает в роли отладчика, и соответственно может повеситься в том числе и на исключительные ситуации
основное приложение выступает в роли отладчика, и соответственно может повеситься в том числе и на исключительные ситуации
почему нельзя загрузить exe в свое адресное про-во?Чем экзе по сути отличается от другого бинарного файла?
У него фиксированный базовый адрес.
но ведь по сути я могу просто загрузить код команды в память и передать на нее управление и она исполнится
Код команды или нескольких - можешь. Но в программе обычно есть инструкции перехода и обращения к памяти.
тогда проще зацепить debug-api.Не понял, что ты понимаешь под Debug API. SEH'и тоже вроде как относятся к Debugging and Error Handling. В постановке задачи присутствует упоминание об отлове SEH'ов. И есть ещё требование удаления виртуальной памяти, где есть исполняемый код. Но главным всё-таки является требование наличия коммуникационного модуля и связи между этим модулем и выполняемым процессом. Именно поэтому я и предложил то, что предложил.
основное приложение выступает в роли отладчика, и соответственно может повеситься в том числе и на исключительные ситуации
ну я же не говорил, что ты просто прочтешь экзе и запустишь его на самотек.Я сказал что реально считать его к себе в пространство.Да и впринципе в своей программе ты сможешь потом пересчитать адреса и сделать все остальное необходимое.По сути это и получится отладчик.
Адреса ты не пересчитаешь.
Почему?
Есть сегмент кода по таким-то адресам, все прыжки в нем локальные, дальше сегмент данных.Тоже все известно о нем.Почему не смогу?Или exe как-то странно устроен?
Есть сегмент кода по таким-то адресам, все прыжки в нем локальные, дальше сегмент данных.Тоже все известно о нем.Почему не смогу?Или exe как-то странно устроен?
> Не понял, что ты понимаешь под Debug API
создание процесса с флагом DEBUG_PROCESS или подключение к процессу через DebugActiveProcess.
вешание на события через WaitForDebugEvent и т.д.
> Но главным всё-таки является требование наличия коммуникационного модуля и связи между этим модулем и выполняемым процессом
соответственно всю коммуникацию (передачу отладочных событий) на себя берет windows.
создание процесса с флагом DEBUG_PROCESS или подключение к процессу через DebugActiveProcess.
вешание на события через WaitForDebugEvent и т.д.
> Но главным всё-таки является требование наличия коммуникационного модуля и связи между этим модулем и выполняемым процессом
соответственно всю коммуникацию (передачу отладочных событий) на себя берет windows.
Есть сегмент кода по таким-то адресам, все прыжки в нем локальные, дальше сегмент данных.Тоже все известно о нем.Почему не смогу?Или exe как-то странно устроен?Ты никак не узнаешь где лежат адреса, которые надо изменить.
Ну ты мне это можешь не рассказывать, я это всё прочитал. И ещё написал, что требуется в задаче. И к этому требованию предложил решение.
Правильно я понимаю, что необходимо уметь: читать, писать память и вешаться на исключения?
и в целом все?
и в целом все?
Попроси у автора задачу, а? Я не могу её сюда написать, т.к. всё-таки в приват пришла. Там чётко описаны шаги, которые надо сделать. А не результат.
раз ты пользуешься инсайдерской информацией, то твое решение, наверное, более точное
Я не понял, что ты имеешь в виду?
Есть основной процесс. Запустить пустой, так? Что такое заглушечная dll? Написанная собственноручно? Зачем тогда менять, сразу нельзя через dll подключить?
Есть основной процесс. Запустить пустой, так? Что такое заглушечная dll? Написанная собственноручно? Зачем тогда менять, сразу нельзя через dll подключить?
Ты никак не узнаешь где лежат адреса, которые надо изменить.
есть сегмент кода, там все адреса относительные.Относительно адреса, в который загрузится программа.Если я ее загружаю, то я и определяю этот базовый адрес.В локальных рамках он будет нулем.Я не понимаю, что я не смогу узнать...
Я не понял, что ты имеешь в виду?Запустить пустой (заглушечный) процесс, сделать в нём LoadLibrary вызвать GetProcAddress своей функции dll, в этой функции загрузить новый exe на место старого. Затем либо в блоке __try/__except, либо установив векторный обработчик исключений вызвать точку входа в загруженный exe. Предварительно выполнив с памятью загруженного exe требуемые операции.
Есть основной процесс. Запустить пустой, так? Что такое заглушечная dll? Написанная собственноручно? Зачем тогда менять, сразу нельзя через dll подключить?
PS Вообще, если ты за все эти дни не написал существенную часть этого задания, то я думаю, что тебе стоит от него отказаться. Вот тебе замечательная ссылка, так сказать как последняя помощь. :Е
ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.WIN32COM.v10.en/memory/base/reserving_and_committing_memory.htm
раз ты пользуешься инсайдерской информацией, то твое решение, наверное, более точноеДа там какая-то странная задача. Почему именно так? Не знаю. Может быть, ради производительности? Ведь дебаггер постоянно будет дёргаться: при создании потоков, загрузках dll и т.п.
>Ты никак не узнаешь где лежат адреса, которые надо изменить.
Вообще-то, в PE-файлах может содержаться (и иногда содержится) информация для релокации.
Вообще-то, в PE-файлах может содержаться (и иногда содержится) информация для релокации.
есть сегмент кода, там все адреса относительные.Относительно адреса, в который загрузится программа.Если я ее загружаю, то я и определяю этот базовый адрес.В локальных рамках он будет нулем.Я не понимаю, что я не смогу узнать...Да, но относительные адреса будут только у jmp/call, обращения к памяти могут быть абсолютными. Так вот, если в exe нету .reloc, то ты никак не узнаешь, что именно нужно изменить. Дело в том, что у ~50% exe файлов нету секции .reloc
Вообще-то, в PE-файлах может содержаться (и иногда содержится) информация для релокации.См. выше, всё-таки мы не знаем, какой именно exe файл будет загружен. И в условиях задачи это не обговаривается.
Я так и стал делать.
Оставить комментарий
water97
Кто-нибудь знает, как можно в данный процесс запихнуть исполняемый файл и контролировать его исполнение (в смысле когда начать исполнять+узнать те места памяти, где он лежит)? Или где об этом можно почитать.