Здравствуйте.

Заранее хочу оговориться, что в сетевом программирование не особенно силен, так что могу не знать чего-то элементарного. Но я пишу программу, которая должна сидеть "там, где часы" и перехватывать EMAIL сообщения (как входящие, так и исходящие).

Придумал использовать GNUтую библиотеку WINPCAP.

Получается (содрал из исходников) перехватывать пакеты по заданному порту (110 и 25).

В полученном дампе вижу знакомые команды POP3: PASS, USER и т.д. Однако есть много мусора непонятного происхождения. Не могли бы вы пояснить процесс коннекта с EMAIL сервером на уровне TCP/IP. Возможно пересылается некоторая информация типа CRC?

Короткая версия вопроса: почему мой дамп отличается от того, что видно в окошке при "telnet pop.mail.ru" и как добиться соответствия? Возможно пакеты с данными и служебные отличаются по заголовку?

Укажите хотя бы направление, куда копать.

Заранее благодарен за любую помощь.

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

I>Придумал использовать GNUтую библиотеку WINPCAP.
Помоему она не GNU, а BSD-like.

I>В полученном дампе вижу знакомые команды POP3: PASS, USER и т.д. Однако есть много мусора непонятного происхождения. Не могли бы вы пояснить процесс коннекта с EMAIL сервером на уровне TCP/IP. Возможно пересылается некоторая информация типа CRC?
У вас там наверно заголовки пакетов, да и, наверняка, ещё "левых" пакетов наперехватывали..

I>Короткая версия вопроса: почему мой дамп отличается от того, что видно в окошке при "telnet pop.mail.ru" и как добиться соответствия?
Потому что, используя WinPCAP вы работаете не c TCP/IP а с кадрами Ethernet. Добится соответствия можно путём фильтрации и обрезания заголовков.

I>Укажите хотя бы направление, куда копать.
Копай, Нео, копай — летать научишься (С) Шматрица
Может вам проще использовать перехват Winsock2 API? Поищите в гугле на тему Detours.

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

B>Может вам проще использовать перехват Winsock2 API? Поищите в гугле на тему Detours.

Лучше LSP (Layered Service Provider).

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

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

B>>Может вам проще использовать перехват Winsock2 API? Поищите в гугле на тему Detours.

P>Лучше LSP (Layered Service Provider).

А вот этого лучше не надо.
У нас LSP в нескольких проектах используется
и поверьте мне на слово — удовольствие еще то...

Основная проблема в том, что вы становитесь зависимым от
моделей ввода-вывода, используемых клиентом (select, WsaAsyncSelect, etc.),
а если еще в клиенте какой-то недочет, который обнаруживается
в достаточно специфичных условиях... и т.д. и т.п.
Лучше уж сразу дрова...

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

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

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

B>>>Может вам проще использовать перехват Winsock2 API? Поищите в гугле на тему Detours.

P>>Лучше LSP (Layered Service Provider).

IG_>А вот этого лучше не надо.
IG_>У нас LSP в нескольких проектах используется
IG_>и поверьте мне на слово — удовольствие еще то...

IG_>Основная проблема в том, что вы становитесь зависимым от
IG_>моделей ввода-вывода, используемых клиентом (select, WsaAsyncSelect, etc.),
IG_>а если еще в клиенте какой-то недочет, который обнаруживается
IG_>в достаточно специфичных условиях... и т.д. и т.п.
IG_>Лучше уж сразу дрова...

А в дровах все плохо..... Возмите Outpost у него фильтрация высокоуровневых протоколов живет в ядре. Ошибка в реализации (а ведь это обычно самое глюченное и опасное — синтаксический анализ и.т.п. , что в свою очередь рано или поздно приведет к переполнению со всеми вытекающими) приводит к возникновению дыр на уровне ядра. Переполнили буфер — сразу BSOD. Варианты с использованием связок промежуточный драйвер — обработка на 3 кольце, нравиться мне еще меньше. Очень криво идут данные — путешествую то из ядра, то обратно в ядро. Для почты это может и не очень существенно, но вообще — кривой подход. LSP (или как вариант перехват сокетов, что по-сути тоже самое) кажется наилучшим вариантом, хотя согласен, в разработке (и особенно в отладке) наиболее трудоемким.

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



