Пишу утилиту мониторинга IRP-пакетов. Видится две модели реализации: 1) Выбираем приложение для мониторинга из списка всех процессов. Монитор показывает все пакеты, которые отправляются приложением какому-либо драйверу. Реализоввывается видимо хуком Native-функции NtDeviceIoControlFile в ядре и анализом ее параметров. 2) Во второй модели возможен мониторинг пакетов как от приложений, так и драйверов. Технически, решение видится в перехвате соответствующих диспечерских функций на вершине стека всех драйверов в системе - перечисляем драйвера, находим DriverObject->MajorFunction[*]'ы, в них перезаписываем члены массива значения которых отличаются от IopInvalidDeviceRequest, старые значения сохраняем, потом вызываем. Далее, просто хотелось бы выслушать мнения по поводу каждой из моделей реализации мониторинга, мнения о правильности предложенных технических решений каждого из методов, а также альтернативы изложенным. Спасибо.
x0man Одно дело муторно, другое дело она позволяет мониторить транспорт IRP-пакетов между драйверами. Выгода очевидна.
blast Да, это как раз реализация первого пункта, тулза хучит NtDeviceIoControlFile. Как ни странно, но код у Cr4sh очень качественный, приятно смотреть. Cr4sh настоящий профессионал. Что насчет второго пункта? Видел ли кто такую реализацию? И вообще нужен ли мониторинг транспорта IRP-пакетов между драйверами?
Я недавно писал дров, который прятал файл по второму способу, там все вроде бы работало, но насколько я понимаю, могут возникнуть некоторые сложности при перехвате асинхронных ирпов, хотя это просто тонкости реализации..
Rodin Кстати тоже об этом думал, но вот не уверен что это затронет все случаи. Надо провести исследование. blast Не, ничего не мешает, просто для начала хотел проработать вопрос чисто теоретически. Velheart Ну в моем случае таких проблем не будет, я же просто мониторю не редактируя запросы.
