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

R>>Сори, но последнее не соответсвует действительности. TDI в NT/2000/XP/2003/Vista x86/x64 работает одинаково.

TC>Работает. Только драйвер tcpip.sys более не имеет TDI интерфейса. TDI интерфейс вынесен в драйвер tdx.sys, обеспечивающий совместимость для старых драйверов ( через него работает netbios, туннель pptp, что свидетельствует о том, что эти драйвера видимо портированы с XP ). Напрямую ( через недокументированный интерфейс TLI ) с tcpip работает драйвер afd, предоставляющий сервис сокетам, драйвера, использующие WSK ( в том числе вроде и http.sys а за ним и IIS и все .NET службы ), привилигированные драйвера могут напрямую использовать tcpip.sys. Возможно, конечно afd.sys имеет сверху TDI интерфейс для общения с UM ( \Device\afd ), но я немного возился с ним и что то не видел традиционных TDI запросов.

По моим же сведениям afd использует TDI девайсы для общения с tcpip под всеми существующими версиями Висты, хоть и реализованы они теперь в другом драйвере, и есть WSK. После IoAttachDeviceToDeviceStack к \device\Tcp в драйвер-перехватчик попадают все сокетные вызовы. Было бы интересно узнать источник вашей информации по поводу того через какой интерфейс работает afd в Висте. В мануалах такой информации я не нашел, хоть и рисуют теперь afd на диаграммах между tdi и wsk. Да и тесты опровергают ваше предположение что в Висте afd работает с tcpip через другой интерфейс. afd.sys реализует \Device\afd, который и не должен получать TDI запросов. Потому что afd это не транспорт, а интерфейс к транспорту, для юзермодной части. WSK кстати может мапить вызовы на TDI девайсы для заданных комбинаций family/type/protocol, так что даже использующие его приложения могут прозрачно продолжать работать через TDI. Но судя по стеку вызовов для afd этого не делается, и из afd обращение идет сразу на девайсы tdx.

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

R>>Неправда Вы это лично проверяли?

TC>а то?

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

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

TC>А вот клиент TDI:

TC>841d12ec 877c1e08 83822078 841d1308 8c74da48 tcpip!TcpTlProviderConnect
TC>841d1360 877c5e17 02741b80 8c74da48 83887d90 tdx!TdxConnectConnection+0x398
TC>841d137c 81c67cc9 83887c98 8c74da48 8c74da48 tdx!TdxTdiDispatchInternalDeviceControl+0x149
TC>841d1394 87d00470 838aa72c 8c644eb0 838aa630 nt!IofCallDriver+0x63
TC>841d13ac 87d005e1 8c4feb98 91ef71d0 838aa72c netbt!TdiConnect+0xe1

TC>Тут стек с параметрами, можно кой-чего интересного посмотреть:

TC>!devobj 83887c98
TC>Device object (83887c98) is for:
TC> Tcp \Driver\tdx DriverObject 838721b8

TC>Убедились, что это мы видим обработку запроса устройством \Device\tcp, созданного драйвером tdx

TC>0: kd> !drvobj 838721b8 2

TC>Driver object (838721b8) is for:
TC> \Driver\tdx
TC>DriverEntry: 877cd005 tdx!GsDriverEntry
TC>DriverStartIo: 00000000
TC>DriverUnload: 877c75d2 tdx!TdxUnload

