Создание поведенческого блокиратора - Низкоуровневое программирование

Здравствуйте, qweas, Вы писали:

Q>Привет) В данный момент у меня стоит задача написания антивирусного блокиратора. Целевая система — Windows XP. Мне не нужно создавать эмуляторы, песочницы, прибегать к сигнатурному анализу.
Q>В основе лежит поведенческий блокиратор всех фунциклирующих процессов. От этого момента задача делится на 2:
Q>1) регистрация действия процесса
Q>2) анализ поведения
Q>Поиск по п.1 привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса. В общем, частично задача решена, только что в SYSTEM не могу пока подгружать…и жесткие тормоза и т.п.))) Т.е. в общем случае это – что-то наподобе filemon,regmon, API Monitor.
Q>Поиск по п.2 привел к фэйлу. Сама идея как бы и понятна и непонятна. Я не нашел ни 1 методического описания построения цепочек подозрительных действий и т.д. . Только что на некоторых сайтах есть обобщенные описания действий. Кроме того, существует 1000 и 1 способ сделать 1 и тоже.
Q>Вопросы:
Q>1) Насчет п2. Имеет ли смысл разрабатывать эту тему? Че и как делать – не очень понятно. Хотелось бы развернутого ответа)
Q>2) Если п1==true, правильно ли выбран метод слежения? Я не использую хуки, так как они не позволяют перехватить взаимодействия с файлами.
Q>Скорее всего, я что-то упустил, но все же жду от вас понимания, сочувствия, комментариев по пунктам, вопросам. Заранее СПС.

1. А чё не понятно? Тысяча и один способ как зделать. Обобщите статистику вызываемых процессоом API, Вычлените потенциально опасные действия (типа установка службы, запись в сситемный каталог, установка атрибута скрытый файл), транслируйте первое во второе. Каждый раз как процесс совершил очередное потенциально опасное действие, проверейте, чего ещё опасного делал — ну и принимайте решения. Некоторые выставляют потенциально опасным действиям балы — если их число превысило определенный порог (и число балов и порог — величины имперические), то принимаеться решение — вредоносное по. Другие орентируються на цепочки действий (допустим если процесс пишет файл autorun.inf и ставит ему скрытые атрибуты; или пытаеться переписать системный файл; или устанавливает себя как службу).
2. А вам для чего? Если как серьёзный продукт, то — fail. "п1==" false. Единственно коректный способ написать серьёзный поведенческий блокиратор — это написать драйвер и инфраструктуру к нему. Но есть сильные подозрения, что такая задача Вам будет непосильна. Если в качестве там диплома/курсовика/развлечения — то нормально и так сойдёт. Я в том смысле, что если обратиться к теории — то ваш перехватьчик можно обойти и не одним способом.

Вы упустили теоритическую базу. Стоило сначала познакомиться с теорией как готовяться поведенческие анализаторы (как они устроены). Поставить в виртуалке пару штук и посмотреть за их работой, может написать пару приложений и оценить их реакцию на различные действия.

Здравствуйте, qweas, Вы писали:
Q>Именно! У меня нет теории. Есть источники, где можно почитать о логике блокиратора? Иначе все сводится к перебору всех разновидностей вирусни, обобщению признаков. Насчет драйвера — уже видел, читал, нацелился, но что вы подразумеваете под инфраструктурой?

