Коллеги, всем всего доброго!

Похоже, что .NET прибавил интеллекта функции GetThreadContext.

Задача типовая — создаем процесс с CREATE_SUSPENDED, через вызов GetThreadContext определяем точку входа в exe и прописываем туда свой код. В случае не-.NET процессов все работает как и планировалось. А вот если с .NET такую штуку проделать, то внедренный код не получает управления.

Если взять простой отладчик (MSVS2005) и после вызова GetThreadContext посмотреть в CONTEXT.Eax, то там будет адрес, похожий на точку входа, типа 0x0004.....
А вот если помимо CONTEXT.Eax посмотреть еще и CONTEXT.Eip, взять значение CONTEXT.Eip, пойти в WinDbg и сделать bu на это значение, то WinDbg в этой точке в Eax будет показывать адрес в аккурат _CorExeMain. И при трассировке прямиком туда и попадет.

Я вижу три варианта того, что происходит.

1. Либо GetThreadContext стал очень умным и подменяет значение в EAX, когда там адрес _CorExeMain, на адрес точки входа.
2. Либо WinDbg стал очень умным и подменяет значение в EAX на _CorExeMain (типа все равно по стандартной заглушке туда попадешь).
3. Либо меня глючит и обе машины, где я это наблюдал, тоже. Обе XP SP2.

Вы за какой вариант голосуете?
Может быть у вас есть свои варианты?

Здравствуйте, -Forester-, Вы писали:

F>2. Либо WinDbg стал очень умным и подменяет значение в EAX на _CorExeMain (типа все равно по стандартной заглушке туда попадешь).

Стандартная заглушка (jmp _CorExeMain) выполняется только в Win98-х и WinNT-Win2k; начиная с WinXP, загрузчик (OS loader т.е.) самостоятельно определяет, содержит ли загружаемый модуль управляемый код — в таком случае он автоматом подгружает ран-тайм .NET (mscoree.dll) и самостоятельно прыгает непосредственно на _CorExeMain, без выполнения кода заглушки.

Здравствуйте, vitalyk, Вы писали:

V>Стандартная заглушка (jmp _CorExeMain) выполняется только в Win98-х и WinNT-Win2k; начиная с WinXP, загрузчик (OS loader т.е.) самостоятельно определяет, содержит ли загружаемый модуль управляемый код — в таком случае он автоматом подгружает ран-тайм .NET (mscoree.dll) и самостоятельно прыгает непосредственно на _CorExeMain, без выполнения кода заглушки.

Спасибо за ответ.
Получается, что GetThreadContext стала умнее. И зачем-то (для обратной совместимости? или совместимости с документацией?) заменяет реальное значение в EAX на адрес точки входа. Тогда и SetThreadContext тоже по идее должна стать умнее и не давать менять значение в EAX при старте.
Я на днях пробовал использовать SetThreadContext для внедрения, и .NET процессы не обращали на мои попытки никакого внимания, но Win32 успешно валились в разных местах.