TC>А в дровах все плохо..... Возмите Outpost у него фильтрация высокоуровневых протоколов живет в ядре. Ошибка в реализации (а ведь это обычно самое глюченное и опасное — синтаксический анализ и.т.п. , что в свою очередь рано или поздно приведет к переполнению со всеми вытекающими) приводит к возникновению дыр на уровне ядра. Переполнили буфер — сразу BSOD.
Следует заметить, что LSP "вешается" ко всем сетевым процессам (включая системные сервисы),
и следовательно ошибка в самой LSP часто приводит к краху системы...
Наш спор мне напоминает спор, который разгорелся, когда MS перенесла графическую
подсистему в режим ядра. В книге Соломона, Русиновича приводится достаточно смешная
аргументация, что-то типа того, что независимо от того в каком режиме навернется
графическая подсистема — в пользовательском или в режиме ядра, все равно наступят
гайки, просто в первом случае они наступят чуть позже


TC> Варианты с использованием связок промежуточный драйвер — обработка на 3 кольце, нравиться мне еще меньше. Очень криво идут данные — путешествую то из ядра, то обратно в ядро. Для почты это может и не очень существенно, но вообще — кривой подход.

Я согласен, что у этого подхода есть недостатки и основной заключается в том, что данные будут
гоняться из одного режима в другой (и это нужно учитывать при выборе метода).

Перехват трафика — это достаточно низкоуровневая вещь, а здесь редко встретишь идеальные решения —
всегда нужно идти на какой-то компромисс.

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

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

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

B>>>Может вам проще использовать перехват Winsock2 API? Поищите в гугле на тему Detours.

P>>Лучше LSP (Layered Service Provider).

IG_>А вот этого лучше не надо.
IG_>У нас LSP в нескольких проектах используется
IG_>и поверьте мне на слово — удовольствие еще то...

IG_>Основная проблема в том, что вы становитесь зависимым от
IG_>моделей ввода-вывода, используемых клиентом (select, WsaAsyncSelect, etc.),

А при использовании Detours не становишься?

IG_>а если еще в клиенте какой-то недочет, который обнаруживается
IG_>в достаточно специфичных условиях... и т.д. и т.п.
IG_>Лучше уж сразу дрова...

Согласен.
Хотя и там проблем хватает.

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

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



TC>>А в дровах все плохо..... Возмите Outpost у него фильтрация высокоуровневых протоколов живет в ядре. Ошибка в реализации (а ведь это обычно самое глюченное и опасное — синтаксический анализ и.т.п. , что в свою очередь рано или поздно приведет к переполнению со всеми вытекающими) приводит к возникновению дыр на уровне ядра. Переполнили буфер — сразу BSOD.
IG_>Следует заметить, что LSP "вешается" ко всем сетевым процессам (включая системные сервисы),
IG_>и следовательно ошибка в самой LSP часто приводит к краху системы...

Никто Вас не заставляет делать это — перехватывать все соединения подряд. Определить процесс, куда Вас занесло, вполне возможно. Если это "не тот" процесс, просто при вызове WSPStartup передайте вниз все параметры без изменений и в этом процессе Вас уже не тронут . Вопрос о том, что кто то может "подделаться" под неприкасаемые процессы (напрмер, запустить свою служьу в svchost где нибудь рядом c lsa) из другой плоскости... если программа может себя регистрировать как SYSTEM или LOACL SERVICE, она может снести любой супервизор к чертовой матери, или даже его обмануть....

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

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

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



