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

Перестаньте обсуждать умственные способности автора, он сам знает что мягко говоря - нуб

Хукать во всех процессах ZwOpenProcess ?

Нашел интересную функцию NtSetThreadExecutionState.

А еще, не помогут ли нам функции ZwSetInformationThread\ZwQueryInformationThread c инфоклассом ThreadPerformanceCount для чекания времени застоя ?

 

Flasher

Ага. Но предложение Great проще и удачнее.

 

CrystalIC

торможу сегодня. Разве ZwYieldExecution не сисентер/инт 2е?

И еще обнаружились функи вызывающие инт 10х, инт 4 итд (щас не помню). или это либы к моему железу?

 

В Eax номер сервиса NtYieldExecution...
Смотрим в IDT:

Код (Text):

1. Interrupt Descriptor Table
2. Base: 8003F400   Limit: 000007FF
3. Selector    - Segment Selector for destination code segment
4. Offset      - Offset to procedure entry point
5. DPL     — Descriptor privilege level
6. P       — Segment present
7. D       - Size of gate: 1 = 32 bits; 0 = 16 bits D
8. --------------------------------------------------------------------------------------------------------------
9. Int.  Sel.:Offset    DPL  P   D        Descriptor Type   Description
10. --------------------------------------------------------------------------------------------------------------
11. 0003  0008:804DF061   3   P   32 bits  Interrupt Gate   Trap
12. 0004  0008:804DF1E6   3   P   32 bits  Interrupt Gate   Trap
13. 0021  00C7:000004E6   3   P   16 bits  Trap Gate
14. 002A  0008:804DE2C6   3   P   32 bits  Interrupt Gate
15. 002B  0008:804DE3D1   3   P   32 bits  Interrupt Gate
16. 002C  0008:804DE586   3   P   32 bits  Interrupt Gate
17. 002D  0008:F8949DDC   3   P   32 bits  Interrupt Gate
18. 002E  0008:804DDD36   3   P   32 bits  Interrupt Gate

В остальных дескрипторах DPL=0 и они не доступны для юзермода.

 

Доступны прерывания сервисные 2A, 2B, 2C, 2D, 2E.

Честно говоря не знаю назначения 2B.
2A - GetTickCount.
2C - SetLowWaitHighThread
2D - DebugService (для DbgPrint/DbgPrompt)
2E - SystemService

 

0x2B - KiCallbackReturn, тоже что и сервис NtCallbackReturn для возврата в кернелмод из калбака вызванного посредством KeUserModeCallback.
0x4 - into.
0x3 - отладочный останов.

 

\wrk\base\ntos\ke\i386\trap.asm

 

Народ. Эта задача качественно не решается. Вы же сами отлично понимаете что несёте бред полнейший. Какое действие - такое будет противодействие. Из ядра всё решится наура и ничево никто не заметит=)))))))

 

k3internal
так тут вроде про юзермодный инжект. это последние N постов ушли в тему назначения различных векторов прерываний в винде)

 

k3internal
Вы с темой попутали..

 

опять я со своим офтопом

В msdart.dll куча функов интит 10н вектор. MessageBoxI - напрямую. Если int 10h - просто мессажбох (с еррором напр), то почему таким зверским способом?
далее. в msvcr80d.dll :: _fmode сваливается, в конце-концов, в int 5ah. а вот других msvcrt почему-то нет. почему-бы? (может недостаточно глубоко искал?)

 

я тему непапутал. я про нево и говорю. Раз мы собираемся делать инжект, значит унас достаточно прав что бы открыть процесс на жапись и для манипуляций с его контекстом. А если так, то, мы можем внедриться в процесс, который запустит подзащитный процесс. Тогда мы поимеем его хэндл и ещё можем перехватить функцию запуска процесса, запустив его с флагом Create_Suspended. Первичный поток встанет на ЕП. Тогда мы делаем инжект и правим код ЕП нужным нам образом. Отпускаем первичный поток. Наш код отрабатывает ивосстанавливает код ЕП. Ну и кто должен это будет заметить ??? Если у вас нету Длл к этому процессу с тлс-колбеками или ваш ехек без них, то хрен вы чем спалите такую манипуляцию. А даже с ТЛС-колбеками вопрос решается просто, они не гакнут.

 

k3internal
Имеется ввиду инжект в уже запущенный процесс, а не на этапе инит.
_basmp_
На векторе 0x10 весит обработчик исключений fpu, прерывание не доступно для юзермода.

Может этот модуль вешаетсо на прерывание, создавая шлюз в IDT..
[Или это намеренный вызов исключения, в целях антиотладки, Кристалег такой способ тоже юзал].

 

