shchetinin В том топике ровным счётом никакой конкретики...Например,как узнать вообще из Process Explorer,что процесс имеет alertable потоки? Или получается,что из user-mode невозможно определить alertable потоки?
Только методом анализа стека. Штатными средствами нельзя, обходных путей/извращенных хаков, скорее всего, нет. Поле "ядерное". Хотя, мейби, какой-нибудь гуру виндовой архитектуры и напишет что-то. В php process hacker даже есть пример кода http://processhacker.sourceforge.net/doc/anawait_8c_source.html
Pantamas Можно определить - поставить в очередь APC. Если доставится, значит alertable-wait Это также не надёжно, как и искать потоки для исполнения в их контексте кода. Потоки могут простаивать в данном случае и не имеет значения что они ждут. Нормально из юзермода это свой поток создать.
APC добавится в любом случае, QueueUserAPC() всегда будет возвращать TRUE. А о том, запустилось ли оно ты не узнаешь.
Lunar_ Он записан заранее. Для этого и управление передаётся через апк. А танцы с бубном вокруг стека совершенно не нужны. Далее смысла юзать апк вообще нет. Некоторые аверы, как например ZA не фильтруют доставку апк, так же как и прямую запись через NtWriteVM. Другие аверы, как например клиф мониторят доставку апк и прочие способы смены Ip, но делают это криво, посему ничем апк не лучше, чем прямая смена контекста: Код (Text): .text:000400E8 PtOpenThread: .text:000400E8 mov edi, edi .text:000400EA push ebp .text:000400EB mov ebp, esp .text:000400ED and esp, 0FFFFFFF8h .text:000400F0 sub esp, 0Ch .text:000400F3 push ebx .text:000400F4 push esi .text:000400F5 push edi .text:000400F6 xor edi, edi .text:000400F8 mov [esp+10h], edi .text:000400FC xor ebx, ebx .text:000400FE call ds:ExGetPreviousMode .text:00040104 push dword ptr [ebp+14h] .text:00040107 test al, al .text:00040109 jnz short loc_4011F .text:0004010B push dword ptr [ebp+10h] .text:0004010E push dword ptr [ebp+0Ch] .text:00040111 push dword ptr [ebp+8] .text:00040114 call pNtOpenThread .text:0004011A jmp loc_401E5 .text:0004011F ; --------------------------------------------------------------------------- .text:0004011F .text:0004011F loc_4011F: .text:0004011F push 8 .text:00040121 pop ecx .text:00040122 call ProbeForReadAndCopyToBuffer ; SEH; (CONTEXT.rEcx:Length, IN PVOID Buffer):PVOID .text:00040127 mov esi, eax .text:00040129 cmp esi, edi .text:0004012B jz loc_401B5 ... .text:000401B5 loc_401B5: .text:000401B5 .text:000401B5 test byte ptr [esp+10h], 1Ch .text:000401BA jz short loc_401C3 .text:000401BC mov esi, 0C0000022h .text:000401C1 jmp short loc_401D7 .text:000401C3 ; --------------------------------------------------------------------------- .text:000401C3 .text:000401C3 loc_401C3: .text:000401C3 push dword ptr [ebp+14h] .text:000401C6 push dword ptr [ebp+10h] .text:000401C9 push dword ptr [ebp+0Ch] .text:000401CC push dword ptr [ebp+8] .text:000401CF call pNtOpenThread .text:000401D5 mov esi, eax - если ProbeForReadAndCopyToBuffer() завершиться с ошибкой, то будет вызван оригинальная нтапи. Эта процедура защищена сех и юзает ProbeForRead(). Передаём страницу помеченную как гвард, это приведёт к вызову оригинальной апи. Чисто теоретически мб это и интересно. Если небыло возврата из сервиса для доставки других апк, то Eax в т-фрейме не изменён и содержит Id сервиса, который был в стабе загружен. Посему берём его из контекста, в блоке case прибавляем к Esp смещение в зависимости от сервиса и достаём со стека аргумент, разрешающий алетрабельное ожидание. Хотя можно и адрес возврата в стаб взять со стека.
Просто читал про ZeroAccess и там было написано,что он использует внедрение при помощи QueueUserAPC() в svchost.exe...Как он это делает хз...
Pantamas Во первых инжект через QueueUserAPC без смыселен(Проще CreateRemoteThread) и то и другое паливо. Во вторых не гарантий что поток таки войдет в состояние Alertable, для это нкжен вайт с Altertable true.
То есть приходим к выводу о том,что использование APC бесполезно и не даёт никаких преимуществ... А как можно определить принадлежность потока модулю - т.е,как узнать,что поток THREAD1 запущен из модуля MODULE1,может API есть какие,я новенький в теме
Pantamas Повторяюсь - апк смысла не имеет в качестве инжекта. А зероаццесс очень плохой пример, это пример как не следует кодить малварь.
Pantamas, у svchost'a могут быть alertable потоки, на свинье это, вроде бы даже факт. Думаю ЗироЭссэс тупо просто перебирает потоки и шлёт apc, ожидая отклика. Хотя по палевности с CreateRemoteThread одинакого, как и сказали...
Malfoy А можно подробнее о "забудьте про проты, нет таких больше програм"? И какой на Ваш взгляд наиболее подходящий способ инжекта?
Pantamas По мойму инжект нужно делать так(из юзермодов): 1. Определяем прот, заюзав SHDE. 2. Выбираем прототипы из базы для рк атаки на прот. 3. Выполняем рк атаку на апи, через которые выполняем инжект. Это зависит от прота. 4. Посылаем IOCTL для остановки прота, добавления себя в его списки(рега клиента), либо впрыскиваемся в доверенный процесс, в идеале в процесс фаера.