TC>>>А в дровах все плохо..... Возмите Outpost у него фильтрация высокоуровневых протоколов живет в ядре. Ошибка в реализации (а ведь это обычно самое глюченное и опасное — синтаксический анализ и.т.п. , что в свою очередь рано или поздно приведет к переполнению со всеми вытекающими) приводит к возникновению дыр на уровне ядра. Переполнили буфер — сразу BSOD.
IG_>>Следует заметить, что LSP "вешается" ко всем сетевым процессам (включая системные сервисы),
IG_>>и следовательно ошибка в самой LSP часто приводит к краху системы...

TC>Никто Вас не заставляет делать это — перехватывать все соединения подряд. Определить процесс, куда Вас занесло, вполне возможно. Если это "не тот" процесс, просто при вызове WSPStartup передайте вниз все параметры без изменений и в этом процессе Вас уже не тронут . Вопрос о том, что кто то может "подделаться" под неприкасаемые процессы (напрмер, запустить свою служьу в svchost где нибудь рядом c lsa) из другой плоскости... если программа может себя регистрировать как SYSTEM или LOACL SERVICE, она может снести любой супервизор к чертовой матери, или даже его обмануть....


Еще добавлю...
Если Вам по каким то причинам не хочется перехватывать конкретное соединение, то из WSPSocket достаточно вернуть оригинальный идентификатор сокета — все дальнейшие вызовы пойдут к провайдеру его создавшему и минуют Вас

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

TC>Никто Вас не заставляет делать это — перехватывать все соединения подряд. Определить процесс, куда Вас занесло, вполне возможно. Если это "не тот" процесс, просто при вызове WSPStartup передайте вниз все параметры без изменений и в этом процессе Вас уже не тронут . Вопрос о том, что кто то может "подделаться" под неприкасаемые процессы (напрмер, запустить свою служьу в svchost где нибудь рядом c lsa) из другой плоскости... если программа может себя регистрировать как SYSTEM или LOACL SERVICE, она может снести любой супервизор к чертовой матери, или даже его обмануть....

Если процесс "ms-овский" (вроде svchost), то да, я с вами согласен, ну а если сторонний разработчик? Основная проблема как раз и заключается в конфликте с другими приложениями... Хотя и у драйверов есть та же проблема...
Или вы предлагаете составить целую таблицу процессов, к которым не стоит аттачится? Тоже не самое лучшее решение...
Плюс возникает неприятная ситуация, когда в системе не только наша LSP.

Ну и еще раз повторюсь: главная проблема заключается в том, что в LSP приходится поддерживать различные модели ввода-вывода, плюс в LSP вы сильно зависимы от клиента. А если еще должна осуществляться достаточно сложная логика
по подмене, отсылке/приему данных, то это труба.

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


TC>Еще добавлю...
TC>Если Вам по каким то причинам не хочется перехватывать конкретное соединение, то из WSPSocket достаточно вернуть оригинальный идентификатор сокета — все дальнейшие вызовы пойдут к провайдеру его создавшему и минуют Вас

А вот это я не понял...
Во-первых при вызове WSPSocket соединение еще не создано (и не факт, что будет создано — например создание слушающего сокета).
А во-вторых это каким макаром все вызовы пойдут не через меня?

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


P>А при использовании Detours не становишься?
Я про Detours ничего не говорил

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

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

TC>>Никто Вас не заставляет делать это — перехватывать все соединения подряд. Определить процесс, куда Вас занесло, вполне возможно. Если это "не тот" процесс, просто при вызове WSPStartup передайте вниз все параметры без изменений и в этом процессе Вас уже не тронут . Вопрос о том, что кто то может "подделаться" под неприкасаемые процессы (напрмер, запустить свою служьу в svchost где нибудь рядом c lsa) из другой плоскости... если программа может себя регистрировать как SYSTEM или LOACL SERVICE, она может снести любой супервизор к чертовой матери, или даже его обмануть....