Вобщем вопрос интересный, немного поразмыслив я пришёл к выводу что в принципе можно обнаружить инжект.
Инжект такого типа выполняется следующим образом. Перед инжектом делается слепок(системинфо), для получения списка потоков в процессе. Затем возможны несколько вариантов:
1. Перечисляются потоки в этом списке, для инжекта используется первый поток, который в списке.
2. Для инжекта используются все потоки.
3. Перечисляются все потоки в списке, определяется их состояние, тот поток который активен используется для инжекта.
4. Перечисляются все потоки в списке, определяется их состояние, те потоки которые активены используется для инжекта.
Детект основан на создании потока, целью работы которого будет вызвать исключение при обращении к стеку/проверку стека(далле). Этот поток должен быть первый в списке потоков полученном с помощью слепка.
Первое что приходит на ум, это детект посредством самотрассировки. Но этот вариант тутже отпадает, ибо перед инжектом Dr7 и TF в контексте потока будут сброшены.
Внедрённый хэндлер должен выполнить какието действия, вызвав один из сервисов. Заранее не известно какую память будет использовать поток, но так как при инжекте такого типа никто не создаёт свой стек, поэтому будет использоватьсо имеющийся стек - это единственная память доступ к которой мы можем отследить. В NT механизм исключений крайне не эффективен, в идеале если указатель на стек невалидный на момент исключения, ядро должно создать новый стек либо попытаться восстановить указатель из TEB, в реальном ядре такого не происходит, процесс в котором возникает подобное исключение тихо завершается. Поэтому мы не можем отследить исключение, возникающее при обращении к странице стека, хэндлер исключений на стороне юзермода не получит управления. Это серьёзная проблема, ибо система прибьёт не только поток в котором возникнет такое исключение, но весь процесс. Без доступа к ядру этого видимо никак не избежать.
1. Можно использовать для отлова подобных исключений отладочные механизмы, предоставляемые сервисами(Debug API). Отладчик получит сообщение при возникновении такого исключения.
2. Так как будет использоваться текущий стек потока мы можем проверять значения в нём в бесконечном цикле.
Для обоих вариантов поток должен в бесконечном цикле передавать не на долго управление системе, для разгрузки процессора, и иметь минимальный приоритет.
Для первого способа цикл может выглядеть так:

Код (Text):

1.     mov esp,-1
2. loop_:
3.     mov eax,116h    ;Номер сервиса NtYieldExecution
4.     int 2eh     ;Вызов NtYieldExecution, значение регистров Esp, Edx не имеет значения.
5.     jmp loop_

Хэндлер попытается обратится к стеку, это привидёт к возникновению исключения и посылки сообщения отладчику, далее его не сложно обработать.
Для второго способа можно в этом цикле сканировать стек на наличие значения отличного от нуля, прежде весь стек должен быть обнулён. Обнаружение значения отличного от нуля(контрольная сумма) означает что поток был прерван и его стек использовался. Например:

Код (Text):

1.     assume fs:nothing
2.     mov edi,dword ptr fs:[TEB.Tib.StackLimit]
3.     cld
4.     mov ecx,edi
5.     xor eax,eax
6.     sub ecx,dword ptr fs:[TEB.Tib.StackBase]
7.     mov esi,edi
8.     shr ecx,2
9.     mov ebx,ecx
10.     rep stosd
11. loop_:
12.     mov eax,116h    ;Номер сервиса NtYieldExecution
13.     int 2eh     ;Вызов NtYieldExecution
14.     xor eax,eax
15.     mov ecx,ebx
16.     mov edi,esi
17.     repe scasd
18.     jz loop_
19.     [...]   ;Поток был прерван.

 

Опять двадцать пять. Опять частные случаи и опять постфактум.
1) А инжект через CreateRemoteThread так ловится?
2) А если я внедрюсь, попользуюсь Вашим процессом, чтобы отослать Ваши пароли себе на мыло, и делаю ExitProcess, поймаете меня?
3)

Я создаю. Причём чаще, чем не создаю. Как раз из тех соображений, что приложение может работать с данными стека выше esp (адреса, младшие esp). Это не особо корректно со стороны приложений, но возможно.
4) И наконец вероятностный подход вида:

Ну откуда уверенность, что я не возьму второй, третий поток, первый с конца?

 

l_inc
1. Тема про подмену контекста потока, удалённые потоки тут не причём.
2. Не сможешь отослать, если будет обнаружено внедрение поток будет прибит. Я уже сказал что при обращении к стеку, если Esp невалидный процесс система прибивает.
3. Учёл п.1 ? Если да, то это очень редко кто делоет, даже я в такого типа инжекте свой стек не создавал.
4. Раньше брал ?

 

CrystalIC
1) Ладно. Согласен.
2) Вариант с циклом проверки стека на ненулевые значения не успеет его обнаружить, т.к. цикл проверки просто не получит управление. Если делать цикл проверки в другом вспомогательном потоке, то он может не успеть его проверить.
3) Учёл. Создавал, создаю и буду создавать. Не всегда, но часто. Почему, я уже написал.
4) Нет. Но, как я написал, это вероятностный подход. А значит ненадёжный. Особенно если планируется инжект в конкретно Ваше приложение.

 

l_inc
[2. Успеет. В инжекте такого типа, после отработки кода всегда контекст восстанавливается в такой, который был до перехвата и стек будет заполнен какимито данными.
3. Примеров инжекта такого типа множество, даже на этом сайте. Но не разу я не видел чтобы создавали стек.
4. Весьма надёжно, впрочем решать это автору топика.]
Немного отойду от темы, мне интересен твой ответ по поводу удалённых потоков. Давно реализован грубый способ словить любой поток. Опиши подробно как ты выполняешь инжект с помощью удалённых потоков.

 

Кстати тут стотья, описывающая принцип, которая легла в основу для многих, хотя весьма кривые и не далёкие способы.
"Секреты Win32" -> "Ms-Rem - Перехват API функций в Windows NT (часть 2). Методы внедрения кода." -> "Исполнение удаленного кода без CreateRemoteThread".
Внедрение этим способом будет обнаружено/присечино обоими методами.
Даже если и создаётся новый стек, то кто будет селектор стека загружать.)