Q>Именно! У меня нет теории.
К сожалению мне не известно о каких либо книгах по этой теме. Есть немало публикаций в виде статей и презентаций, но либо поверхностно, либо перспективное будущее + они как правило на разных конференциях, поэтому вообще источники есть — но найти трудно.
Q>Именно! У меня нет теории. Есть источники, где можно почитать о логике блокиратора?
По поводу источников вообще — есть пара аспектов:
1. Как в предыдущем ответе я говорил — посмотрите на различные проактивки, антивирусы и прочее. Да, я понял, что это не то, что Вы ищите. НО, настройки и поведение этих защит частично раскрывает и механизм их работы. К примеру Norton AntiBot (он правда не блокиратор) — открытым текстом пишет в настройках по каким критериям он отличает вредоностное по от нормального.
2. На разных форумах типа wasm.ru, cracklab.ru, и ещё пара-тройка сайтов, по памяти не назову. На них вскользь и в большую сторону в адрес проактивных защит но возникают вопросы и ответы, которые могут вам помочь.
3. Чтобы сделать шит надо знать что такое меч. Если вы претендуете на создание хорошего продукта — вы должны знать как работает вещи которые ваша защита будет детектить. В этом ваше самое слабое место — если эти знания есть, то необходимость в теории отпадает — вы делаете защиту от конкретных угроз. Если не знаете, то надо узнать.
Q>Именно! У меня нет теории. Есть источники, где можно почитать о логике блокиратора? Иначе все сводится к перебору всех разновидностей вирусни, обобщению признаков.
Вообщето именно так и надо делать. Знаете как работает то что хотите обнаружить -> знаете опорные точки (api вызовы в данном контексте) без которых это нечто не может функционировать -> анализируете процессы на действия попадающие в эти "опорные точки".
Q>Насчет драйвера — уже видел, читал, нацелился, но что вы подразумеваете под инфраструктурой?
Одним драйвером вам не отделаться — как минимум надо будет написать программу работающую с ним в тандеме и обеспечивающею взаимодействие с пользователем (если видели и читале, то уже поняли что драйвера имеют неограниченые возможности в сторону системы и минимальные в сторону пользователя). Но самое сложное конечно это драйвер.

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

Здравствуйте, Аноним, Вы писали:
А>С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал

А>Ну и что вы собрались детектить, если есчо со времён рустока копия образа мапится в память и там юзается, в обход системной загруженной.
Чё то я этого не догнал. Со времен nt 1.0 мапяться в память и там юзаеться. И чем это мешает? В обход системы загруженой работать будет? Ну так в ring0 сначала втиснуться надо для таких делов то, да и то, не очень то в обход выйдет.
А>В добавок всегда юзаются сплоеты, кпл повышается через осевые уязвимости, либо в обход защиты(как например для киса — юзаем буфер с PAGE_GURD).
Ага. И порно банеры винлокеров вообще сильно повышают себе привелегии. Аж в ядро лезут. Ах нелезут? Таких как русток, эксплуатирующих уязвимости ядра — еденицы. В смысле единицы пролезающих в ядро. А вот пролезающих через дыры в ОС... Не помню че там делал русток, но к примеру tdl подпихивает себе вовсе не через сплоиты.
А>как например для киса — юзаем буфер с PAGE_GURD
каспер не образец идеальной проактивки. Любой драйвер может отмапить память любого процесса с любыми провами. У кусок виртуальной памяти с PAGE_GUARD? А друйвера кусок виртуальной памяти с PAGE_EXECUTE_READWRITE. А физическая память этих виртуальных кусков — одна и таже. Так что на кривые руки кав нечего пенять.
А>Вас спасёт только виртуальная машина, ну первую неделю спасёт после релизенга. Потом я и остальные запилят антиэмуль.
А что вы подразумеваете под виртулальной машиной? Intel VT или как-его-там? protect mode — по мне вполне себе виртуализация, дле железа. И перехват всего что идет через 2eh — тоже вполне себе виртуализация, для ос. И с этой точки зрения поведенческий блокиратор — это как раз виртуальная машина, которая прекращает работать, как только что-то не так.
А>Потом я и остальные запилят антиэмуль.
Пилите Шура, пилите)) Само собой, ничто несовершенно.

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

А>>>С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал

А>>>Ну и что вы собрались детектить, если есчо со времён рустока копия образа мапится в память и там юзается, в обход системной загруженной.
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>>Пилите Шура, пилите)) Само собой, ничто несовершенно.
А>Вы вначале в паблик релиз киньте. С удовольствием ковырнём.

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

Здравствуйте, qweas, Вы писали:

Q>Я в шоке от происходящего. Спасибо вам ребят за столь информативные ответы...споры))
Q>Я вообще писал на разные форумы, мне упомянули об ETW. Стоит на эту штуку расчитывать?
В первые слышу. Посмотрел сейчас — это же вроде настройка над счетчиками производительности? Если так то вам от нее толку не будет.

