1.
При попытке инжекта в чужой процесс (любой) под XP SP3 (возможно и 2), используя RtlCtreateUserThread (RtlExitUserThread), NtQueueApcThread (LdrLoadDll или любую из LoadLibrary (LoadLibraryA(W), LoadLibraryExA(W)), NtResumeThread. используя CreateRemoteThread всё акей, т.е. никаких ошибок нету, только невозможно инжектить такую библиотеку в некоторые процессы, из-за некоторых ограничений CreateRemoteThread под XP SP2 и выше.
LdrLoadDll возвращает статус:
//
// MessageId: STATUS_ILLEGAL_FUNCTION
//
// MessageText:
//
// The specified handle is not open to the server end of the named pipe.
//
#define STATUS_ILLEGAL_FUNCTION ((NTSTATUS)0xC00000AFL)
под 2k8,vista и 7 всё работает, никаких ошибок такого рода не возвращяет.
И в этой же теме второй вопрос:
2.
При попытке инжекта в процесс, который только что был создан, используя CreateRemoteThread всё под той же ХР начинаются проблемы, если инжектить после возобновления потока, то всё хорошо, если сразу до, то потом поток умирает... тестировал на taskmgr к примеру.
опять же под 2k8,vista и 7 всё ок

| Сообщение посчитали полезным:

multiarc
> используя RtlCtreateUserThread (RtlExitUserThread), NtQueueApcThread
Вобщем смысла нет использовать создание потока с доставкой апк. Хотя апк будет доставлена до перехода на пользовательский стартовый адрес треда, но смысла в такой манипуляции нет. Доставка апк используется для захвата контекста уже созданных тредов, которые находятся в ожидании с разрешением на обработку апк.
> из-за некоторых ограничений CreateRemoteThread под XP SP2
Создавайте нативный тред, тогда никаких ограничений не будет.
> поток умирает
Проблемы могут быть в чём угодно, например тред вызвал сервис из шадова до инициализации клиента, что приведёт к сепшену, причин множество.
> невозможно инжектить такую библиотеку
Загрузка модуля удалённо потенциально нестабильна, внедряйте пикод. Альтернатива всякому способу инжекта - подмена секций(см. на васме в поисковике).
Захват контекста посредством NtGetContextThread тоже лучше во всяком случае, чем удалённые потоки.
Второй способ - обработка сепшена любым подходящим способом, тогда в контексте вновь создаваемого треда взводится TF и после исполнения первой инструкции диспетчера апк будет сгенерировано трассировочное исключение. Иначе если есть защита ваш удалённый поток не сможет её обойти, в контексте не возможно изменить регистр Eip перед доставкой ядерной апк, тред с неё и начинается.

| Сообщение посчитали полезным:

Для начала скажу, что мне не нужны нативные трэды... (ибо это всё юзер мод, что мне нужно) на счёт захвата контеста могу только сказать, что это хорошо только если поток уже создан, т.е. процесс уже проинициализирован... А если процесс только что создал и его потоки не успел выполниться, то такое не катит никак... мы можем конечно захватить только что созданный первый поток приложения... т.е. подменить его контекст... но всё же вопрос остаётся открытым, почему при использовании удалённых потоков не через CreateRemoteThread мы получаем выше указанную ошибку?

| Сообщение посчитали полезным:

multiarc
Нативный это который только ntdll юзает.
> почему при использовании удалённых потоков не через CreateRemoteThread мы получаем выше указанную ошибку?
Сколько юзал никогда такой ошибки лодер не возвращал, более того ни в нтдлл, ни в kernel32 не определён этот код ошибки, так что это скорее всего это ваши модуля загружаемые возвращают.
Советуем достать руки и делать всё по нормальному

| Сообщение посчитали полезным:

а мне вот нужен инжект в .NET прогу.
создаю процесс с флагом CREATE_SUSPENDED и когда юзаю CreateRemoteThread запускается сама программа а не тред который должен загрузить дллку.
как быть?
может эти ваши RtlCtreateUserThread (RtlExitUserThread), NtQueueApcThread помогут?)
или какие ещо варианты попробовать.

-----
zzz

| Сообщение посчитали полезным:

У меня проблема, с которой впервые сталкиваюсь (никогда инжект раньше не был неудачен).

1) Создаю процесс ф-цией CreateProcess с флагом CREATE_SUSPENDED, ..., через CreateRemoteThread хочу загрузить свою dll. Поток создается нормально, вызывает LoadLibraryA, LoadLibraryExA, LoadLibraryExW, ... В RtlpWaitForCriticalSection поток вываливает ACCESS_VIOLATION (чтение по адресу 0x10), в результате dll не грузится. По-видимому это означает, что недоинициализирована какая-то структура. Раньше делал абсолютно также и все было успешно, в чем дело?

2) Раз такое дело, попробовал найти EP - самое место для перехвата, но оказывается в памяти процесса только ntdll.dll и kernel32.dll, самого образа исполняемого файла еще нет. Надо значит подождать...

3) Чтобы подождать, доработал asm-код (под MS студию), который также внедряется популярной ф-цией инжекта в память процесса, ставит там хук на LoadLibraryExW.... Проверял - хук ставится, никуда не девается, но не срабатывает. Здесь я очень может быть ошибаюсь, что она должна вызываться из ntdll )) Но! Новая проблема - исполняемый файл загрузился, а все необходимые ему функции не импортировались !!? Импорт целиком остался нетронутым, как и до загрузки.

Очень интересно, по каким причинам может возникать проблема, указанная в 1 способе?

В 3-ем способе в спящем процессе использовал только 2 API-функции: VirtualProtect и FlushInstructionCache для помощи в установке хука. Что я делаю не так?

______________________________________________________________________ _____________

3) Эта проблема не возникает, если не пользоваться студийным отладчиком Visual Studio. Оля и 1-ая и 2-ая хорошо переносятся.

2) Файл образа загружается в память процесса, если в Process Explorer зайти в свойства процесса и тогда Оли видят процесс. Жаль, что из PE нельзя перейти в отладчик - Оля пишет, что не может найти процесс с указанным идентификатором.

1) Проблема остается. Видимо, не зависит от отладчика. Дело все в том, что внутри kernel32.dll объект _BaseDllDirectoryLock некоей структуры не инициализирован и передается в ntdll RtlEnterCriticalSection, который в свою очередь рассматривает одно из его нулевых полей, как то, что уже критическая занята и передает управление в ntdll.RtlpWaitForCriticalSection. Кстати в ntdll аналогичный объект на тот момент инициализирован...

-----
IZ.RU

| Сообщение посчитали полезным: