Filter vs. Hook: Что выбрать? Анализируем За и Против. - Низкоуровневое программирование

Приветствую всех

в очередной раз замечена попытка понять почему плохо "патчить ядро на каждый чих" (с) мой, а фильтр это хорошо

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

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

ведь иначе бы этого другого никому не было нужно, ясен пень.

впрочем не буду отвлекаться и сразу предлагаю использовать эту ветку форума для того чтобы дополнить то, о чем забуду упомянуть

но пожалуйста следите за объемом цитирования — модератор

ибо на эту тему можно написать и трактат и кандидатскую даже не уходя из Windows NT области (остальные популярные ОС впрочем тут как правило не лучше)

итак, тезисно, Pro et Contra или benefits vs. drawbacks, то что сразу вспоминается:

Contra или чем чреваты хуки

1. Хуки невыгружаемы. Точка.

Выгрузка хука это почти всегда катастрофа. Если кто-то выше повесил хук на наш, то после выгрузки нашего драйвера при первом же вызове, когда хук выше позовет предыдущий обработчик, т.е. нас, а мы уже ушли — результат будет известно какой: можете попытаться угадать, но я бы даже не стал этого делать ибо правильный ответ — непредсказуемый.

2. Хуки и недокументированность

Часто вызовы которые патчатся — недокументированы (например при использовании system call table hooking), а это значит, что последствия могут быть самыми разными — начнется путешествие по недокументированным и изменяющимся без уведомления "минным полям" т.к. производитель волен делать (и делает!) что угодно с приватными интерфейсами. Если хук таблицы системных вызовов делается, надо для начала четко определить правильный индекс — а они, бывает, меняются! Если речь не идет о какой-нибудь "хорошей" ф-ии выставленной ядром наружу официально. Короче, начало может быть весьма нелегким, если Вы не сам себе тестер на однопроцессорной машине с одной и той же конфигурацией ОС что подозреваю имеет место в данном случае, но могу и ошибаться

3. Хуки не всегда спасают

к примеру, сложно будет с хуком вместо файлового фильтра отследить I/O for mapped memory files

4. Несколько хуков неизбежно приведут к interoperability issues. ибо не имеют механизма синхронизации.

Это очень серьезная беда, если есть два или больше драйверов которые используют хуки, имеем классический сценарий:
— первый системный вызов: вызов хука 1 потом хука 2 и потом настоящей ф-ии
— второй системный вызов: вызов хука 2 потом хука 1 и потом настоящей ф-ии
в зависимости от того что делают хуки последствия могут быть самыми печальными. Потом еще и МС будут ругать все вместе

И это хорошо еще если авторы обоих хуков достаточно умны и хотя бы используют interlocked ф-ии при установке хуков

5. Палки в колеса! Новые! От производителя! "Налетай, торопись, покупай живопись"

начиная с XP соотв. части ядра потихоньку делают защищенными от модификаций (хуков). на ХР защита довольно легко обходится простыми манипуляциями с маппингом с доступом на запись да и PTE таблицы известно где находятся, но сам факт должен насторожить — всякие новые версии ОС оснащаются разными там patch guards и т.п. — тенденция однако! А ведь тут еще скрытая появляется проблема описанная в пред пункте, что хуже. Ну и уже упомянутые фишки в свете windows updates и просто новых СП и версий ОС: индексы недокументированных вызовов съезжают или API вообще пропадает\заменяется на другой — в общем весело, спать спокойно будет нелегко.

6. Банальные косяки и криворукость

проблемы с кривыми и корявыми по исполнению драйверами, использующими разные техники для постановки хуков: вот в XP SP2 пролог ф-ий был изменен (привет пред. пункту) и кое-кто не выдержал такой подставы — вероятно, использовали жестко зашитые прологи ф-ий

Справедливости ради, в фильтре тоже легко можно накосячить как надо.

7. Безопасность

как правило жестко попирается, когда любители навесных защит на все подряд прикручивают свою security на хуках взамен Windows NT native security model. Часто даже с целью лишь ослабить\отключить встроенную защиту ибо мешает

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

предлагаю желающим продолжить список, продолжая нумерацию

Pro или аргументы за хуки

1. Экспериментальный софт