Q>А целью создания блокиратора(скорее перехватчика-анализатора) является сдача учебной работы)) Не зохват мира, не лютый взлом...Тем не менее, хочется сделать получше, и поэтому я уже приготовился к грядущей головной боли.
Порой лучше сделать хоть что то. Во всяко случае оставте обходной путь для отката на вариант без драйверов. Если в учебных целях.
Q>Он действительно пишется под ХР.
Есть такая штука — Windows Kernel Reseach. Там есть исходники ядра Windows XP SP3. В вашем случае наверно можно просто впихнуть свой исходный код туда и пересобрать. Но для подобного опыт разработки драйверов обязателен.

Q>Вы упомянули антивирусные системы, как уних устроен такого рода перехват?
Конкретно до XP почти все баловались перехватом Nt* функциий подменой адресов сервисной таблицы дескрипторов (SDT). И для вас лучше наверно именно этот способ: он относительно прост и позволяет перехватить все общение между ядром и пользовательским пространством (читай между всеми приложениями и ос-ю). С вистой майкрософт на модификацию ядра в целом и этой таблицы в особеннгости стал смотреть косо (Path Guard), зато расширили api (ядерных) для драйверов безопастности. Второй вариант (и для хр кстати) — это использование апи безопастности: драйвер фильтр на файловую систему — полный контроль за доступом к фс, callback диспечеру конфигурации — полный контроль за доступом к реестру, нотификация от менеджера процессов — контроль за созданием новых процессов (точней загрузкой образов pe файлов). Единственное чего в хр нет точно — это контроль за доступом к чужой памяти и над gui. Как с этим в висте/7 не знаю, может и улучшили. Есть старая книга Сорокина — программирование драйвервов и систем безопастности. На руском наиболее тематическая по этому вопросу.

Q>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего? Щас просто в уч целях, перебрав мэйл слоты, каналы, маппинг, атомы, выбрал каналы как самый подходящий.
Для больших объемов данных быстрей всего — проэцируемые в память файлы. каналы, слоты, сокеты и т.д. копирует передаваемую информацию, при мапинга копирования нет. Но его придеться сочетать с способом передачи сообщений между процессами (уведомить о том что данные обновились) — самый быстрый (если я не ошибаюсь) именнованные события. По идеи у рихтора должно быть написано что быстрей и почему — посмотрите.

Q>Кажется, среди многих вы чуть ли не единственный на помощь которого можно расчитывать...

Это совершенно не так, просто тут любят конкретные вопросы и я их понимаю. Ты же задаёшь вопросы, которые относятся к архитектуре ПО в целом, при чём не просто какого-то ПО, а вполне конкретного системного ПО, методы разработки которого, вообще говоря, абсолютно не формализованы и каждый разработчик пишет то, во что горазд. Соответственно, фактически получается так, что подобной темой ты спрашиваешь типа "а расскажите-ка мне ваши ноу-хау". Я уже не говорю о поистине чудовищных размерах предметной области, в которую ты решил залезть. Описание всех существующих методов и технологий разработки подобного ПО заняло бы столько же, сколько сборник сочинений Толстого. Короче говоря, я ещё раз повторюсь и, думаю, я выражу общее мнение: старайся задавать конкретные вопросы, а не хватать по кусочкам и не философствовать, ибо философия по части ИБ это совсем в другой форум. Системный разработчик называется так не столько потому, что пишет какие-то системные вещи, но потому, что подходит к вопросу разработки чего бы то ни было системно и последовательно.