IG_>Если процесс "ms-овский" (вроде svchost), то да, я с вами согласен, ну а если сторонний разработчик? Основная проблема как раз и заключается в конфликте с другими приложениями... Хотя и у драйверов есть та же проблема...
IG_>Или вы предлагаете составить целую таблицу процессов, к которым не стоит аттачится? Тоже не самое лучшее решение...
IG_>Плюс возникает неприятная ситуация, когда в системе не только наша LSP.

IG_>Ну и еще раз повторюсь: главная проблема заключается в том, что в LSP приходится поддерживать различные модели ввода-вывода, плюс в LSP вы сильно зависимы от клиента. А если еще должна осуществляться достаточно сложная логика
IG_>по подмене, отсылке/приему данных, то это труба.

Все равно в коде будет баг. Когда упадет IE из за Вашей (или моей ) ошибки, пользователь скажет "е...й IE и MS", а когда упадет ваш драйвер и вся система из-за ошибки и похерит еще какой нибудь рабочий файл, который пользователь должен был редактировать а в место чего сидел в инете, угадайте, что он скажет?

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

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


TC>>Еще добавлю...
TC>>Если Вам по каким то причинам не хочется перехватывать конкретное соединение, то из WSPSocket достаточно вернуть оригинальный идентификатор сокета — все дальнейшие вызовы пойдут к провайдеру его создавшему и минуют Вас

IG_>А вот это я не понял...
IG_>Во-первых при вызове WSPSocket соединение еще не создано (и не факт, что будет создано — например создание слушающего сокета).
IG_>А во-вторых это каким макаром все вызовы пойдут не через меня?

С каждым сокетом ассоциирован провайдер. Когда Вы создаете сокет через WPUCreateSocketHandle Вы же указываете его номер. Если Вы в своей ф. WSPSocket не подмените дескриптор, а вернете оригинальный, все дальнейшие вызовые пойдут тому провайдеру, который создал этот дескриптор.

На мой взгляд, это дурацкая концепция. По сути паралелльно могут работать два провайдера, хотя всем ново созданным сокетам и будут подсовывать самого верхнего. И это приводит к одному неприятному багу во время "горячей" инсталляции и деинсталяции. Если без всякого "хакерства", то LSP фильтр сразу после инсталяции работает с некоторыми приложениями (в т.ч. и системными, такими как winlogon) некорректно и блокирует соединения.

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

TC>Все равно в коде будет баг. Когда упадет IE из за Вашей (или моей ) ошибки, пользователь скажет "е...й IE и MS", а когда упадет ваш драйвер и вся система из-за ошибки и похерит еще какой нибудь рабочий файл, который пользователь должен был редактировать а в место чего сидел в инете, угадайте, что он скажет?

"е...й Windows и MS"
Тем более, что источник ошибки без отладчика иногда понять просто нельзя.

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

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

TC>>Все равно в коде будет баг. Когда упадет IE из за Вашей (или моей ) ошибки, пользователь скажет "е...й IE и MS", а когда упадет ваш драйвер и вся система из-за ошибки и похерит еще какой нибудь рабочий файл, который пользователь должен был редактировать а в место чего сидел в инете, угадайте, что он скажет?

P>"е...й Windows и MS"
P>Тем более, что источник ошибки без отладчика иногда понять просто нельзя.

Более того, его можно тщательно укрыть, наставив подобных вещей:
try {
}
catch(...)
{
throw 0; //к примеру.
}
Этак можно даже при установленном отладчике скрыться от возмездия

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

P>>Тем более, что источник ошибки без отладчика иногда понять просто нельзя.

TC>Более того, его можно тщательно укрыть, наставив подобных вещей:
TC>try {
TC>}
TC>catch(...)
TC>{
TC> throw 0; //к примеру.
TC>}
TC>Этак можно даже при установленном отладчике скрыться от возмездия

Лучше сделать jmp куда-нить в недра ядра.
Пускай само разбирается с проблемой.

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

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


P>>А при использовании Detours не становишься?
IG_>Я про Detours ничего не говорил

Тогда что предлагалось взамен?

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

IG_>>Основная проблема в том, что вы становитесь зависимым от
IG_>>моделей ввода-вывода, используемых клиентом (select, WsaAsyncSelect, etc.),

P>А при использовании Detours не становишься?

Вдогонку.
Сегодня наблюдал работу двух программ, которые одновременно пытались захучить одну и ту же системную функцию (через Detours и каким-то своим методом).

Чтотораздирающее зрелище.

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

P>Тогда что предлагалось взамен?

Смотрю тема еще жива... почему-то всем хочется что-то похакать, поснифеть, поперехватывать...

Просто человек сказал, что он не очень силен в сетевом программировании, а без хорошего знания winsock LSP не напишешь... Ну и вторя вам я предложил дрова...


Так как вопрос об LSP остался открытым, выскажу свою точку зрения, в каких случаях следует использовать LSP, а в каких нет.
Перефразировав известное высказывание замечу, что цель определяет средства. В первую очередь следует определиться с целями, которые ставятся. LSP следует использовать в случае фильтрации сетевого трафика (да и то, далеко не всегда), но не для осуществления политики сетевой безопасности (Firewall, NIDS(Network Intrusion Detection System), etc.) – для этих целей следует использовать драйвера!

Итак, если нужна фильтрация трафика , то нужно определиться с целями:

1. Просто в образовательных целях — можно, а для лучшего понимания Windows specific sockets очень даже желательно
(так сказать, достаточное условие понимания )
2. Если проект некоммерческий, то наверное не стоит, так как есть достаточно средств с подходящими лицензионными соглашениями.
3. Проект коммерческий и ни одно из фриварных средств не подходит.
На первый взгляд, LSP самое подходящее решение, но это не всегда так. О сложностях с которыми приходится сталкиваться при реализации LSP я говорил здесь

Автор: IGor_79
Дата: 19.10.04

. Тут все зависит от самого проекта – если проект короткосрочный и многое делается в режиме “quick hack’a”, либо же заранее известно клиентское приложение, трафик которого нужно мониторить, тогда LSP – то что доктор прописал. Достаточно взять ms-овский готовый шаблон и “прикрутить” к нему необходимую функциональность. Если имя процесса известно, то это сильно упрощает жизнь, так как нет необходимости аттачиться к остальным процессам и можно “забить” на различные модели ввода-вывода и сконцентрироваться только на одной – используемой данным приложением. Но если проект долгосрочный, если в дальнейшем он будет требовать сопровождения, будет развиваться, будет добавляться новая функциональность, заранее неизвестны поддерживаемые клиенты, тогда про LSP стоит забыть и обратить взгляд в сторону драйверов.
Возможен и такой вариант – сначала пишется функционал и прикручивается к LSP, но с таким учетом, чтобы в дальнейшем перейти на драйвера. Можно пойти дальше – отделить движок, от транспортного канала(LSP, драйвер), введя еще один уровень абстракции, скрывающий низкоуровневые детали, таким образом при переходе с LSP на драйвер в движке даже ничего не нужно будет менять. Но это имеет смысл в случае, если движок достаточно тяжеловесный и не имеет смысла тянуть его в режим ядра, либо если он выполняет и другие функции несвязанные с мониторингом трафика.

ЗЫ
Еще отмечу, что проводилось маленькое исследование на тему использования LSP различными компаниями
Так вот, используют LSP единицы, большинство — драйвера

ЗЫЗЫ
Сори что так длинно получилось – сам не ожидал

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

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

TC>>Все равно в коде будет баг. Когда упадет IE из за Вашей (или моей ) ошибки, пользователь скажет "е...й IE и MS", а когда упадет ваш драйвер и вся система из-за ошибки и похерит еще какой нибудь рабочий файл, который пользователь должен был редактировать а в место чего сидел в инете, угадайте, что он скажет?

P>"е...й Windows и MS"
P>Тем более, что источник ошибки без отладчика иногда понять просто нельзя.

Боюсь, что если даже упадет где-то сервер под unix, то юзер все равно скажет
"е..й IE, Windows и MS"...