быстро въехать в фильтры для новичков может не получиться, раньше написание файлового фильтра требовало многих месяцев просто чтобы сделать то, что делается грубо говоря в 10 строк на хуке. Т.е. быстро что-то проверить на хуках — бывает разумно...

2. Маркетинг

...а иногда создать целый прототип или даже продукт! Но не будем забывать, что "быстро дешево и сердито" — это зло идет от НИХ. От пользователей конечно!

ибо маркетоиды идут у рынка на поводу и часто готовы продать хоть что на соплях дабы занять рынок, а там "день простоять и ночь продержаться" в ожидании выпуска "правильного" решения (случается правильное решение начинает бесконечно откладываться ибо "и так продается", а с нами мол падают все — есть на кого свалить короче, начиная с МС, вестимо)

3. Больше информации о контексте.

Фильтр видит что файл открывается или читается через paging I/O. Хук же может на самом деле сказать что файл был открыт с execute доступом и теперь используется для создания section object (конечно если execution разрешен) и мапится в PAGE_EXECUTE память.

4. Хуки быстрее

есть и такой момент, хотя в некоторых ситуациях люди говорят ровно наоборот (если хуки плохо или криво написаны — производительность всей ОС пострадает, а с фильтрами это может быть не так заметно).

5. Сбор статистики или мониторинг чего-либо

Да хоть бы DbgMon вспомнить можно — без хука тут никак.

6. Нет другого (официального) выхода

без комментариев. на самом деле этот пункт равно как и пред. здесь чтобы сделать боевую ничью 7-7 дабы попытаться сохранить объективность

7. Безопасность
седьмым пунктом традиционно идет как ни странно опять безопасность: в кач-ве иллюстрации пункта о маркетинге приведу пример: Если особые заказчики (например те же вояки, кто не понял) требуют безопасности по цене использования недокументированных возможностей и разных грязных и не очень хаков вместо отсутствия им нужной безопасности вообще, то все догадались, что будет выбрано. Но см. то что сказано про безопасность в Contra.

предлагаю желающим продолжить список, продолжая нумерацию

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

Короче говоря, никому не рекомендую даже думать о хуках в production коде, если есть официальные пути. То, что многие просто не в курсе, что есть такие пути и по привычке пользуют старую добрую парадигму хуков по делу и без, то бишь "патчат ядро на каждый чих" (с) — не освобождает их от ответственности

Но если официальные средства исчерпаны, то без сомнения тут all bets are off!

... << RSDN@Home 1.2.0 alpha rev. 653>>

Здравствуйте, Valery A. Boronin,

VAB>Pro или аргументы за хуки

VAB>2. Маркетинг
--
"Objection Your Honor, the item is misleading!"

Это аргумент против хуков.

Вспомните недавний скандал с Sony CD copy protection. Расскажите его Вашему "маркетоиду". Пускай он сам оценит потери Sony. Пускай он сам оценит Ваши потери, когда об этом хуке узнают Ваши клиенты и конкуренты.

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

Все сказанное, конечно, верно.
ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет.
По крайней мере на ОСях NT, 2k, XP, 2k3.

O>Все сказанное, конечно, верно.

Верно, и давно известно. Но самое главное систематизировано... Я вот для декций материал подбираю... Самое то

O>ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет.

А где бы их глянуть?
а то у них на сайте только бинарники...

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

O>Все сказанное, конечно, верно.
O>ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет.
O>По крайней мере на ОСях NT, 2k, XP, 2k3.

В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).

O>>ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет.

DA>А где бы их глянуть?

Вот на этой страничке вы их найдете:
http://www.wasm.ru/toollist.php?list=21

Правда версия не новая, но техника хуков, думаю, особо не поменялась...

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

SS>В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).

А у вас есть исходники одной из последних версий regmon?
Если да, поделитесь ссылочкой, please.

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

O>Здравствуйте, Sergey Storozhevykh, Вы писали:

SS>>В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).

O>А у вас есть исходники одной из последних версий regmon?
O>Если да, поделитесь ссылочкой, please.

Неа, по-моему, их и не было никогда (как и для "правильного" filemon). Наводит, кстати, на определенные размышления.

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

VAB>1. Хуки невыгружаемы. Точка.
При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.

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

