Господа! Подскажите, где можно почитать о технике перехвата функций ядра (если нет hot patching). Требуется перехватить очень часто вызываемую функцию на многопроцессорной машине. Какие вообще существуют красивые и безопасные техники перехвата ядерных сервисов. Пример: WRITE_REGISTER_ULONG - надо перехватить!
>> WRITE_REGISTER_ULONG - надо перехватить! #define WRITE_REGISTER_ULONG(Register, Value) (*(volatile ULONG *)(Register) = (Value))
fr0b-p ну вообще-то там вот так: #define WRITE_REGISTER_ULONG(x, y) { \ *(volatile ULONG * const)(x) = y; \ KeFlushWriteBuffer(); \ }
Во-перыых, что вообще такое сплайсинг? Если я правильно догадался - либо замена адреса функции в KiServiceTable, либо подмена кода в начале самой функции. Если я близок к истине... тогда продолжим: какая разница, с каким приоритом может исполняться перехватываемая функция? Прервется код или нет зависит только от IRQL того кода, который выполняет перехват что значит "код на DISPATCH_LEVEL гарантировано не может исполняться"? в смысле, цикл в DPC не может прерваться потоком с таким же и меньшим приоритетом? когда в третий раз прочитал, понял... кстати, а как быть с прерываниями? рассчитывать, что их обработчики не станут вызывать перехватываемые функции? так все таки - перехват на PASSIVE_LEVEL, или перехват функций, работающих на PASSIVE_LEVEL?
вот ведь.. %( а к функции вообще применимо понятие IRQL? IRQL есть у потока... и как можно запретить прерывания? (кроме cli, конечно)
fluderast Вот видишь, сам же сказал, что есть почти безопасный способ сплайсинга. Хукинг SDT безопасен по определению. Nouzui NMI обрабатываются на высших IRQL. Нативные же функции работают в основном на passive level, реже - dispatch, к ним обращений оттуда быть не может. Единственный потенциальный косяк - если другой поток был прерван в той области, в которую производится сплайсинг. Вероятность этого чрезвычайно мала, но если так случится - то бсод.
Менеджер памяти и шедулер работают на IRQL DISPATCH_LEVEL. Отсюда вывод, что функции, которые используют подкачиваемую память или каким-то образом затрагивают шедулер (например, функции ожидания KeWaitForXXXObject при ненулевом таймауте) могут работать на IRQL строго меньше DISPATCH_LEVEL.
