kernel32.dll: по тому же адресу — да (иначе не работало бы с таймаутом), загружена ли — не знаю. По идее, WaitForIdleProcess и говорит что процесс готов.
x64: А что вы мне предлагаете дебажить? Чужой процесс до внедрения длл? А если в DllMain ставить бесконечный цикл — то процесс точно так же умирает.
В общем и целом ясно (мне) что проблема в том что целевой процесс не успел толком проинициализироваться. Вот я и спросил — как отследить что процесс "up and ready"?
Здравствуйте, namux, Вы писали:
N>Возникла такая проблемка — может, кто чего посоветует. N>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает
После того как процесс создан, его выполнение начинается с ResumeThread в недрах ntdll.dll, которая настраивает всё окружение процесса в юзермоде.
В этот момент все статические импорты уже замаплены, а также безусловно замаплена ntdll.dll (и kernel32.dll в свежих версиях ОС, вроде бы начиная с XP). Так что ответ Сергея Мухина
имеет место только для чисто-нативных приложений (и в случае ОС <= Win2000).
N>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота.
Очевидно, достаточно подождать пока исполнится стартап-код в ntdll.dll, который передаст управление на EntryPoint. Достаточно подождать пару сотен миллисекунд или перенаправить ентри-поинт на себя.
Здравствуйте, x64, Вы писали:
N>>При вызове CreateRemoteThread процесс умирает, то есть как предлагаете проверить начал ли исполняться внедренный код?
x64>Т.е. ты предлагаешь мне рассказать тебе, как пользоваться отладчиком?
Отладчик тут не каждый подойдёт. OllyDbg или студийный не справятся. SoftICE и WinDBG — вполне.
IID>Очевидно, достаточно подождать пока исполнится стартап-код в ntdll.dll, который передаст управление на EntryPoint. Достаточно подождать пару сотен миллисекунд или перенаправить ентри-поинт на себя.
Так в том то и дело, что иногда и 3 секунд не хватает.
Здравствуйте, IID, Вы писали:
IID>В этот момент все статические импорты уже замаплены, а также безусловно замаплена ntdll.dll (и kernel32.dll в свежих версиях ОС, вроде бы начиная с XP). Так что ответ Сергея Мухина
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Не работает — значит что поведение такое же как и без WaitForInputIdle() — процесс умирает. Приложение (куда инжектится) — не консольное.
PD>Приложение, куда инжектится — твое ? Если да, передай ему в командной строке дескриптор окна из инжектора, и пусть он пришлет сообщение этому окну, когда будет готов (напрмер, на первом WM_PAINT или где-то еще). Или передай ему ID своего потока и пусть он PostThreadMessage.
а Event не лучше ли? А то бывают и консольные приложения. (в общем случае)
---
С уважением,
Сергей Мухин
Re: Process up and ready?
От:
Аноним
Дата:
21.05.09 14:36
Оценка:
N>Возникла такая проблемка — может, кто чего посоветует. N>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает N>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота. N>Всем спасибо!
падает он вероятно потому что ваш поток расставляет хуи, то бишь патчит код процесса в то время как он в это же время работает в другом потоке.
Просто не создавайте новый потом а воспользуйтесь тем что есть.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Не работает — значит что поведение такое же как и без WaitForInputIdle() — процесс умирает. Приложение (куда инжектится) — не консольное.
PD>Приложение, куда инжектится — твое ?
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, IID, Вы писали:
IID>>В этот момент все статические импорты уже замаплены, а также безусловно замаплена ntdll.dll (и kernel32.dll в свежих версиях ОС, вроде бы начиная с XP). Так что ответ Сергея Мухина
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>Здравствуйте, IID, Вы писали:
IID>>>В этот момент все статические импорты уже замаплены, а также безусловно замаплена ntdll.dll (и kernel32.dll в свежих версиях ОС, вроде бы начиная с XP). Так что ответ Сергея Мухина
имеет место только для чисто-нативных приложений (и в случае ОС <= Win2000).
СМ>>а вот не будет в случаях OC >- Vista Kernel32 загружен в другое место?
PD>Автор вопроса утверждает, что если подождать, то все работает. Значит, вопрос не в kernel32 — не переедет же она через 5 сек
а почему бы и нет? ей надо только это очень быстро сделать
а на самом деле, как узнать ее адрес в другом процессе? Да и любой другой DLL?
СМ>а на самом деле, как узнать ее адрес в другом процессе? Да и любой другой DLL?
Инжектить свой код по-другому: с помощью WriteProcessMemory переписать свои функции в адресное пространство другого процесса и CreateRemoteThread на свою ф-ию. Ну и тогда своя ф-ия бежит в коде другого процесса — узнавай что хочешь...
СМ>>а на самом деле, как узнать ее адрес в другом процессе? Да и любой другой DLL?
N>Инжектить свой код по-другому: с помощью WriteProcessMemory переписать свои функции в адресное пространство другого процесса и CreateRemoteThread на свою ф-ию. Ну и тогда своя ф-ия бежит в коде другого процесса — узнавай что хочешь...
это не всегда возможно, если внутри ф-ии есть перемещаемые выражения.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Автор вопроса утверждает, что если подождать, то все работает. Значит, вопрос не в kernel32 — не переедет же она через 5 сек
СМ>а почему бы и нет? ей надо только это очень быстро сделать
"переезд" kernel32 — бред! количество смайликов не делает его смешнее
Если kernel32.dll присутствует в статическом импорте она будет загружена, и никуда уже не денется. Более того, если её в статических импортах нету — через CreateProcess такой процесс не запустить
СМ>а на самом деле, как узнать ее адрес в другом процессе? Да и любой другой DLL?
Например:
1) По дефолтному SEH обработчику. Он изначально в kernel32 указывает. При условии, конечно, что окружение процесса уже создано и проинициализировано (чем занимается как раз тот стартап код из ntdll.dll).
2) Из другого процесса — получить список модулей интересующего.
3) Посмотреть базу kernel32.dll в данной системе. В чужом процессе она будет по такому же адресу расположена. (Уж для обычных приложений 100%)
4) Почитать память чужого процесса, найти заголовок kernel32
хватит ?
Топик стартеру: ещё можно посмотреть в сторону внедрения Через APC
СМ>>это не всегда возможно, если внутри ф-ии есть перемещаемые выражения.
N>Если задача узнать куда загружена определенная длл — то возможно всегда: просто пишите свою ф-ию не используя перемещаемые выражения.
и Вы нам сейчас расскажете как это делать на С/C++?
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, namux, Вы писали:
СМ>>>это не всегда возможно, если внутри ф-ии есть перемещаемые выражения.
N>>Если задача узнать куда загружена определенная длл — то возможно всегда: просто пишите свою ф-ию не используя перемещаемые выражения.
СМ>и Вы нам сейчас расскажете как это делать на С/C++?
Что, проблема написать ф-ию которая вызывает GetModuleHandle?
Здравствуйте, IID, Вы писали:
IID>"переезд" kernel32 — бред! количество смайликов не делает его смешнее
ну нифига! я еще как-то могу понять, что никто уже не может отличить шутку от серьезного текста без смайликов. Но тут то! Два смайлика поставил и все равно серьезно восприняли!
IID>Если kernel32.dll присутствует в статическом импорте она будет загружена, и никуда уже не денется. Более того, если её в статических импортах нету — через CreateProcess такой процесс не запустить
СМ>>а на самом деле, как узнать ее адрес в другом процессе? Да и любой другой DLL? IID>Например: IID>1) По дефолтному SEH обработчику. Он изначально в kernel32 указывает. При условии, конечно, что окружение процесса уже создано и проинициализировано (чем занимается как раз тот стартап код из ntdll.dll).
Это по цепочке SEH надо пробегать?
IID>2) Из другого процесса — получить список модулей интересующего.
наверно это самое правильное
IID>3) Посмотреть базу kernel32.dll в данной системе. В чужом процессе она будет по такому же адресу расположена. (Уж для обычных приложений 100%)
Вы видимо не в теме. Давно уже при загрузке системных DLL (и Kernel32.dll в частности) ВОЗМОЖНО изменение базы! Называется это Address Space Layout Randomization
IID>4) Почитать память чужого процесса, найти заголовок kernel32
неэффективно и не дает 100%
IID>хватит ?
IID>Топик стартеру: ещё можно посмотреть в сторону внедрения Через APC
количество смайликов не делает его смешнее 