VAB>>1. Хуки невыгружаемы. Точка.
А>При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.

А если в момент выгрузки первого хука, второй уже находится внутри одной из своих хукнутых процедур и готовится позвать первый хук? БСОД.

Хотя и без этого корректной назвать выгрузку, которая заодно обрубает руки-ноги другим хукам язык не поворачивается. Однако, так им и надо

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

O>Здравствуйте, Sergey Storozhevykh, Вы писали:

SS>>В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).

O>А у вас есть исходники одной из последних версий regmon?
O>Если да, поделитесь ссылочкой, please.

здесь Читаем как работает regmon

Здравствуйте, Геннадий Майко, Вы писали:

VAB>>Pro или аргументы за хуки

VAB>>2. Маркетинг
ГМ>--
ГМ>"Objection Your Honor, the item is misleading!"

ГМ>Это аргумент против хуков.
Маркетинг как и Безопасность — двуликий янус. Или обоюдоострый меч, все верно

Гена, с удовольствием принимаю Ваше ценное дополнение, но тем не менее в случае с Sony была еще и банальная криворукость и низкий уровень реализации — что и показал доктор Руссинович, заодно не сильно напрягаясь грамотно пропиарив в очередной раз свой ресурс

Кто знает, может это и подтолкнуло MSFT к его покупке?

На упоминаемый тут regmon никто не жалуется особо, к примеру. Естественно коммерческий вариант на хуках, чтобы попасть в Pro::Marketing, должен быть ближе к RegMon нежели к сляпанной на коленке поделухе Sony — мастер и на хуке сделает конфетку (в теории).

ГМ>Вспомните недавний скандал с Sony CD copy protection. Расскажите его Вашему "маркетоиду". Пускай он сам оценит потери Sony. Пускай он сам оценит Ваши потери, когда об этом хуке узнают Ваши клиенты и конкуренты.
маркетоиды не мои

конкуренты же (те, которые квалифицированные

) и клиенты в курсе, если уровень позволяет и know-how не нарушается.

Если говорить за мое текущее место работы, то там посторонние эксперты по безопасности и технологиям, бывает, разбирают наши решения по косточкам — чтобы заключить контракт с какой-либо серьезной организацией типа английского минобороны (Ministry of Defense) их техническим специалистам приходится доказывать что и как, почему хук и почему по-другому если не нельзя, то хуже и в чем именно хуже. Что-то случается просят переделать — без этого контракта не будет. Тайны-то никакой нет, кому надо все равно сразу в отладчике все увидит, соотв. и потери чаще всего происходят не от того, что стало известно о применении хука внутри продукта, а от проблем типа плохой реализации — как в случае с Sony.

PS Более того, я бы приветствовал если бы производители писали хотя бы на чем у них решения, мол такая-то версия Касперского на хуке, а такая-то версия Панды на минифильтре.

PPS Еще немного оффтопика себе позволю: вообще с подозрением отношусь к софту от consumer производителей, невзирая на громкие имена типа Sony, Samsung... Лучше бы они писали кто для них пишет софт — было бы написано мол Руссинович или OSR трудился — вот тут бы доверие наверное минимальное появилось

А если сами пишут — то скорее всего будет как всегда, что и доказал лишний раз скандал с Sony.

... << RSDN@Home 1.2.0 alpha rev. 653>>

Здравствуйте, Valery A. Boronin,

VAB>>>Pro или аргументы за хуки

VAB>>>2. Маркетинг
ГМ>>--
ГМ>>"Objection Your Honor, the item is misleading!"

ГМ>>Это аргумент против хуков.
VAB>Маркетинг как и Безопасность — двуликий янус. Или обоюдоострый меч, все верно

ГМ>>Вспомните недавний скандал с Sony CD copy protection. Расскажите его Вашему "маркетоиду". Пускай он сам оценит потери Sony. Пускай он сам оценит Ваши потери, когда об этом хуке узнают Ваши клиенты и конкуренты.
VAB>маркетоиды не мои

--
Я имел в виду не Вас, а некоего третьего лица, который захочет убедить своих "маркетоидов", что такое решение будет нормальным.

