Re: TDI_RECEIVE, ReceiveCallback и ChainedReceiveCallback
От: x64 Россия  
Дата: 28.01.11 20:38
Оценка:
C_>пишу секюрити продукт на базе TDI фильтра. заметил одну интересную особенность — исходящий трафик
C_>проходит через обработчик TDI_SEND, так его легко получить из IRP.

Не всё идёт через TDI_SEND, кое-что идёт через TDI_DIRECT_SEND, например, SMB.

C_>1) кого из них нужно перехватывать для полного анализа входящего трафика


Достаточно фильтровать TDI_RECEIVE и ClientEventReceive, а установку обработчика ClientEventChainedReceive() можно фейлить на TDI_SET_EVENT_HANDLER. Нормальный клиент должен адекватно отреагировать на подобный отлуп. Во всяком случае, системные драйвера реагируют адекватно, следовательно, это эталонное поведение. Ну а если всё же очень хочется перехватить именно chained-вариант, то придётся заморочиться с грязнохуками, но я не уверен, что это нужно.

C_>2) есть ли четкая закономерность, как HTTP траффик распеределен по трем данным обработчикам, или

C_>это когда как.

Нет, зависимости нет, однако начиная с Windows Vista, транспорт старается дёргать чаще chained-колбек, чем не-chained, т.к. он более производителен.

C_>кроме того, слышал, в Висте и Семерке TDI не всегда корретно работчват, лучше юзать NPI/WFP, хотя

C_>первый не документировани, а второй имеет ряд серьезный багов, особенно в семерке. стоит ли работать с NPI/WFP?

Весь сокетный трафик (afd.sys), а также кое-что ещё, включая ядерный HTTP-сервер (http.sys), проходит через TDI. И на Windows 7 в том числе.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.