TC>Dispatch routines:
TC>....
TC>[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL 877c5cce tdx!TdxTdiDispatchInternalDeviceControl
TC>....

TC>Убедились, что мы видим обработку IRP_MJ_INTERNAL_DEVICE_CONTROL. Можно убедиться, что это запрос TDI_CONNECT

TC>Это я привел для иллюстрации факта, что драйвера afd.sys и tdx.sys являются равноправными, работают параллельно и ни один из них не использует другого.

Эти драйвера по определению не могут быть равноправными, т.к. выполняют разные функции в системе. tdx имеет TDI интерфейс для использования его по назначению TDI клиентами, в том числе AFD. AFD предоставляет юзермодной сокетной библиотеке промежуточный интерфейс для доступа к транспорту. Причем какой именно интерфейс использовать TDI или WSK определяется AFD в рантайме. Если в системе есть фильтры \device\TCP, то вызовы делаются через TDI интерфейс из tdx.sys.

Проще всего, я думаю, сделать LSP фильтр. В SDK есть пример пустого фильтра — нужно в него добавить чуть-чуть функционала в реализацию функции WSPConnect. Из минусов — не все соединения будут видны ( вы не написали, что именно Вас интересует ), только те, что используют сокеты ( соответственно, не видны будут — NetBIOS, некоторые web службы ).

Альтернативы:

1. перехват ф. WSAConnect. Тоже самое, что LSP фильтр по сути, минусы те же + проблемы с некорректностью подобной техники — приличные программы так себя не ведут
2. Фильтр транспортного драйвера ( tcpip.sys ), для примера смотри TDIMon. Плюсы — будете видеть все соединения. Минусы — трудности в реализации, проблемы с портированием XP -> Vista
3. Использование WFP. Минусы — только для Vista
4. Пакетная фильтрация ( NDIS ). Минусы — трудности в реализации, не видны локальные соединения. Могут возникнуть проблемы с портированием между XP и Vista. Из плюсов — возможность управлять транзитным трафиком ( если машине повезло быть шлюзом, или если на ней работает виртуальная ОС ).

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

TC>Проще всего, я думаю, сделать LSP фильтр. В SDK есть пример пустого фильтра — нужно в него добавить чуть-чуть функционала в реализацию функции WSPConnect. Из минусов — не все соединения будут видны ( вы не написали, что именно Вас интересует ), только те, что используют сокеты ( соответственно, не видны будут — NetBIOS, некоторые web службы ).

Кроме этого в каждом сетевом приложении будет по экземпляру библиотеки с LSP фильтром. В которой кроме минимальной полезной функциональности обычно требуется еще interprocess communications часть для взаимодействия с основным приложением. Встраивается LSP в системе "супер" способом, через правку цепочки LSP фильтров в реестре (sporder). Если не повезет, и в процессе встраивания (или удаления) что-то пойдет не так, можно пользователю сделать проблему с сетью.
Да, и антивирусы со своими фильтрами. Те что перехватывают соединения на свои прокси редко дают левым DLLкам встроиться для фильтрации в свои процессы. А иначе перенаправленный трафик даже от обычных приложений в LSP может не попасть. Если делать с помощью LSP редирект на свою прокси, то весьма вероятны конфликты с другими прокси, которые так же перехватывают на себя соединения на определенные порты. Это когда прокси поочередно перехватывают друг у друга на себя одно и то же соединение в условно бесконечном цикле. А т.к. прокси с редиректором это сейчас практически стандартное решение, которое реализовано во многих популярных антивирусах, соответственно махнуть рукой на такие конфликты это значит отрезать аудиторию из кучи пользователей. Короче многое зависит от задачи конечно, но IMHO LSP — это путь для сильных духом И я бы не советовал сегодня делать на LSP тиражируемые приложения, т.к. кажущаяся простота решения на LSP на деле может обернуться проблемами с поддержкой. У многих пользователей такой зверинец в системе, что мама не горюй: файрволы, антивирусы, попап-блокеры, баннерорезалки, антиспамы. Надо хорошо постараться чтобы еще один LSP ничего не похерил и все продолжало работать как надо.

TC>Альтернативы:

TC>2. Фильтр транспортного драйвера ( tcpip.sys ), для примера смотри TDIMon. Плюсы — будете видеть все соединения. Минусы — трудности в реализации, проблемы с портированием XP -> Vista

Сори, но последнее не соответсвует действительности. TDI в NT/2000/XP/2003/Vista x86/x64 работает одинаково.

Привет, All!

Подскажите в какую сторону копать:
Надо: при установлении соединения по TCP/IP на определенный порт, перенаправить соединение на другой IP-адрес. Смутно всплывают в памяти слова Winsock, NDIS
Платформа: Windows

Спасибо!

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

RD>Подскажите в какую сторону копать:
RD>Надо: при установлении соединения по TCP/IP на определенный порт, перенаправить соединение на другой IP-адрес. Смутно всплывают в памяти слова Winsock, NDIS
RD>Платформа: Windows

Сюда: http://netfiltersdk.com

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

TC>Проще всего, я думаю, сделать LSP фильтр. В SDK есть пример пустого фильтра — нужно в него добавить чуть-чуть функционала в реализацию функции WSPConnect. Из минусов — не все соединения будут видны ( вы не написали, что именно Вас интересует ), только те, что используют сокеты ( соответственно, не видны будут — NetBIOS, некоторые web службы ).

Спасибо! Вкуриваю Komodia LSP Guide, вроде то что нужно.

R>Сори, но последнее не соответсвует действительности. TDI в NT/2000/XP/2003/Vista x86/x64 работает одинаково.

Работает. Только драйвер tcpip.sys более не имеет TDI интерфейса. TDI интерфейс вынесен в драйвер tdx.sys, обеспечивающий совместимость для старых драйверов ( через него работает netbios, туннель pptp, что свидетельствует о том, что эти драйвера видимо портированы с XP ). Напрямую ( через недокументированный интерфейс TLI ) с tcpip работает драйвер afd, предоставляющий сервис сокетам, драйвера, использующие WSK ( в том числе вроде и http.sys а за ним и IIS и все .NET службы ), привилигированные драйвера могут напрямую использовать tcpip.sys. Возможно, конечно afd.sys имеет сверху TDI интерфейс для общения с UM ( \Device\afd ), но я немного возился с ним и что то не видел традиционных TDI запросов.

Вот тут немного об архитектуре — http://tarasc0.blogspot.com/2007/01/windows-vista.html

TC>Работает. Только драйвер tcpip.sys более не имеет TDI интерфейса. TDI интерфейс вынесен в драйвер tdx.sys

И чего? Драйверу, который клиент TDI, не всё ли равно кто девайсы вируальные ляпает? Он же не с драйверами работает, а с девайсами.

А> Он же не с драйверами работает, а с девайсами.

А то, что фильтр устройства \Device\Tcp на Vista не увидит соединения от IE например

TC>А то, что фильтр устройства \Device\Tcp на Vista не увидит соединения от IE например

TarasCo! Та это ясный перец! TDI-фильтр — решение только для Windows < Vista.
Я лишь хотел сказать, что ваш пост о TDI в Vista немного сумбурен и из него непонятно, как TDI-фильтр и TDI-клиент будут работать в Vista.

TC>2. Фильтр транспортного драйвера ( tcpip.sys ), для примера смотри TDIMon. Плюсы — будете видеть все соединения. Минусы — трудности в реализации, проблемы с портированием XP -> Vista

imho, это и есть самый правильный способ для Windows XP/Server 2003.
Сложностей в реализации не вижу (писал, было дело). Объём работ над TDI-фильтром не сравнимо меньше, чем над NDIS Intermediate Driver.

Для Windows Vista — Windows Filtering Platform.

А>Я лишь хотел сказать, что ваш пост о TDI в Vista немного сумбурен
Ну извините, в таком случае Ваш пост о полной идентичности работы TDI в XP и Vista — провокационен ( что и произошло — лишний флейм ) , надо было сразу уточнять свою позицию.

Вот тут и проблема — LSP фильтр совместим с XP и Vista. Фильтрация на уровне транспортного фильтра — принципиально различна, по сути, нужно два проекта вместо одного. А для стратапа лучше все же LSP фильтр — это быстрее даст результат, чем разработка двух драйверов, потом можно потихоньку перенести все в ядро. Я бы стал решать задачу скорее всего с помощью драйвера, но я в курсе как это делать. Автор топика судя по вопросу не в курсе, он потратит пару-тройку месяцев на изучение основ, что сильно замедлит стартап, и возможно вообще загубит проект..

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

А>> Он же не с драйверами работает, а с девайсами.

TC>А то, что фильтр устройства \Device\Tcp на Vista не увидит соединения от IE например

Неправда Вы это лично проверяли?

TC>Ну извините, в таком случае Ваш пост о полной идентичности работы TDI в XP и Vista — провокационен ( что и произошло — лишний флейм ) , надо было сразу уточнять свою позицию.

Блин, да и в мыслях не было никого провоцировать Я вообще питаю к вам уважение как к специалисту, только вы не всегда высказываетесь чётко. Вообще, я ожидал, что вы скажете что-то вроде "да, для TDI-клиентов — разницы нет, а вот TDI-фильтры будут не всё ловить".

P.S. И опять вы попутали немного О полной идентичности писал не я, а некто racer — здесь

Автор: racer
Дата: 17.07.07

. Я же...

( Irreconcilable anonym;
привет, TarasCo! )

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

А>>Я лишь хотел сказать, что ваш пост о TDI в Vista немного сумбурен
TC>Ну извините, в таком случае Ваш пост о полной идентичности работы TDI в XP и Vista — провокационен ( что и произошло — лишний флейм ) , надо было сразу уточнять свою позицию.

TDI работает в Vista абсолютно так же как в предыдущих NT-based операционках, это факт. То что появился еще WSK и некоторые подсистемы могут работать через новый интерфейс этот факт не опровергает. AFD продолжает работать через TDI, так что ваши предположения на счет сокетных вызовов неверны.

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

R>По моим же сведениям afd использует TDI девайсы для общения с tcpip под всеми существующими версиями Висты, хоть и реализованы они теперь в другом драйвере, и есть WSK. После IoAttachDeviceToDeviceStack к \device\Tcp в драйвер-перехватчик попадают все сокетные вызовы.

Чего долго думать? Можно взять и снять стек

935d7b48 8778556f tcpip!TcpTlProviderConnect <--- а вот обращение через TLI к tcpip.sys, как и обещалось — напрямую.....
935d7c1c 8777e3ec afd!AfdConnect+0x75c
935d7c2c 81c67cc9 afd!AfdDispatchDeviceControl+0x3b <-- а вот мы в функции-диспетчере драйвера, создавшего файл — это afd.sys, как и предполагалось
935d7c44 81dc808b nt!IofCallDriver+0x63
935d7c64 81dcc7ce nt!IopSynchronousServiceTail+0x1e0
935d7d00 81e20abe nt!IopXxxControlFile+0x6b7 <--- начал работать манагер ввода вывода
935d7d34 81c461fa nt!NtDeviceIoControlFile+0x2a <--- вот через таблицу SDT была вызвана функция работы с файлами
935d7d34 77a30f34 nt!KiFastCallEntry+0x12a <--- а вот мы уже прошли через шлюз ( обращаем внимания адреса процедур в области ядра уже )
011ce690 77a2f850 ntdll!KiFastSystemCallRet <--- а вот обращению к шлюзу ядра
011ce694 758a4753 ntdll!ZwDeviceIoControlFile+0xc <---- вот обращение к файлу, представляющему соединение
011ce744 758a4514 mswsock!SockDoConnectReal+0x2f5
011ce7e0 758a431e mswsock!SockDoConnect+0x38f
011ce804 76294bf9 mswsock!WSPConnect+0x1f <---- вот все попало SPI провайдеру
011ce850 00b9c90c WS2_32!connect+0x52 <---- вот вызов connect ( сокетный вестимо )
011cea00 00b9ca96 telnet!FProcessFDOOB+0x1c4
011cec18 00b9a6df telnet!FConnectToServer+0x32
011cf370 00ba25b3 telnet!OpenTelnetSession+0x404
011cf9a0 769b3833 telnet!DoTelnetCommands+0x158 <---- вот я набрал команду telnet у

Где обращения к драйверу tdx.sys который создал устройство \device\tcp????

R>afd.sys реализует \Device\afd, который и не должен получать TDI запросов. Потому что afd это не транспорт, а интерфейс к транспорту, для юзермодной части

Ну, в NT 4.0 и 5.0 устройство \Device\afd имело TDI подобный интерфейс, там номера запросов другие ( не как в tcpip.sys ), но формат передаваемых запросов тот же. А вот в Vista я не смог идентифицировать запросы к драйверу afd как соответствующие спецификации TDI, хотя возился недолго и не уверен.

R>Неправда Вы это лично проверяли?

а то?

А вот клиент TDI:

841d12ec 877c1e08 83822078 841d1308 8c74da48 tcpip!TcpTlProviderConnect
841d1360 877c5e17 02741b80 8c74da48 83887d90 tdx!TdxConnectConnection+0x398
841d137c 81c67cc9 83887c98 8c74da48 8c74da48 tdx!TdxTdiDispatchInternalDeviceControl+0x149
841d1394 87d00470 838aa72c 8c644eb0 838aa630 nt!IofCallDriver+0x63
841d13ac 87d005e1 8c4feb98 91ef71d0 838aa72c netbt!TdiConnect+0xe1

Тут стек с параметрами, можно кой-чего интересного посмотреть:

!devobj 83887c98
Device object (83887c98) is for:
Tcp \Driver\tdx DriverObject 838721b8

Убедились, что это мы видим обработку запроса устройством \Device\tcp, созданного драйвером tdx

0: kd> !drvobj 838721b8 2

Driver object (838721b8) is for:
\Driver\tdx
DriverEntry: 877cd005 tdx!GsDriverEntry
DriverStartIo: 00000000
DriverUnload: 877c75d2 tdx!TdxUnload

Dispatch routines:
....
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL 877c5cce tdx!TdxTdiDispatchInternalDeviceControl
....

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

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

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

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

R>>По моим же сведениям afd использует TDI девайсы для общения с tcpip под всеми существующими версиями Висты, хоть и реализованы они теперь в другом драйвере, и есть WSK. После IoAttachDeviceToDeviceStack к \device\Tcp в драйвер-перехватчик попадают все сокетные вызовы.

TC>Чего долго думать? Можно взять и снять стек

TC>935d7b48 8778556f tcpip!TcpTlProviderConnect <--- а вот обращение через TLI к tcpip.sys, как и обещалось — напрямую.....
TC>935d7c1c 8777e3ec afd!AfdConnect+0x75c
TC>935d7c2c 81c67cc9 afd!AfdDispatchDeviceControl+0x3b <-- а вот мы в функции-диспетчере драйвера, создавшего файл — это afd.sys, как и предполагалось
TC>935d7c44 81dc808b nt!IofCallDriver+0x63
TC>935d7c64 81dcc7ce nt!IopSynchronousServiceTail+0x1e0
TC>935d7d00 81e20abe nt!IopXxxControlFile+0x6b7 <--- начал работать манагер ввода вывода
TC>935d7d34 81c461fa nt!NtDeviceIoControlFile+0x2a <--- вот через таблицу SDT была вызвана функция работы с файлами
TC>935d7d34 77a30f34 nt!KiFastCallEntry+0x12a <--- а вот мы уже прошли через шлюз ( обращаем внимания адреса процедур в области ядра уже )
TC>011ce690 77a2f850 ntdll!KiFastSystemCallRet <--- а вот обращению к шлюзу ядра
TC>011ce694 758a4753 ntdll!ZwDeviceIoControlFile+0xc <---- вот обращение к файлу, представляющему соединение
TC>011ce744 758a4514 mswsock!SockDoConnectReal+0x2f5
TC>011ce7e0 758a431e mswsock!SockDoConnect+0x38f
TC>011ce804 76294bf9 mswsock!WSPConnect+0x1f <---- вот все попало SPI провайдеру
TC>011ce850 00b9c90c WS2_32!connect+0x52 <---- вот вызов connect ( сокетный вестимо )
TC>011cea00 00b9ca96 telnet!FProcessFDOOB+0x1c4
TC>011cec18 00b9a6df telnet!FConnectToServer+0x32
TC>011cf370 00ba25b3 telnet!OpenTelnetSession+0x404
TC>011cf9a0 769b3833 telnet!DoTelnetCommands+0x158 <---- вот я набрал команду telnet у

TC>Где обращения к драйверу tdx.sys который создал устройство \device\tcp????

R>>afd.sys реализует \Device\afd, который и не должен получать TDI запросов. Потому что afd это не транспорт, а интерфейс к транспорту, для юзермодной части

TC>Ну, в NT 4.0 и 5.0 устройство \Device\afd имело TDI подобный интерфейс, там номера запросов другие ( не как в tcpip.sys ), но формат передаваемых запросов тот же. А вот в Vista я не смог идентифицировать запросы к драйверу afd как соответствующие спецификации TDI, хотя возился недолго и не уверен.

Попробуйте приаттачиться своим фильтром к \device\TCP и стек будет примерно такой:

tcpip!TcpTlProviderConnect
tdx!TdxConnectConnection+0x398
tdx!TdxTdiDispatchInternalDeviceControl+0x149
nt!IofCallDriver+0x63
WARNING: Stack unwind information not available. Following frames may be wrong.
anftdird+0xe75
anftdird+0x60e
nt!IofCallDriver+0x63
afd!AfdConnect+0x8b7
afd!AfdDispatchDeviceControl+0x3b
nt!IofCallDriver+0x63
nt!IopSynchronousServiceTail+0x1df
nt!IopXxxControlFile+0x6b7
nt!NtDeviceIoControlFile+0x2a
nt!KiFastCallEntry+0x127
ntdll!KiFastSystemCallRet
ntdll!NtDeviceIoControlFile+0xc
MSWSOCK!SockDoConnectReal+0x2f5
MSWSOCK!SockDoConnect+0x38f
MSWSOCK!WSPConnect+0x1f
WS2_32!connect+0x52
ftp!hookup+0x1c3
ftp!setpeer+0x1e7
ftp!main+0x506
ftp!_initterm_e+0x173
kernel32!BaseThreadInitThunk+0xe
ntdll!_RtlUserThreadStart+0x23


Это работает на всех Вистах, на чистых инсталляциях. Я тоже когда увидел что на чистой системе вызовы делаются напрямую подумал что все пропало Потом поковырял afd.sys и нашел условный переход на использование TDX когда в системе есть фильтры \device\TCP. Т.е. напрямую к tcpip вызовы идут только когда к девайсы TDX не фильтруются.

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

Проверил, Вы абсолютно правы — при добавлении устройства в стек \device\tcp вызовы перенаправляются в драйвер tdx.sys. Как говориться век живи — век учись.