VAB> Тайны-то никакой нет, кому надо все равно сразу в отладчике все увидит, соотв. и потери чаще всего происходят не от того, что стало известно о применении хука внутри продукта, а от проблем типа плохой реализации — как в случае с Sony.
--
Скорее, не в плохой реализации, а в плохом процессе uninstall этого драйвера, который изменяет системную таблицу.
Корректно заменить адрес функции в какой-то таблице (адрес которой известен, конечно) проблем не вызывает.

А вот корректно заменить участок кода (что очень хотят сделать многие), на мой взгляд, весьма сложно.

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

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

VAB>>>1. Хуки невыгружаемы. Точка.
А>>При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.

SS>А если в момент выгрузки первого хука, второй уже находится внутри одной из своих хукнутых процедур и готовится позвать первый хук? БСОД.
Тоесть мы рассматриваем вариант с постобработкой данных. При корректной реализации хук не выгрузится до тех пор, пока он имеет шанс получить управление не через точку входа, а именно:
— функция выгрузки сигналит о необходимости выгрузки
— диспетчер восстанавливает точки входа
— и ждет на объекте(ах) синхронизации обработчиков
— дождались и выгружаем тело
Это навскидку.

SS>Хотя и без этого корректной назвать выгрузку, которая заодно обрубает руки-ноги другим хукам язык не поворачивается. Однако, так им и надо

Напишите в мс, чтоб сделали KeGetHook/KeSetHook/KeRestoreHook

При общем диспетчере можно будет это делать безопасно.

Здравствуйте, Аноним,

VAB>>>>1. Хуки невыгружаемы. Точка.
А>>>При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.

SS>>А если в момент выгрузки первого хука, второй уже находится внутри одной из своих хукнутых процедур и готовится позвать первый хук? БСОД.
А>Тоесть мы рассматриваем вариант с постобработкой данных. При корректной реализации хук не выгрузится до тех пор, пока он имеет шанс получить управление не через точку входа, а именно:
А> — функция выгрузки сигналит о необходимости выгрузки
А> — диспетчер восстанавливает точки входа
А> — и ждет на объекте(ах) синхронизации обработчиков
А> — дождались и выгружаем тело
А>Это навскидку.
--
Похоже, мы вновь начинаем идти по кругу.

Даже если функцию установки объекта синхронизации вызывать последней в Вашей hook-функции, это не гарантирует, что внутри этой функции не будет кода, который не будет выполняться при уже установленном объекте синхронизации. Всегда будет такой код, как минимум — это инструкция ret (а что будет реально — посмотрите ассемблерный код Вашей hook-функции).
Это значит, что вполне возможна ситуация, когда на одном процессоре функция unload получит управление и выгрузит драйвер (потому что объекты синхронизации уже установлены), а на другом процессоре hook-функция еще до конца не выгрузилась.
Только не надо говорить о вероятностях таких событий, хорошо?

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

Здравствуйте, Геннадий Майко,

SS>>>А если в момент выгрузки первого хука, второй уже находится внутри одной из своих хукнутых процедур и готовится позвать первый хук? БСОД.
А>>Тоесть мы рассматриваем вариант с постобработкой данных. При корректной реализации хук не выгрузится до тех пор, пока он имеет шанс получить управление не через точку входа, а именно:
А>> — функция выгрузки сигналит о необходимости выгрузки
А>> — диспетчер восстанавливает точки входа
А>> — и ждет на объекте(ах) синхронизации обработчиков
А>> — дождались и выгружаем тело
А>>Это навскидку.
ГМ>--
ГМ>Похоже, мы вновь начинаем идти по кругу.

ГМ>Даже если функцию установки объекта синхронизации вызывать последней в Вашей hook-функции, это не гарантирует, что внутри этой функции не будет кода, который не будет выполняться при уже установленном объекте синхронизации. Всегда будет такой код, как минимум — это инструкция ret (а что будет реально — посмотрите ассемблерный код Вашей hook-функции).
ГМ>Это значит, что вполне возможна ситуация, когда на одном процессоре функция unload получит управление и выгрузит драйвер (потому что объекты синхронизации уже установлены), а на другом процессоре hook-функция еще до конца не выгрузилась.
Секунду, может я пропустил первую часть обсуждения, но этот аргумент не особо понимаю.
Введем следующие обозначения:
E — внешний вызов функции
O — наш обработчик
P — тот, что мы подменили
N — тот, кто подменил нас

E1 -> N1 -> O1 -> P -> O2 -> N2 -> E2

После unload мы должны получить следующее:
E1 -> P -> E2

Допустим, что EP (entry point) мы восстановили, но управление находится в точке N1, получим bsod

в остальных случаях операция должна завершится успешно, при условии что в N2 нет повторного вызова O.

Не могли бы вы подробней описать проблему, связанную с многопроцессорностью?

ГМ>Только не надо говорить о вероятностях таких событий, хорошо?

И не собирался

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

А>>>Тоесть мы рассматриваем вариант с постобработкой данных. При корректной реализации хук не выгрузится до тех пор, пока он имеет шанс получить управление не через точку входа, а именно:
---
А>>> — функция выгрузки сигналит о необходимости выгрузки
А>>> — диспетчер восстанавливает точки входа
А>>> — и ждет на объекте(ах) синхронизации обработчиков
А>>> — дождались и выгружаем тело
----
ГМ>>--
ГМ>>Похоже, мы вновь начинаем идти по кругу.

ГМ>>Даже если функцию установки объекта синхронизации вызывать последней в Вашей hook-функции, это не гарантирует, что внутри этой функции не будет кода, который не будет выполняться при уже установленном объекте синхронизации. Всегда будет такой код, как минимум — это инструкция ret (а что будет реально — посмотрите ассемблерный код Вашей hook-функции).
ГМ>>Это значит, что вполне возможна ситуация, когда на одном процессоре функция unload получит управление и выгрузит драйвер (потому что объекты синхронизации уже установлены), а на другом процессоре hook-функция еще до конца не выгрузилась.
PVA>Секунду, может я пропустил первую часть обсуждения, но этот аргумент не особо понимаю.
PVA>Введем следующие обозначения:
PVA>E — внешний вызов функции
PVA>O — наш обработчик
PVA>P — тот, что мы подменили
PVA>N — тот, кто подменил нас

PVA>E1 -> N1 -> O1 -> P -> O2 -> N2 -> E2

PVA>После unload мы должны получить следующее:
PVA>E1 -> P -> E2

PVA>Допустим, что EP (entry point) мы восстановили, но управление находится в точке N1, получим bsod

PVA>в остальных случаях операция должна завершится успешно, при условии что в N2 нет повторного вызова O.
--
А что будет, если управление находится в O1 (или в P, или в O2) и драйвер тоже уже выгружен?

PVA>Не могли бы вы подробней описать проблему, связанную с многопроцессорностью?
--
Честно говоря, я даже не рассматривал варианты с несколькими хуками на одну функцию, я постарался показать проблему с деинсталляцией только одного хука. Я это сделал, возражая на выделенную последовательность действия (см. вверху).

Мы не имеем права выгружать драйвер до тех пор, пока выполняется наша hook-функция, т.е. тогда, когда самая последняя команда нашего обработчика О уже выполнилась. Затем этот факт нужно сообщить нашей процедуре unload драйвера. Выделенная последовательность комманд, по моему, этого не гарантирует.

Я не утверждаю, что этого сделать нельзя, я просто говорю, что это не тривиальная задача.

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

От:	Valery A. Boronin	linkedin.com/in/boronin
Дата:	15.08.06 22:49
Оценка:	47 (9)
#Имя:	FAQ.asm.Filter vs. Hook

	От:	Геннадий Майко
	Дата:	16.08.06 02:41
	Оценка:	15 (2) +1

	От:	onyx2
	Дата:	16.08.06 05:59
	Оценка:

	От:	don ASKet
	Дата:	16.08.06 06:07
	Оценка:

	От:	Sergey Storozhevykh
	Дата:	16.08.06 06:40
	Оценка:	2 (2)

	От:	Злость
	Дата:	16.08.06 13:54
	Оценка:	6 (1)

	От:	Аноним
	Дата:	17.08.06 06:43
	Оценка:

	От:	PVA
	Дата:	17.08.06 08:46
	Оценка:

	От:	gear nuke
	Дата:	17.08.06 09:57
	Оценка: