Здравствуйте, Аноним, Вы писали:

А>>>С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал
А>>>Ну и что вы собрались детектить, если есчо со времён рустока копия образа мапится в память и там юзается, в обход системной загруженной.
1>>Чё то я этого не догнал. Со времен nt 1.0 мапяться в память и там юзаеться. И чем это мешает? В обход системы загруженой работать будет? Ну так в ring0 сначала втиснуться надо для таких делов то, да и то, не очень то в обход выйдет.
А>Вы ведь сказали:
>> привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса.
А>Как обычно релоцируем образ или ремапим его. Все ваши патчи идут лесом.

Сказал не я. Посмотрите внимательней. Я говорил как раз, что полноценный перехват — это драйвер. Такие перехваты действительно обходяться легко и множеством способов. Я с вами согласен по этому вопросу — хотя высказывание их контекста вырвано.

А>>>В добавок всегда юзаются сплоеты, кпл повышается через осевые уязвимости, либо в обход защиты(как например для киса — юзаем буфер с PAGE_GURD).
1>>Ага. И порно банеры винлокеров вообще сильно повышают себе привелегии. Аж в ядро лезут. Ах нелезут? Таких как русток, эксплуатирующих уязвимости ядра — еденицы. В смысле единицы пролезающих в ядро. А вот пролезающих через дыры в ОС... Не помню че там делал русток, но к примеру tdl подпихивает себе вовсе не через сплоиты.
А>Винлокеры это примитивнейшие приложения. Это не малварь. Нашли что в пример приводить.

Не, а что непримитивных много? Я привел наиболее распрастрененные просто, никто не спорит, что пишуться они на делфях за десяток минут. И кстати их простота усложняет их детект. + Я спращивал автора вопроса — с какой целью он пишет свой блокиратор — может ему и винлокеров достаточно. А вы сразу гнобить.

А>>>как например для киса — юзаем буфер с PAGE_GURD
1>>каспер не образец идеальной проактивки. Любой драйвер может отмапить память любого процесса с любыми провами. У кусок виртуальной памяти с PAGE_GUARD? А друйвера кусок виртуальной памяти с PAGE_EXECUTE_READWRITE. А физическая память этих виртуальных кусков — одна и таже. Так что на кривые руки кав нечего пенять.
А>Для большинства файеров перехват сисколов обходится через рк атаку с помощью сторожевых страниц. Но вы видимо не в курсе.

Я действительно не в курсе. И подозреваю что говорим мы о разных вещах. Еще раз: я говорю о режиме ядра. Поведенческий блокиротор блокирует по факту вызовов api. Если говорит про XP — то тот же кав/кис (старые правда) патчет сервисную таблицу — ваши вызовы либо пройдут через него либо не пройдут через систему (не будут исполнены). Если говорить о семерке/современных проактивках/блокираторах и прочей хрени — то ваш вызов api в либо пройдет через callback-и/минифильтры либо не дойдет до адресата и не будет исполнен. Ставте эти права спокойно — на поведенческий блокиратор он повлиять не должен.
Если вы говорите о сигнатурном поиске, то из за кривых ручек установка данного атрибута защиты может и приводит к таким результатам. Непробовал. НО, ещё раз повторяю, драйвер (причем любой) может повторно отмапить кусок памяти любого процесса с любыми правами. У вас страница с вашим PAGE_GURD по вашему виртуальному адресу 0x04674000. У драйвера по адресу 0хB6882000 с атрубутом любого доступа. или у его доверенного приложения по адресу 0x0а124000 — а физически это один и тот же кусок оперативной памяти. Через этот механизм менеджера памяти в частности работает межпроцессорное взаимодействие через проэцируемые файлы. И все вашы атрибуты бесполезны — они работают в контексте вашей виртуальной памяти и не действую в контексте виртуальной памяти системной или других процессов.

1>>Пилите Шура, пилите)) Само собой, ничто несовершенно.
А>Вы вначале в паблик релиз киньте. С удовольствием ковырнём.

Чёй релез? Вы путаете меня с автором вопроса? Пожалуста, обратите внимание на имена авторов сообщений этого треда.