попробую наконец максимально доходчиво разобраться с этим одним из самых популярных вопросов, одним из первых кандидатов в FAQ этого форума. этот же вопрос вероятно муссируется постоянно на других форумах, в т.ч. OSR со дня их появления, так что владеющие английским, думаю, легко могут найти все о чем я поведаю там, немного порывшись.
не претендуя на полноту, попробую лишь обозначить проблемы, которые появляются при использовании разного рода хуков. ну и не забыть о преймуществах — все кто уже большие, должны знать что в таких вещах не бывает одно всегда и во всем лучше другого ведь иначе бы этого другого никому не было нужно, ясен пень.
впрочем не буду отвлекаться и сразу предлагаю использовать эту ветку форума для того чтобы дополнить то, о чем забуду упомянуть
но пожалуйста следите за объемом цитирования — модератор
ибо на эту тему можно написать и трактат и кандидатскую даже не уходя из Windows NT области (остальные популярные ОС впрочем тут как правило не лучше)
итак, тезисно, Pro et Contra или benefits vs. drawbacks, то что сразу вспоминается:
Contra или чем чреваты хуки
1. Хуки невыгружаемы. Точка.
Выгрузка хука это почти всегда катастрофа. Если кто-то выше повесил хук на наш, то после выгрузки нашего драйвера при первом же вызове, когда хук выше позовет предыдущий обработчик, т.е. нас, а мы уже ушли — результат будет известно какой: можете попытаться угадать, но я бы даже не стал этого делать ибо правильный ответ — непредсказуемый.
2. Хуки и недокументированность
Часто вызовы которые патчатся — недокументированы (например при использовании system call table hooking), а это значит, что последствия могут быть самыми разными — начнется путешествие по недокументированным и изменяющимся без уведомления "минным полям" т.к. производитель волен делать (и делает!) что угодно с приватными интерфейсами. Если хук таблицы системных вызовов делается, надо для начала четко определить правильный индекс — а они, бывает, меняются! Если речь не идет о какой-нибудь "хорошей" ф-ии выставленной ядром наружу официально. Короче, начало может быть весьма нелегким, если Вы не сам себе тестер на однопроцессорной машине с одной и той же конфигурацией ОС что подозреваю имеет место в данном случае, но могу и ошибаться
к примеру, сложно будет с хуком вместо файлового фильтра отследить 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, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re: Что такое хорошо и что такое плохо (фильтр против хука)
Здравствуйте, Valery A. Boronin,
VAB>Pro или аргументы за хуки
VAB>2. Маркетинг
--
"Objection Your Honor, the item is misleading!"
Это аргумент против хуков.
Вспомните недавний скандал с Sony CD copy protection. Расскажите его Вашему "маркетоиду". Пускай он сам оценит потери Sony. Пускай он сам оценит Ваши потери, когда об этом хуке узнают Ваши клиенты и конкуренты.
C уважением,
Геннадий Майко.
Re: Что такое хорошо и что такое плохо (фильтр против хука)
Все сказанное, конечно, верно.
ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет.
По крайней мере на ОСях NT, 2k, XP, 2k3.
Верно, и давно известно. Но самое главное систематизировано... Я вот для декций материал подбираю... Самое то
O>ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет.
А где бы их глянуть?
а то у них на сайте только бинарники...
Меняю два проигрывателя, на один выигрватель! Возможна доплата... ;)
Re[2]: Что такое хорошо и что такое плохо (фильтр против хук
O>Все сказанное, конечно, верно. O>ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет. O>По крайней мере на ОСях NT, 2k, XP, 2k3.
В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).
Re[3]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, onyx2, Вы писали:
O>Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>>В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).
O>А у вас есть исходники одной из последних версий regmon? O>Если да, поделитесь ссылочкой, please.
Неа, по-моему, их и не было никогда (как и для "правильного" filemon). Наводит, кстати, на определенные размышления.
Re: Что такое хорошо и что такое плохо (фильтр против хука)
А есть еще различные Rootkits детекторы, которые очень подозрительно относяться к пропатченой таблице сервисов.
Доказывай потом конечному пользователю, что ты белый и пушистый.
Re: Что такое хорошо и что такое плохо (фильтр против хука)
От:
Аноним
Дата:
16.08.06 09:43
Оценка:
VAB>1. Хуки невыгружаемы. Точка.
При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.
Re[2]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, Аноним, Вы писали:
VAB>>1. Хуки невыгружаемы. Точка. А>При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.
А если в момент выгрузки первого хука, второй уже находится внутри одной из своих хукнутых процедур и готовится позвать первый хук? БСОД.
Хотя и без этого корректной назвать выгрузку, которая заодно обрубает руки-ноги другим хукам язык не поворачивается. Однако, так им и надо
Re[4]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, onyx2, Вы писали:
O>Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>>В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).
O>А у вас есть исходники одной из последних версий regmon? O>Если да, поделитесь ссылочкой, please.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Здравствуйте, Геннадий Майко, Вы писали:
VAB>>Pro или аргументы за хуки
VAB>>2. Маркетинг ГМ>-- ГМ>"Objection Your Honor, the item is misleading!"
ГМ>Это аргумент против хуков.
Маркетинг как и Безопасность — двуликий янус. Или обоюдоострый меч, все верно
Гена, с удовольствием принимаю Ваше ценное дополнение, но тем не менее в случае с Sony была еще и банальная криворукость и низкий уровень реализации — что и показал доктор Руссинович, заодно не сильно напрягаясь грамотно пропиарив в очередной раз свой ресурс Кто знает, может это и подтолкнуло MSFT к его покупке?
никто не жалуется особо, к примеру. Естественно коммерческий вариант на хуках, чтобы попасть в Pro::Marketing, должен быть ближе к RegMon нежели к сляпанной на коленке поделухе Sony — мастер и на хуке сделает конфетку (в теории).
ГМ>Вспомните недавний скандал с Sony CD copy protection. Расскажите его Вашему "маркетоиду". Пускай он сам оценит потери Sony. Пускай он сам оценит Ваши потери, когда об этом хуке узнают Ваши клиенты и конкуренты.
маркетоиды не мои
конкуренты же (те, которые квалифицированные ) и клиенты в курсе, если уровень позволяет и know-how не нарушается.
Если говорить за мое текущее место работы, то там посторонние эксперты по безопасности и технологиям, бывает, разбирают наши решения по косточкам — чтобы заключить контракт с какой-либо серьезной организацией типа английского минобороны (Ministry of Defense) их техническим специалистам приходится доказывать что и как, почему хук и почему по-другому если не нельзя, то хуже и в чем именно хуже. Что-то случается просят переделать — без этого контракта не будет. Тайны-то никакой нет, кому надо все равно сразу в отладчике все увидит, соотв. и потери чаще всего происходят не от того, что стало известно о применении хука внутри продукта, а от проблем типа плохой реализации — как в случае с Sony.
PS Более того, я бы приветствовал если бы производители писали хотя бы на чем у них решения, мол такая-то версия Касперского на хуке, а такая-то версия Панды на минифильтре.
PPS Еще немного оффтопика себе позволю: вообще с подозрением отношусь к софту от consumer производителей, невзирая на громкие имена типа Sony, Samsung... Лучше бы они писали кто для них пишет софт — было бы написано мол Руссинович или OSR трудился — вот тут бы доверие наверное минимальное появилось А если сами пишут — то скорее всего будет как всегда
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Valery A. Boronin,
VAB>>>Pro или аргументы за хуки
VAB>>>2. Маркетинг ГМ>>-- ГМ>>"Objection Your Honor, the item is misleading!"
ГМ>>Это аргумент против хуков. VAB>Маркетинг как и Безопасность — двуликий янус. Или обоюдоострый меч, все верно
ГМ>>Вспомните недавний скандал с Sony CD copy protection. Расскажите его Вашему "маркетоиду". Пускай он сам оценит потери Sony. Пускай он сам оценит Ваши потери, когда об этом хуке узнают Ваши клиенты и конкуренты. VAB>маркетоиды не мои
--
Я имел в виду не Вас, а некоего третьего лица, который захочет убедить своих "маркетоидов", что такое решение будет нормальным.
VAB> Тайны-то никакой нет, кому надо все равно сразу в отладчике все увидит, соотв. и потери чаще всего происходят не от того, что стало известно о применении хука внутри продукта, а от проблем типа плохой реализации — как в случае с Sony.
--
Скорее, не в плохой реализации, а в плохом процессе uninstall этого драйвера, который изменяет системную таблицу.
Корректно заменить адрес функции в какой-то таблице (адрес которой известен, конечно) проблем не вызывает.
А вот корректно заменить участок кода (что очень хотят сделать многие), на мой взгляд, весьма сложно.
С уважением,
Геннадий Майко.
Re[3]: Что такое хорошо и что такое плохо (фильтр против хук
От:
Аноним
Дата:
17.08.06 06:43
Оценка:
Здравствуйте, Sergey Storozhevykh, Вы писали:
VAB>>>1. Хуки невыгружаемы. Точка. А>>При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.
SS>А если в момент выгрузки первого хука, второй уже находится внутри одной из своих хукнутых процедур и готовится позвать первый хук? БСОД.
Тоесть мы рассматриваем вариант с постобработкой данных. При корректной реализации хук не выгрузится до тех пор, пока он имеет шанс получить управление не через точку входа, а именно:
— функция выгрузки сигналит о необходимости выгрузки
— диспетчер восстанавливает точки входа
— и ждет на объекте(ах) синхронизации обработчиков
— дождались и выгружаем тело
Это навскидку.
SS>Хотя и без этого корректной назвать выгрузку, которая заодно обрубает руки-ноги другим хукам язык не поворачивается. Однако, так им и надо
Напишите в мс, чтоб сделали KeGetHook/KeSetHook/KeRestoreHook При общем диспетчере можно будет это делать безопасно.
Re[4]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, Аноним,
VAB>>>>1. Хуки невыгружаемы. Точка. А>>>При корректной выгрузке хука, хук повешенный позже просто не получит управления этим же путем — точка входа при выгрузке будет восстановлена на предыдущий обработчик.
SS>>А если в момент выгрузки первого хука, второй уже находится внутри одной из своих хукнутых процедур и готовится позвать первый хук? БСОД. А>Тоесть мы рассматриваем вариант с постобработкой данных. При корректной реализации хук не выгрузится до тех пор, пока он имеет шанс получить управление не через точку входа, а именно: А> — функция выгрузки сигналит о необходимости выгрузки А> — диспетчер восстанавливает точки входа А> — и ждет на объекте(ах) синхронизации обработчиков А> — дождались и выгружаем тело А>Это навскидку.
--
Похоже, мы вновь начинаем идти по кругу.
Даже если функцию установки объекта синхронизации вызывать последней в Вашей hook-функции, это не гарантирует, что внутри этой функции не будет кода, который не будет выполняться при уже установленном объекте синхронизации. Всегда будет такой код, как минимум — это инструкция ret (а что будет реально — посмотрите ассемблерный код Вашей hook-функции).
Это значит, что вполне возможна ситуация, когда на одном процессоре функция unload получит управление и выгрузит драйвер (потому что объекты синхронизации уже установлены), а на другом процессоре hook-функция еще до конца не выгрузилась.
Только не надо говорить о вероятностях таких событий, хорошо?
C уважением,
Геннадий Майко.
Re[5]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, Геннадий Майко,
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.
Не могли бы вы подробней описать проблему, связанную с многопроцессорностью?
ГМ>Только не надо говорить о вероятностях таких событий, хорошо?
И не собирался
newbie
Re[6]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, 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 драйвера. Выделенная последовательность комманд, по моему, этого не гарантирует.
Я не утверждаю, что этого сделать нельзя, я просто говорю, что это не тривиальная задача.
С уважением,
Геннадий Майко.
Re[5]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>Даже если функцию установки объекта синхронизации вызывать последней в Вашей hook-функции, это не гарантирует, что внутри этой функции не будет кода, который не будет выполняться при уже установленном объекте синхронизации. Всегда будет такой код, как минимум — это инструкция ret
ret не всегда обязателен, поскольку иногда можно поменять call на jmp. И "опасный" код не обязательно размещать в выгружаемом модуле.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[6]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, gear nuke,
ГМ>>Даже если функцию установки объекта синхронизации вызывать последней в Вашей hook-функции, это не гарантирует, что внутри этой функции не будет кода, который не будет выполняться при уже установленном объекте синхронизации. Всегда будет такой код, как минимум — это инструкция ret
GN>ret не всегда обязателен, поскольку иногда можно поменять call на jmp.
--
Не забудьте — я расматриваю случай, когда устанавливается синхронизирующий элемент и затем, после него, будет — ну скажем Ваш jmp. После установки элемента и до исполнения jmp, unload функция может закончиться, так как она уже дождалась установки своего элемента. Драйвер уже выгружен. А команду jmp выполнить еще надо. Вот в чем проблема.
GN>И "опасный" код не обязательно размещать в выгружаемом модуле.
--
2. Согласен с Вами. Но тогда мы не выгружаем наш драйвер, правильно?
C уважением,
Геннадий Майко.
Re[7]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, Геннадий Майко, Вы писали:
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) и драйвер тоже уже выгружен?
Если управление находится в O1, то следуя scoped guard драйвер не может быть выгружен вплоть до снятия блокировки по завершению O2.
Заметьте, что Unhook и Unload могут быть разнесены во времени (увиливаю от bsod)
PVA>>Не могли бы вы подробней описать проблему, связанную с многопроцессорностью? ГМ>-- ГМ>Честно говоря, я даже не рассматривал варианты с несколькими хуками на одну функцию, я постарался показать проблему с деинсталляцией только одного хука. Я это сделал, возражая на выделенную последовательность действия (см. вверху).
Не имеет значение количество хуков до нас, равно как и после нас — последние мы все-равно отключим.
ГМ>Мы не имеем права выгружать драйвер до тех пор, пока выполняется наша hook-функция, т.е. тогда, когда самая последняя команда нашего обработчика О уже выполнилась. Затем этот факт нужно сообщить нашей процедуре unload драйвера. Выделенная последовательность комманд, по моему, этого не гарантирует.
Для этого я там ввел понятие диспетчера, который отмониторит момент разрешения выгрузки со стороны хука
Кстати, такой диспетчер решает и проблему с разблокировкой на многопроцессорной машине с необходимостью. выполнить ret после выгрузки.
ГМ>Я не утверждаю, что этого сделать нельзя, я просто говорю, что это не тривиальная задача.
Да я и не спорю, просто интересно рассмотреть подходы при необходимости воспользоваться этими самыми хуками.
newbie
Re[8]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, 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>Если управление находится в O1, то следуя scoped guard драйвер не может быть выгружен вплоть до снятия блокировки по завершению O2. PVA>Заметьте, что Unhook и Unload могут быть разнесены во времени (увиливаю от bsod)
--
Да, понимаю. Точнее говоря, снижаете его вероятность
ГМ>>Честно говоря, я даже не рассматривал варианты с несколькими хуками на одну функцию, я постарался показать проблему с деинсталляцией только одного хука. Я это сделал, возражая на выделенную последовательность действия (см. вверху). PVA>Не имеет значение количество хуков до нас, равно как и после нас — последние мы все-равно отключим.
--
Верно. И это уже плохо.
ГМ>>Мы не имеем права выгружать драйвер до тех пор, пока выполняется наша hook-функция, т.е. тогда, когда самая последняя команда нашего обработчика О уже выполнилась. Затем этот факт нужно сообщить нашей процедуре unload драйвера. Выделенная последовательность комманд, по моему, этого не гарантирует. PVA>Для этого я там ввел понятие диспетчера, который отмониторит момент разрешения выгрузки со стороны хука PVA>Кстати, такой диспетчер решает и проблему с разблокировкой на многопроцессорной машине с необходимостью. выполнить ret после выгрузки.
--
Я что-то не заметил диспечера в Вашем исходном сообщении. Или плохо смотрел?
Я думаю, что без чего-то внешнего здесь не обойтись. Это внешнее должно отслеживать окончание работы hook-функции и сообщать об этом процедуре unload. Например, свой маленький отладчик, точнее отбработчик debug exceptions.
С уважением,
Геннадий Майко.
Re[7]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>я расматриваю случай, когда устанавливается синхронизирующий элемент и затем, после него, будет — ну скажем Ваш jmp. После установки элемента и до исполнения jmp, unload функция может закончиться, так как она уже дождалась установки своего элемента. Драйвер уже выгружен. А команду jmp выполнить еще надо. Вот в чем проблема.
Предположим, что сигналим вызовом некоторго API:
call SignalCanUnload
ret; драйвер выгружен - BSOD
меняем на:
jmp SignalCanUnload
GN>>И "опасный" код не обязательно размещать в выгружаемом модуле. ГМ>-- ГМ>2. Согласен с Вами. Но тогда мы не выгружаем наш драйвер, правильно?
Именно для возможности выгрузки модуля можно скопировать (небольшой) опасный участок в другое место. Этот код, безусловно, так и останется потом болтаться в памяти, но его можно разместить и без аллокации. Решение не слишком чистое, но и так падчится ядро, какая уже разница, 5 байт или 20
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[8]: Что такое хорошо и что такое плохо (фильтр против хук
--
Если конвенции возврата SignalCanUnload совпадают с конвенцией возврата из хука и этот SignalCanUnload не порушит регистры, то да, так, наверное, можно.
Еще нужно иметь гарантию, что SignalCanUnload не будет "трогать" синхронизационный элемент после того, как его установит.
Или, на всякий случай, нужно обеспечить "жизнь" этому элементу даже после выгрузки дайвера, примерно так, как Вы предлагаете ниже.
GN>>>И "опасный" код не обязательно размещать в выгружаемом модуле. ГМ>>-- ГМ>>2. Согласен с Вами. Но тогда мы не выгружаем наш драйвер, правильно?
GN>Именно для возможности выгрузки модуля можно скопировать (небольшой) опасный участок в другое место. Этот код, безусловно, так и останется потом болтаться в памяти, но его можно разместить и без аллокации. Решение не слишком чистое, но и так падчится ядро, какая уже разница, 5 байт или 20
--
И опять соглашусь с Вами. И добавлю, что подобных вариантов может быть несколько — от неинициализации указателя на Unload вообще до маркировки частей невыгружаемого драйвера как pageable/non pageable.
С уважением,
Геннадий Майко.
Re[2]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, onyx2, Вы писали:
O>ИМХО: Но если использовать хуки, так как это делает М. Руссинович (см. исходники regmon), думаю проблем не будет.
А вот мнение автора:
// NOTE: We can't unhook if someone else has hooked on top of us. Note that the
// unhook code below still has a window of vulnerability where someone can hook between
// our test and unhook.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Что такое хорошо и что такое плохо (фильтр против хук
Здравствуйте, onyx2,
SS>>В последних версиях regmon используются registry callbacks (см. CmRegisterCallback).
O>А у вас есть исходники одной из последних версий regmon?
В 4.35 (общедоступная версия исходников) используется CmRegisterCallback.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
ведь иначе бы этого другого никому не было нужно, ясен пень.
Вместо защиты образуется одна большая дыра которую уже ничем не закрыть. Конечно, я говорю о крайних случаях, просто этим пунктом хотел обратить внимание что безопасность вообще говоря идет рука об руку с хуками (см тоже пункт 7 ниже), но это бывает требует весьма тонкой работы...
Кто знает, может это и подтолкнуло MSFT к его покупке? 
