Как обнаружить внедрение через CONTEXT.regEip ?

Есть какие-нить идеи как обнаружить инжект через CONTEXT.regEip в юзермодном режиме?
Обычно перед инжектом - суспендят поток, могет в цикле проверять статус потока?
И еще вопрос, таким способом можно инжектится в любой поток? или только в основной?

 

а если CreateRemoteThread? тут таким способом не получится определить

 

а ваш цикл проверки суспенда незасуспендится? )

 

Flasher
Imho потоки равноправны.

 

MSoft, от CreateRemoteThread есть уже противоядие
LazzY, неа, сложно будет найти мой поток, прилажение многопоточное...
q_q, ясно..
А где вообще храниться структура контекста потока? Могет ее возможно будет переместить?
Т.е. ZwGetContextThread откуда берет данные ?

Я так понял eip - это указатель на инструкцию которая выполняется в потоке на данный момент?

 

ух ты... а перечислять потоки теперь умеют только агенты ФБР?

в режиме ядра сохраняется контекст. из юзермода не достанешь

на правах рекламы: PS. скоро будет стотья про процессы и потоки, которую никак не мог закончить ввиду отстутствия времени в том числе там и про контексты есть

 

Great, мне даже самый лоховской метод обноружения или противодействия пригодится, хотябы на первое время, пока ничего лучще не придумаю.., или подскажут..
Так что генерите сударь идеи, генерите..

 

Перехватить KiUserApcDispatcher, либо похукать DllEntryPoint ntdll.
А вот с ZwSetContextThread, можно создать еще один поток, который будет каждую сек проверять eip на принадлежность к какому-то модулю/лям, правда не много геморный способ как подругому не обращаясь к хукам без понятия.

 

Из юзермода никак не удастся обнаружить, если конечно не отслеживаются временные задержки. А в общем можно сделоть так - обычно при инжекте из системинфо извлекается ID первого потока в процессе и он используется для инжекта. Так вот - создать несколько потоков, взять первый, который будет в списке инфы, понизить его приоритет и заюзать в этом потоке бесконечный цикл Int2A/ZwYieldExecution, который будет замерять интервалы. Если инжект атомарно, редиректом всех потоков с помощью NtSuspendProcess, то это также может быть обнаружено, если конечно выполнится не слишком быстро. Как альтернатива - мониторить число системных сервисов, похучив шлюз либо если можно спроецировав себе в процесс на чтение часть памяти ядра(ETHREAD и etc.). Хотя не слишком эффективно. Из юзермода вобщем трудно контролировать подобное.

 

напиши драйвер и не дай открыть хендл твоего процесса. просто и эффективно.
хендл еще останется в csrss, его тоже можно закрыть.

не понимаю зачем тебе в юзермоде это все надо

 

А с ZwYieldExecution можно подробней ?
Описание

Как это могет мне помочь ?

 

С сорсов винды описание:

Короче, вызвав этот сервис поток отдаст квант своего времени системе, планировщик в последовательности переключения процессорного времени пропустит его. Вызов для того, чтобы разгрузить систему, ибо юзается быстрый вызов в цикле KiGetTickCount. Моожно с такойже целью заюзать NtDelayExecution, но так как период мал, это не подходит, если указать минимум, вроде 0.1мс, вызов эквиволентен тому сервису.
Код выглядит просто класным, ибо нет у сервиса параметров.

 

CrystalIC, та глупость написал, потом стер )
Если честно суравно не понял как NtDelayExecution могет помочь выявить факт суспендирования

А еще чаще всего поток находят таким способом

Код (Text):

1.     invoke CreateToolhelp32Snapshot,TH32CS_SNAPTHREAD,addr te32
2.     mov hSnapshot,eax
3.     mov te32.dwSize,sizeof THREADENTRY32
4.     invoke Thread32First,hSnapshot,addr te32
5. _loop4:
6.     mov eax,te32.th32OwnerProcessID
7.     .if eax == pID
8.         m2m thID,te32.th32ThreadID
9.         jmp _endloop4
10.     .endif
11.     invoke Thread32Next,hSnapshot,addr te32
12.     .if eax == TRUE
13.         jmp _loop4
14.     .endif
15.    _endloop4:
16.     invoke CloseHandle,hSnapshot
17.  
18.     invoke OpenThread,THREAD_ALL_ACCESS,0,thID

Я так понял TH32CS_SNAPTHREAD перебирает все потоки в системе ?
Могет на этом этапе не дать найти потоки моего процесса? Или это из облости фентази?

 

CrystalIC
А между чем и чем интервалы замерять? Между получением потоком процессорного времени? Это бред. Если Ваш метод со сравнением интервалов при трассировке и без даёт ещё более-менее какую-то надёжность, то интервал, с которым поток будет получать процессорное время, может ооочень сильно колебаться. Как предлагаете в таком случае отличить замораживание потока от простого скачка в нагрузке системы?
К тому же откуда уверенность, что я разморожу измеряющий поток назад при инжекте? Заморожу все потоки, использую какой-нибудь один для своего грязного дела, а потом просто свалю процесс.
Flasher

Вам Great это (ну почти это) и советовал. По сути и драйвер не обязателен, но для юзермодного "запрета" работа объёмнее.

 

l_inc
А вы когдалибо инжект писали ?
Скока времени займёт загрузка модуля по LdrLoadDll() ?
Поток выполняет чтение текущего времени(условно, к примеру тики). Тут паразитный процесс суспендит поток, сохраняет контекст для последующего восстановления, и передаёт управление на его полезную нагрузку. Пока она будет исполняться код того потока исполняться не будет. А это - потеря времени и значительная. Конечно, если примитивный атомарный инкремент исполняется или к примеру вызов одного/двух быстрых сервисов, то ничего обнаружено не будет. В случае загрузки модуля, подключения отладчика и тому подобного это весьма эффективно. Если период чтения времени допустим 1мс, а код исполняющий инжект для синхронизации в большинстве случаев ждёт на эвентах/портах то время ожидания(да и вобще работы потока) будет гораздо большим. Даже если изначально считано значение к примеру в три раза большая задержка чем при следующей итерации, то следует сделоть вывод об нарушении нормальной работы потока. Аналогичная ситуация будет вероятно и с инжектом посредством апк.

 

и пашет только для юзермода

 

CrystalIC

А Вы писали? Вы в курсе, что я совсем не обязан подгружать dll? Всё, что мне нужно сделать, - это тормознуть поток и сделать SetThreadContext на заранее внедрённый код, который в свою очередь создаёт, например, ещё один поток, а попользованному потоку возвращает контекст. Да я в один квант уложусь. Это даже за скачок в нагрузке системы не сойдёт.
И ещё раз повторяю: немало инжектов вообще не возвращают использованный поток к жизни.
P.S. И вообще вряд ли автор хочет установить постфактумом, что его поимели. Скорее всего нужно препятствовать инжекту.
Freeman

Тоже верно.

 

В отличае от тебя я знаю автора и знаю что ему нужно и знаю как это решить.

 

CrystalIC
Ну так Вы заранее имеете преимущество. А для не ЭЛИТЫ постановка задачи конкретизирована недостаточно, чтобы можно было однозначно ответить на вопрос. И если знаете, что конкретно нужно автору, что ж Вы его заставляете такие глупости спрашивать:

?
Сразу бы ему и ответили в ПМ.

 

Я сдесь ответил и этого достаточно должно быть.