Привет) В данный момент у меня стоит задача написания антивирусного блокиратора. Целевая система — Windows XP. Мне не нужно создавать эмуляторы, песочницы, прибегать к сигнатурному анализу.
В основе лежит поведенческий блокиратор всех фунциклирующих процессов. От этого момента задача делится на 2:
1) регистрация действия процесса
2) анализ поведения
Поиск по п.1 привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса. В общем, частично задача решена, только что в SYSTEM не могу пока подгружать…и жесткие тормоза и т.п.))) Т.е. в общем случае это – что-то наподобе filemon,regmon, API Monitor.
Поиск по п.2 привел к фэйлу. Сама идея как бы и понятна и непонятна. Я не нашел ни 1 методического описания построения цепочек подозрительных действий и т.д. . Только что на некоторых сайтах есть обобщенные описания действий. Кроме того, существует 1000 и 1 способ сделать 1 и тоже.
Вопросы:
1) Насчет п2. Имеет ли смысл разрабатывать эту тему? Че и как делать – не очень понятно. Хотелось бы развернутого ответа)
2) Если п1==true, правильно ли выбран метод слежения? Я не использую хуки, так как они не позволяют перехватить взаимодействия с файлами.
Скорее всего, я что-то упустил, но все же жду от вас понимания, сочувствия, комментариев по пунктам, вопросам. Заранее СПС.

Здравствуйте, 11molniev, Вы писали:

1>Вы упустили теоритическую базу. Стоило сначала познакомиться с теорией как готовяться поведенческие анализаторы (как они устроены). Поставить в виртуалке пару штук и посмотреть за их работой, может написать пару приложений и оценить их реакцию на различные действия.

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

С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал

Ну и что вы собрались детектить, если есчо со времён рустока копия образа мапится в память и там юзается, в обход системной загруженной. В добавок всегда юзаются сплоеты, кпл повышается через осевые уязвимости, либо в обход защиты(как например для киса — юзаем буфер с PAGE_GURD). Вас спасёт только виртуальная машина, ну первую неделю спасёт после релизенга. Потом я и остальные запилят антиэмуль.

Здравствуйте, 11molniev, Вы писали:

1>Здравствуйте, Аноним, Вы писали:
А>>С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал

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

Вы ведь сказали:
> привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса.
Как обычно релоцируем образ или ремапим его. Все ваши патчи идут лесом.

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

Винлокеры это примитивнейшие приложения. Это не малварь. Нашли что в пример приводить.

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

Для большинства файеров перехват сисколов обходится через рк атаку с помощью сторожевых страниц. Но вы видимо не в курсе.

1>Пилите Шура, пилите)) Само собой, ничто несовершенно.

Вы вначале в паблик релиз киньте. С удовольствием ковырнём.

Я в шоке от происходящего. Спасибо вам ребят за столь информативные ответы...споры))
Я вообще писал на разные форумы, мне упомянули об ETW. Стоит на эту штуку расчитывать?
А целью создания блокиратора(скорее перехватчика-анализатора) является сдача учебной работы)) Не зохват мира, не лютый взлом...Тем не менее, хочется сделать получше, и поэтому я уже приготовился к грядущей головной боли. Он действительно пишется под ХР. Вы упомянули антивирусные системы, как уних устроен такого рода перехват? И насчет межпроцессного взаимодействия...какой способ работает быстрее всего? Щас просто в уч целях, перебрав мэйл слоты, каналы, маппинг, атомы, выбрал каналы как самый подходящий.

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

В случае возникновения фундаментальных вопросов, как можно с вами связаться? Обещаю не наглеть) Пока какой-то вопрос вознкнет думаю месяц точняк пройдет)

Здравствуйте, qweas, Вы писали:

Q>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?

LPC.

Q>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?
А>LPC.
LPC сделан на shared memory. Так что ничем не быстрее named shared memory + SignalObjectAndWait с двух концов.

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

А>Здравствуйте, qweas, Вы писали:

Q>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?

А>LPC.

Это же недокументированый механизм (я в курсе статьи). Зачем вы советуете использовать недокументированые функции ОС?

Здравствуйте, qweas, Вы писали:

Q>Большое спасибо. Кажется, среди многих вы чуть ли не единственный на помощь которого можно расчитывать

В случае возникновения фундаментальных вопросов, как можно с вами связаться? Обещаю не наглеть) Пока какой-то вопрос вознкнет думаю месяц точняк пройдет)

Да тут на форуме и можно. Я его просмотриваю чаще, чем проверяю почту)

Здравствуйте, 11molniev, Вы писали:

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

А>>Здравствуйте, qweas, Вы писали:

Q>>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?

А>>LPC.

1>Это же недокументированый механизм (я в курсе статьи). Зачем вы советуете использовать недокументированые функции ОС?

