Всем добрый день. Проблема в следующем. Есть код (Ring 3) перехватывающий с десяток NTxxx функций. В некоторых перехватчиках используются локальные переменные. Соответственно возможна ситуация, когда в многопоточном приложении во время работы перехватчика другой поток вызовет этот же перехватчик, что может привести к изменениям в локальных переменных. Первое, что приходит в голову, это останавливать все потоки при работе перехватчика, либо использовать CriticalSections. Какой из этих методов предпочтительней использовать? Может есть еще подводные камни? P.S У меня на обычном селероне все и так работает. Пробовал перехват на последней версии Themida - все окей. Но есть еще такие звери как Core2 Duo, HyperTreading, многопроцессорные компьютеры… Вот тут и могут быть проблемы.
критические секции, имхо, предпочтительнее... можно также реализовать синхронизацию с использлванием обьектов ядра (мютексов, событий, етц)
Извиняюсь, не правильно выразился. Не локальные переменные, а вот такие: Код (Text): ;Код заполняющий LUD_Handle, Zw_rvalue2 jmp @F Zw_name2 db 'LdrUnloadDll: Handle :' LUD_Handle dq ? LUD_Result db ' Result : ' Zw_rvalue2 dq ? ,0h ;Buffer for save results @@: ;******[Writing Acii string to File]******* lea eax,[EBP+Zw_name2] push eax call _write2file Под переменными подразумеваются LUD_Handle, Zw_rvalue2. Сам код является базовонезависимым. Это кусок кода перехватчика LdrUnloadDll.
"Останавливать все потоки" - а если хукаешь блокирующую функцию (а тем более, с разблокировкой в другом потоке)? + возможны гонки и взаимоблокировки. "использовать CriticalSections" - в дополнение к предыдущему, бока будут при (неявной) рекурсии. ХЗ может в NTxxx функциях ее и нет, но такую гарантию тебе никто не даст. ЗЫ: Локальные переменные, тут не причем, можешь их юзать сколько душе угодно, для каждой функции они свои. Траблы с потоками у тебя возникнут минимум в 3-х других местах.
Сколько всего добавилось seeQ В твоем, как частном примере, можешь использовать КС, лишь бы _write2file, не вызвал в итоге хукаемую функцию. ЗЫ: Все равно минимум 3 других бока связанные с многопоточностью остаются, и советую подумать о них
Nouzui Это как понять? Вообще я писал, до того как увидел пример с кодом. Исходя из первоначальных объяснений трудно понять какой участок кода берется в критическую секцию, поэтому и ответил для общего случая когда весь хук будет в КС. Для частного, т.е. примера, все ОК.
здорово у меня "не" инвертировалась ) а что касается КС, то они не блокируют поток при повторном вхождении, только потом нужно будет освободить секцию столько же раз, сколько раз она была занята
Nouzui Код (Text): Объект Относительная скорость Доступ нескольких процессов Подсчет числа обращений к ресурсу Платформы Критическая секция быстро Нет Нет (эксклюзивный доступ) 9x/NT/CE Мьютекс медленно Да Нет (эксклюзивный доступ) 9x/NT/CE Семафор медленно Да Автоматически 9x/NT Событие медленно Да Да 9x/NT/CE Кто-то что-то путает, критические секции не считают даже в теории синхронизации у Таненбаума.
ого, понеслась Я решил отказаться от замораживания потоков и от КС. Раз не было у меня локальных переменных, то теперь будут, соответственно и возможные проблемы должны таким способом решиться. Нда.. заинтриговал.
Nouzui Некоторые АПИ функции, (шелловские в основном, но есть пара например ДбжБреак+ЕхитТнреад), любят создавать потоки и ждать резалта от потока. Если хукнуть подобную, и одну из тех которые вызывает вновь созданный поток, это будет как раз искомый бок.
