N>Возникла такая проблемка — может, кто чего посоветует. N>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает N>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота. N>Всем спасибо!
падает он вероятно потому что ваш поток расставляет хуи, то бишь патчит код процесса в то время как он в это же время работает в другом потоке.
Просто не создавайте новый потом а воспользуйтесь тем что есть.
Спасибо за развернутый ответ. Если кое-кто излишне умный немного подучится то поймет, что если CreateRemoteThread не отрабатывает то и никакой код не внедряется.
Здравствуйте, namux, Вы писали:
N>Возникла такая проблемка — может, кто чего посоветует. N>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает
После того как процесс создан, его выполнение начинается с ResumeThread в недрах ntdll.dll, которая настраивает всё окружение процесса в юзермоде.
В этот момент все статические импорты уже замаплены, а также безусловно замаплена ntdll.dll (и kernel32.dll в свежих версиях ОС, вроде бы начиная с XP). Так что ответ Сергея Мухина
имеет место только для чисто-нативных приложений (и в случае ОС <= Win2000).
N>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота.
Очевидно, достаточно подождать пока исполнится стартап-код в ntdll.dll, который передаст управление на EntryPoint. Достаточно подождать пару сотен миллисекунд или перенаправить ентри-поинт на себя.
N>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает
Падение целевого процесса происходит до или после начала исполнения внедрённого кода? Не кода DLL, а именно внедрённого кода.
Возникла такая проблемка — может, кто чего посоветует.
Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает
Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота.
Всем спасибо!
Здравствуйте, namux, Вы писали:
N>Возникла такая проблемка — может, кто чего посоветует. N>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает N>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота. N>Всем спасибо!
Здравствуйте, namux, Вы писали:
N>Спасибо за развернутый ответ. Если кое-кто излишне умный немного подучится то поймет, что если CreateRemoteThread не отрабатывает то и никакой код не внедряется.
не надо горячиться. Почитайте ЧТО спрашивает x64.
"начался ли выполняться внедренный код", а Вы отвечаете "падение происходит при CreateRemoteThread"
Здравствуйте, namux, Вы писали:
N>Спасибо за развернутый ответ. Если кое-кто излишне умный немного подучится то поймет, что если CreateRemoteThread не отрабатывает то и никакой код не внедряется.
Вы не кипятитесь .
Просто приведете код, где пытаетесь внедрить DLL и код самой DLL. Посмотрим, а то информации не так уж и много Вы привели.
где pszLibFileRemote — имя длл в адресном пространстве целевого процесса.
При вызове CreateRemoteThread процесс умирает, то есть как предлагаете проверить начал ли исполняться внедренный код?
Здравствуйте, namux, Вы писали:
N>Я не кипячусь, просто не люблю хамства. N>Насчет внедренного кода я же ответил — внедрение происходит посредством CreateRemoteThread:
N>PTHREAD_START_ROUTINE pfnThreadRtn = ( PTHREAD_START_ROUTINE ) GetProcAddress( GetModuleHandle( TEXT( "Kernel32" )), "LoadLibraryW" ); N>CreateRemoteThread( hProcess, NULL, 0, pfnThreadRtn, pszLibFileRemote, 0, NULL );
N>где pszLibFileRemote — имя длл в адресном пространстве целевого процесса. N>При вызове CreateRemoteThread процесс умирает, то есть как предлагаете проверить начал ли исполняться внедренный код?
Приведите плз весь процесс ваших действий по внедрению полностью. WriteProcessMemory() делали? VirtualAllocEx()? VirtualProtectEx()? Или догадываться?
Здравствуйте, namux, Вы писали:
N>Не работает — значит что поведение такое же как и без WaitForInputIdle() — процесс умирает. Приложение (куда инжектится) — не консольное.
Приложение, куда инжектится — твое ? Если да, передай ему в командной строке дескриптор окна из инжектора, и пусть он пришлет сообщение этому окну, когда будет готов (напрмер, на первом WM_PAINT или где-то еще). Или передай ему ID своего потока и пусть он PostThreadMessage.
PD>Приложение, куда инжектится — твое ? Если да, передай ему в командной строке дескриптор окна из инжектора, и пусть он пришлет сообщение этому окну, когда будет готов (напрмер, на первом WM_PAINT или где-то еще). Или передай ему ID своего потока и пусть он PostThreadMessage.
P>Приведите плз весь процесс ваших действий по внедрению полностью. P>WriteProcessMemory() делали? VirtualAllocEx()? VirtualProtectEx()? Или догадываться?
в данном случае догадаться легко. т.к. был намек, что "если подождать 5 сек то все работает".
Еще раз подчеркиваю — проблема проявляется только если длл инжектится сразу после запуска целевого процесса (процесс не мой). Если WaitForProcessUp состоит из вызова Sleep( 3000 ) то все работает ок.
N>При вызове CreateRemoteThread процесс умирает, то есть как предлагаете проверить начал ли исполняться внедренный код?
Т.е. ты предлагаешь мне рассказать тебе, как пользоваться отладчиком? Ну есть документация, почитай. Ты говоришь что падает целевой процесс. Следовательно, тебе нужно, как минимум, сузить область поиска ошибки. Для этого я предлагаю тебе разделить в уме весь алгоритм внедрения на три фазы:
kernel32.dll: по тому же адресу — да (иначе не работало бы с таймаутом), загружена ли — не знаю. По идее, WaitForIdleProcess и говорит что процесс готов.
x64: А что вы мне предлагаете дебажить? Чужой процесс до внедрения длл? А если в DllMain ставить бесконечный цикл — то процесс точно так же умирает.
В общем и целом ясно (мне) что проблема в том что целевой процесс не успел толком проинициализироваться. Вот я и спросил — как отследить что процесс "up and ready"?
Здравствуйте, 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 не лучше ли? А то бывают и консольные приложения. (в общем случае)
Здравствуйте, 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
Здравствуйте, IID, Вы писали:
IID>>>2) Из другого процесса — получить список модулей интересующего. N>>Так Сергей и спрашивает как это сделать...
IID>Не уверен Думаю, Сергей прекрасно знает и про PsApi обёртку, и про NativeAPI.
конечно.
я просто говорю, что зная адрес DLL в своем процессе недостаточно, что бы утверждать, что точно такая же DLL будет находиться по тому же адресу в другом процессе. Даже Kernel32
Здравствуйте, Сергей Мухин, Вы писали:
IID>>Например: IID>>1) По дефолтному SEH обработчику. Он изначально в kernel32 указывает. При условии, конечно, что окружение процесса уже создано и проинициализировано (чем занимается как раз тот стартап код из ntdll.dll).
СМ>Это по цепочке SEH надо пробегать?
Если приложение только что запустилось и на EP ещё не попало — там будет всего один SEH обработчик. Иначе — да, придётся просмотреть всю цепочку. В самых клинических случаях (теоретически) цепочка может и не оканчиваться обработчиком из Kernel32.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Сергей Мухин, Вы писали:
IID>>>Например: IID>>>1) По дефолтному SEH обработчику. Он изначально в kernel32 указывает. При условии, конечно, что окружение процесса уже создано и проинициализировано (чем занимается как раз тот стартап код из ntdll.dll).
СМ>>Это по цепочке SEH надо пробегать?
IID>Если приложение только что запустилось и на EP ещё не попало — там будет всего один SEH обработчик. Иначе — да, придётся просмотреть всю цепочку. В самых клинических случаях (теоретически) цепочка может и не оканчиваться обработчиком из Kernel32.
ну т.е. этот метод оставим в качестве упражнения. Для боевого применения имхо не годится.
А если программа знает, что в н е будут так внедряться, то вообще легко обмануть уже нас
Здравствуйте, namux, Вы писали:
N>>>Если задача узнать куда загружена определенная длл — то возможно всегда: просто пишите свою ф-ию не используя перемещаемые выражения.
СМ>>и Вы нам сейчас расскажете как это делать на С/C++?
N>Что, проблема написать ф-ию которая вызывает GetModuleHandle?
Что-то совсем плохо у вас с логикой и со знаниями.
СМ>>Вот такую например попробуйте запихнуть и выполнить. СМ>>При этом версия С в приложении мб отличной от Вашей
N>Да, все-таки проблема написать. Вот такая будет работать всегда:
N>
N>void ccc() {
N>HMODULE hMod = LoadLibrary( "kernel32.dll" );
N>FARPROC p = GetProcAddress( hMod, "GetModuleHandle" );
N>HMODULE H = ( *p )( "AAA" );
N>// переслать в свой процесс
N>}
N>
Отлично. давайте теперь сделайте, что обещали, покажите, как Вашу ф-ию легко переместить в другое пространство. Что бы выполнить можно было бы.
Здравствуйте, x64, Вы писали:
СМ>>и Вы нам сейчас расскажете как это делать на С/C++?
x64>Только не говори, что не знаешь что такое базонезависимый код...
знаю, но не знаю как его сделать из нетривиальной ф-ии
как я понимаю, проблемы будут в следующем:
1. убедиться в отсутствии Сшной поддержки (некоторые опции могут порождать вызовы) (это легко)
2. найти размер ф-ии (я не знаю кошерных способов)
3. НЕ вызывать другие свои ф-ии, или их так же надо переносить (с транзитивным замыканием)
4. Не знаю что делать, если используются сегменты .rdata и .data (а в приведенной ф-ии есть .rdata)
5. при вызове импортной ф-ии хотелось бы убедится, что вызов происходит через правильную таблицы (разные компиляторы ее по разному генерят),
СМ>Отлично. давайте теперь сделайте, что обещали, покажите, как Вашу ф-ию легко переместить в другое пространство. Что бы выполнить можно было бы.
Насче того что Я говорил что это просто и что-то обещал — это Ваши фантазии. Я говорил что просто написать саму ф-ию, имея ввиду Windows XP (наверно, надо было это подчеркнуть). А как — смотрите здесь
СМ>>Отлично. давайте теперь сделайте, что обещали, покажите, как Вашу ф-ию легко переместить в другое пространство. Что бы выполнить можно было бы.
N>Насче того что Я говорил что это просто и что-то обещал — это Ваши фантазии. Я говорил что просто написать саму ф-ию, имея ввиду Windows XP (наверно, надо было это подчеркнуть). А как — смотрите здесь
ф-ию тут может каждый написать. А если нет ее прямого внедрения — не интересно совсем. мб я не так понял.
а статья хорошая. Но вы ее не читали. т.к. там, например, прямо написано, что нельзя использовать строки.
Здравствуйте, x64, Вы писали:
СМ>>и Вы нам сейчас расскажете как это делать на С/C++?
x64>Только не говори, что не знаешь что такое базонезависимый код...
Я не знаю, но хочу об этом знать. Что читать?
«Мы с тобой в чудеса не верим, Оттого их у нас не бывает…»
Здравствуйте, meerius, Вы писали:
СМ>>>и Вы нам сейчас расскажете как это делать на С/C++?
x64>>Только не говори, что не знаешь что такое базонезависимый код... M>Я не знаю, но хочу об этом знать. Что читать?
я не знаю, что читать. давно ничего не читаю. Но задача внедрения кода решается один раз в жизни. потом можно забыть об этом и никогда не вспоминать ни задачу, ни все что с ней связано.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, meerius, Вы писали:
СМ>>>>и Вы нам сейчас расскажете как это делать на С/C++?
x64>>>Только не говори, что не знаешь что такое базонезависимый код... M>>Я не знаю, но хочу об этом знать. Что читать?
СМ>я не знаю, что читать. давно ничего не читаю. Но задача внедрения кода решается один раз в жизни. потом можно забыть об этом и никогда не вспоминать ни задачу, ни все что с ней связано.
У Рихтера целая глава есть по внедрению кода, но про базонезависимый код он даже не заикнулся
Я даже термин такой не слышал. Думаю, для общего развития не помешает об этом знать.
«Мы с тобой в чудеса не верим, Оттого их у нас не бывает…»
Здравствуйте, meerius, Вы писали:
M>Я даже термин такой не слышал. Думаю, для общего развития не помешает об этом знать.
ну термин немного по другому может звучать, например "перемещаемый код" или как-то еще
общее развитие хорошо, но я сразу вспоминаю Холмса,
- Ну, а как же Аристотель, Жанна д’Арк, Коперник?
— Коперник – знакомая фамилия. Что он сделал?
— Боже мой, так ведь же это он открыл, что Земля вращается вокруг Солнца. Или этот факт Вам тоже неизвестен?
— Но мои глаза говорят мне, что скорее Солнце вращается вокруг Земли. Впрочем, может быть он и прав, ваш, как его, Коперник.
— Простите меня, Холмс… Вы человек острого ума, это сразу видно. Вы превосходно знаете химию… Как же вы не знаете вещей, которые известны каждому школьнику?
— Ну, когда я был школьником, я это знал, а потом основательно забыл. Лишнего хлама мне не нужно.
— Учение Коперника, по-вашему, хлам?!
— Хорошо. Допустим, Земля вращается вокруг Солнца…
— То есть как “допустим”?...
— Хорошо, Земля вращается вокруг Солнца, но мне в моем деле это не пригодится.
я не уверен, что цитата из книги, мб она из фильма. в книге (как я помню) там еще рассуждения идут о чердаке
СМ>общее развитие хорошо, но я сразу вспоминаю Холмса,
СМ>
СМ>- Ну, а как же Аристотель, Жанна д’Арк, Коперник?
СМ>- Коперник – знакомая фамилия. Что он сделал?
СМ>- Боже мой, так ведь же это он открыл, что Земля вращается вокруг Солнца. Или этот факт Вам тоже неизвестен?
СМ>- Но мои глаза говорят мне, что скорее Солнце вращается вокруг Земли. Впрочем, может быть он и прав, ваш, как его, Коперник.
СМ>- Простите меня, Холмс… Вы человек острого ума, это сразу видно. Вы превосходно знаете химию… Как же вы не знаете вещей, которые известны каждому школьнику?
СМ>- Ну, когда я был школьником, я это знал, а потом основательно забыл. Лишнего хлама мне не нужно.
СМ>- Учение Коперника, по-вашему, хлам?!
СМ>- Хорошо. Допустим, Земля вращается вокруг Солнца…
СМ>- То есть как “допустим”?...
СМ>- Хорошо, Земля вращается вокруг Солнца, но мне в моем деле это не пригодится.
Вспоминаю Булгакова
- Я извиняюсь, — заговорил он подозрительно, — вы кто такой будете? Вы — лицо официальное?
— Все это зависит от того, с какой точки зрения смотреть на предмет, все это, Никанор Иванович, условно и зыбко. Сегодня я неофициальное лицо, а завтра, глядишь, официальное! А бывает и наоборот, Никанор Иванович. И еще как бывает!
Рассуждение это ни в какой степени не удовлетворило председателя домоуправления. Будучи по природе вообще подозрительным человеком, он заключил, что разглагольствующий перед ним гражданин — лицо именно не официальное, а пожалуй, и праздное.
Вот жене моей точно не пригодится — она экономист
«Мы с тобой в чудеса не верим, Оттого их у нас не бывает…»
Здравствуйте, meerius, Вы писали:
M>Вспоминаю Булгакова M>
M>- Я извиняюсь, — заговорил он подозрительно, — вы кто такой будете? Вы — лицо официальное?
M>- Все это зависит от того, с какой точки зрения смотреть на предмет, все это, Никанор Иванович, условно и зыбко. Сегодня я неофициальное лицо, а завтра, глядишь, официальное! А бывает и наоборот, Никанор Иванович. И еще как бывает!
M>Рассуждение это ни в какой степени не удовлетворило председателя домоуправления. Будучи по природе вообще подозрительным человеком, он заключил, что разглагольствующий перед ним гражданин — лицо именно не официальное, а пожалуй, и праздное.
M>Вот жене моей точно не пригодится — она экономист
и моей
---
С уважением,
Сергей Мухин
Re[2]: Process up and ready?
От:
Аноним
Дата:
25.05.09 04:12
Оценка:
Здравствуйте, Аноним, Вы писали:
N>>Возникла такая проблемка — может, кто чего посоветует. N>>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает N>>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота. N>>Всем спасибо! А>падает он вероятно потому что ваш поток расставляет хуи, то бишь патчит код процесса в то время как он в это же время работает в другом потоке. А>Просто не создавайте новый потом а воспользуйтесь тем что есть.
Ну как то по Фрейду прямо
Re[3]: Process up and ready?
От:
Аноним
Дата:
25.05.09 05:49
Оценка:
N>>>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота. N>>>Всем спасибо! А>>падает он вероятно потому что ваш поток расставляет хуи, то бишь патчит код процесса в то время как он в это же время работает в другом потоке. А>>Просто не создавайте новый потом а воспользуйтесь тем что есть. А>Ну как то по Фрейду прямо
Интересно на вас было бы посмотреть. Если бы вы пересаживались с десктопа на лаптоп и назад так же часто как я...
Здравствуйте, namux, Вы писали:
N>Возникла такая проблемка — может, кто чего посоветует. N>Моя апликуха ждет появления определенного процесса, по появлении инжектит в него мою дллку с помощью тыщу раз описанной методики через CreateRemoteThread. Так вот, если после появления процесса немного не подождать, то при вызове CreateRemoteThread тот прцесс тихо умирает N>Собственно, вопрос: как, чего и сколько ждать? Когда процесс будет готов? А тупо ждать 5 сек неохота. N>Всем спасибо!
Юзай detours!
Ничто не ограничивает полет мысли программиста так, как компилятор.