Вполне документирован. Не менее чем SST и прочие внутренние особенности. Это мощный механизм, позволяющий безгеморно обслуживать множество клиентов. Разумеется быстрее своя синхронизация на паре событий(Event Pair, тоже обьект не дукументированный кстати

). В любом случае такая синхронизация, при которой ожидается ответ клиента повесит всю ось, либо процесс.

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

Q>>>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?
А>>>LPC.
1>>Это же недокументированый механизм (я в курсе статьи). Зачем вы советуете использовать недокументированые функции ОС?
А>Вполне документирован. Не менее чем SST и прочие внутренние особенности.
Под документированостью/недокументированостью я имею в виду его описание в msdn-е. Немножко гарантирующее, что microsoft не поступит с этим фпи так же как с sst. На семерке его даже руткиты стороной обходят (я имею в виду не крутые, которые обходятся без него чтоб не палиться).

А>Это мощный механизм, позволяющий безгеморно обслуживать множество клиентов.
Да. Но недокументированость ставит его использование под сомнение.

Кстати, вы наверное правы по отношению к LPC в данной ситуации. Если человек делает под хр — то недокументированость становиться делом десятым. Вот в отношении скорости передачи, я с вами не согласен — через общею память (проэцируемые файлы) оно быстрей будет.

А>Разумеется быстрее своя синхронизация на паре событий(Event Pair, тоже обьект не дукументированный кстати

). В любом случае такая синхронизация, при которой ожидается ответ клиента повесит всю ось, либо процесс.
Не использовал, поэтому могу ошибаться. Но вообще вся синхронизации работающая по Wait* и ваши пары событий в частности должна иметь примерно с одинаковую скорость. Пока планировщик не выдаст квант времени потоку, с которого снят флаг ожидания — ничего до него не дойдет. Единственное, в случае использования остатков текущего кванта для разморозки ожидающего потока, при смене состояния объекта синхронизации, будет быстрей работать; Ваши пары событий по такому принципу сделаны? Это дает более быстрый отклик, но общая производительность должна деградировать из-за переключений контекста, поэтому я не уверен, что подобный подход используеться для каких либо объектов синхронизации.
И поэтому думаю особой разницы между тем, что использовать для межпроцесной сминхронизации нет. Нужно использовать, что удобней.

1>И поэтому думаю особой разницы между тем, что использовать для межпроцесной сминхронизации нет. Нужно использовать, что удобней.
нафиг eventpair'ы, они кстати разве сапортяться?
SignalAndWaitForSingleObject сигналит один ивент и переходит в режим ожидания "атомарно", то есть не отпуская планировщик сразу после сигнала. Вобщем то реализован он как

KeSetEvent(.., .., TRUE); 
KeWaitForSingleObject(...

Здравствуйте, qweas,

Q>А целью создания блокиратора(скорее перехватчика-анализатора) является сдача учебной работы))
--
Если это учебная задача, то порекомендую обратить внимание на fuzzy logic (нечеткую логику), которую можно достаточно формально использовать вместо эвристических алогиртмов.

C уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:
обратить внимание на fuzzy logic (нечеткую логику)

да-да, помниться контрольную по инт системам решал)))

Понял, спасибо. Опять же повторюсь, вы тут все очень отзывчивые)

А>>Это мощный механизм, позволяющий безгеморно обслуживать множество клиентов.
1>Да. Но недокументированость ставит его использование под сомнение.

Это всё опенсурсное, врк официально открытый код.

1>Кстати, вы наверное правы по отношению к LPC в данной ситуации. Если человек делает под хр — то недокументированость становиться делом десятым. Вот в отношении скорости передачи, я с вами не согласен — через общею память (проэцируемые файлы) оно быстрей будет.

Готов поспорить на ящик пива что в W8 LPC не изменится.

А>Готов поспорить на ящик пива что в W8 LPC не изменится.

Да, подобные технологии типа LPC/APC, которые тесно интегрированы в ядро, вряд ли когда-нибудь будут переписаны.

Здравствуйте, x64, Вы писали:

А>>Готов поспорить на ящик пива что в W8 LPC не изменится.

x64>Да, подобные технологии типа LPC/APC, которые тесно интегрированы в ядро, вряд ли когда-нибудь будут переписаны.

Тогда что значит "не документировано", если механизмы не изменяются, ядро опенсурсное официально(рку) ?

А>Тогда что значит "не документировано", если механизмы не изменяются, ядро опенсурсное официально(рку) ?

Слова "не документировано" значат ровно то, что они значат, ничего более. Нет гарантий, вот и всё, это очевидно. А исходники открыты только для Windows Server 2003 SP1, но даже если бы они были открыты и для всех последующих систем, один хрен — нет гарантий. Но если это кого-то устраивает, т.е. на будущие версии закладываться не требуется, — то разумеется, почему нет? Да, и "рку" это Rootkit Unhooker (RkU), а исходники Windows называются WRK, не путаем.

Здравствуйте, x64, Вы писали:

А>>Тогда что значит "не документировано", если механизмы не изменяются, ядро опенсурсное официально(рку) ?

x64>Слова "не документировано" значат ровно то, что они значат, ничего более. Нет гарантий, вот и всё, это очевидно. А исходники открыты только для Windows Server 2003 SP1, но даже если бы они были открыты и для всех последующих систем, один хрен — нет гарантий. Но если это кого-то устраивает, т.е. на будущие версии закладываться не требуется, — то разумеется, почему нет? Да, и "рку" это Rootkit Unhooker (RkU), а исходники Windows называются WRK, не путаем.

Да вы правы. Это опечатка была(думал про одно, писал другое).

И снова здравствуйте! Я ленив и мечтателен, посему за это время толком ничего не сделал. Ладно, терь к делу. Я читал о драйверах режима ядра, васм читал, шрайбера читал, по боьшей части по верхам. Созрели вопросы...
1. Касательно варианта замены таблицы сервисов. Шрайбер описал способ перехвата API с подтасовкой SDT, которая круто всё делает. Но тут же пишет, что не работает эта тема для некоторых функций того же ntdll и ntoskrnl.
2. Касательно варианта с отловом IRP. К какому устройству я должен подключаться? Какую инфу я могу извлечь таким способом? Обращение на зап/чт/пер/уд?
3. Я так понял, это максимум того, что можно выжать? Я понимамаю, что далеко не познал дзен, почитав пару статеек и книжку 10летней давности...
4. Если п.3==труе, на чем все-таки остановиться?(в контексте повед анализатора). Мне кажется, 1ый вар привлекателен тем, что можно будет легко обучить его, скормив строчку на овер 600 бит.

Оч жду ответов. Спс.

Здравствуйте, qweas.

На мой взляд хуки не совсем то, что нужно. Я бы на вашем месте писал драйвер уровня ядра, который поставил бы jmp с начала каждой API функции (конечно же native API, поскольку обычные API — лишь оболочка для native). Драйверу уровня ядра невозможно помешать работать, у него абсолютная власть в системе.
И в дополнение, Ваш драйвер может следить, чтобы никакая другая программа не устанавливала jmp на начало системной функции. Если устанавливает — 95% гарантия, что это руткит.

> Ваш драйвер может следить, чтобы никакая другая программа не устанавливала jmp на начало системной функции. Если устанавливает — 95% гарантия, что это руткит.

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

Здравствуйте, qweas, Вы писали:

Q>И снова здравствуйте! Я ленив и мечтателен, посему за это время толком ничего не сделал. Ладно, терь к делу. Я читал о драйверах режима ядра, васм читал, шрайбера читал, по боьшей части по верхам. Созрели вопросы...
Q> 1. Касательно варианта замены таблицы сервисов. Шрайбер описал способ перехвата API с подтасовкой SDT, которая круто всё делает. Но тут же пишет, что не работает эта тема для некоторых функций того же ntdll и ntoskrnl.
Этот вариант работает для абсолютно всех функций вызываемых всеми программами, кроме драйверов. Не помню/нечитал этот фрагмент, но подразумеваеться, что заменой в этой таблице можно перехватывать ограничены перечень из нескольких сотен api функций, через которые все приложения общаются с ядром и дровами. Для поведенческого блокиратора способ самый простой (+ не задеваете работу kernel mode и имеете меньший геморой связанный с перехватом вызовов идущих от драйверов).

