Re[9]: Создание поведенческого блокиратора
От: 11molniev  
Дата: 02.08.11 06:55
Оценка: 3 (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>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего? Щас просто в уч целях, перебрав мэйл слоты, каналы, маппинг, атомы, выбрал каналы как самый подходящий.

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