Q> 2. Касательно варианта с отловом IRP. К какому устройству я должен подключаться? Какую инфу я могу извлечь таким способом? Обращение на зап/чт/пер/уд?
)) В том тот и соль и сложность этого метода — разобраться к чему и как подключаться. Вариантов довольно много и в конечном счете все зависит от решаемых задач.

Q> 3. Я так понял, это максимум того, что можно выжать? Я понимамаю, что далеко не познал дзен, почитав пару статеек и книжку 10летней давности...
Для чего выжать? можно делать нелегальные перехваты через смену обработчика 2eh/sysenter, правку sdt, спайсинг функций, переопределение irp обработчиков, патчинг образа ядра/дров на диске...
Можно выжимать легальные возможности через драйверы фильтры всех калибров + стандартное api для антивирей и файверловов..
Можно полулегально взять исходники ядра из WRK, дописать все что нужно и просто "обновить" его на целевой машине...
И это навскидку — вспомнил пока писал.

Q> 4. Если п.3==труе, на чем все-таки остановиться?(в контексте повед анализатора). Мне кажется, 1ый вар привлекателен тем, что можно будет легко обучить его, скормив строчку на овер 600 бит.
1. Если целевая ос WinXP и переноса на более новые версии не планируется — пользуйтесь sdt. Для хрюшки чуть ли не документированый метод реализации проактивок — версии каспера тех времен к примеру именно так и работали.
2. Если пункт 1 и хорошо понимаете что да как — допишите свой код в исходники ядра из WRK и откомпилируйте))
3. Если есть планы когда нибудь перенести дальше хп — драйверы фильтры очевидный выбор. А уж на какое именно устройство — когда изучите достаточно для написания такого драйвера без сильных глюков поймете.

Q>В голове мешанина и + к этому не совсем понимаю токостей переключения контектов процессов, связи этого с IRQL и взаимных блокировок. Вроде во всех 3 источниках есть по немногу, но блин всеравно непонятно)
Рекомендую ознакомиться с работой защитного режима процессора для понимания тонкостей переключения контекстов (хорошая книга "Защищенный режим процессоров Intel 80286/80386/80486"). Там расписано более чем подробно.
О irql вам в принципе достаточно знать — что оно есть и если текущий уровень выше PASIV (или как он там) — то можно использовать ограниченный перечень апи и как можно скорей возвращать управление.
Взаимные блокировки — это взаимные блокировки, что в обычных программах, что в ядре разницы особо нет.
О каждом из этих трех аспектов можно лекции читать)) Поэтому сформулируйте более конкретные вопросы.

Q>Сейчас буду WDKшный FileSpy потрошить
В сети есть ещё исходники filemon — с неплохими комментариями.

И самое главное. Ваши вопросы и "по боьшей части по верхам" говорит о поверхностном ознакомлении с предметом. По отношению к низкоуровневому программированию такой подход неприменим. Лучше один раз внимательно прочесть имеющеюся литературу и разобраться с тем, что в ней написано, чем потом днями напролет пытаться отладит программный код низкого качества. Это сэкономит время.

	От:	11molniev
	Дата:	31.07.11 13:06
	Оценка:	3 (1)

	От:	11molniev
	Дата:	31.07.11 16:21
	Оценка:	3 (1)

	От:	11molniev
	Дата:	01.08.11 06:45
	Оценка:	3 (1)

	От:	11molniev
	Дата:	01.08.11 19:29
	Оценка:	3 (1)

	От:	11molniev
	Дата:	02.08.11 06:55
	Оценка:	3 (1)

	От:	Геннадий Майко
	Дата:	02.08.11 12:30
	Оценка:

	От:	Аноним
	Дата:	04.08.11 08:25
	Оценка:

	От:	x64
	Дата:	04.08.11 18:33
	Оценка:

	От:	Аноним
	Дата:	04.08.11 19:40
	Оценка:

	От:	x64
	Дата:	04.08.11 20:44
	Оценка: