sniffer ИСОДЯЩЕГО траффика

Возможно, можно и проще, но получить довольно полный контроль над стеком TCP/IP без написания драйвера можно через layered service provider (LSP).

А можно примерчик хоть, или ссылку... я с LSP никогда дела не имел, не знаю даже с чего начать...

Начни с Google или c MSDN.
http://www.microsoft.com/msj/0599/LayeredService/LayeredService.aspx

эх... английский я вроде неплохо знаю... но может есть другие ресурсы? :о) очень нужен пример...
Я даже NDIS теперь приветствую, надо ХОТЬ КАК-ТО это сделать...

В одном из примеров снифера я нашол такую строчку:
#define SIO_RCVALL 0x98000001
По каким принципам берется число 0x98000001?:confused:

По каким принципам вообще выбираются системные константы? :-)

Без понятия. Автор же статьи откудато откопал это число?!

Mad Kit, автор статьи столкнулся с проблемой - снифер не отлавливает исходящие пакеты. Я тоже сталкивался с этим в свое время, но забил за не надобностью. :-)

Код из моего снифера:



Вот что я нарыл с свое время по этому поводу:

[FONT="Times New Roman"]"IP-пакеты (дейтаграммы), источником которых является приложение пользователя, инкапсулируются в Ethernet-кадры. Каждый кадр содержит исходный IP-пакет и другую информацию, необходимую для доставки его адресату, в частности, 6-ти байтовый Ethernet-адрес (MAC-адрес) назначения, который при помощи протокола ARP ставится в соответствие IP-адресу назначения. На уровне протокола Ethernet маршрутизация отсутствует. Другими словами, кадр, отправленный хостом-отправителем, не попадает напрямую хосту-получателю, а будет доступен для ВСЕХ хостов, объединенных в сеть. Каждая сетевая карта принимает кадр и считывает из него первые 6 байт. Эти байты содержат MAC-адрес хоста-получателя, но только одна карта в сети определит его как свой собственный, и передаст кадр для дальнейшей обработки сетевому драйверу." [/FONT]

Режим promiscuous всего лишь отключает эту проверку первых шести байт. Нам будут доступны ВСЕ кадры гуляющие по сети! :-) Но для нас они являлются ВХОДЯЩИМИ, этот режим не будет отлавливать ИСХОДЯЩИЕ кадры. Вот с этим и столкнулся ШпиЁн :-) Решение этой проблемы - порыться в DDK, откопать что-либо с NDIS, драйвер точно поможет :-)

Полезная информация( если можно ссылочку дай плз ), но вопрос мой был в другом. Я тоже нашол этот снифер и даже успел его переписать что бы он еще высвечивал порты на которые приходят сообщения, но вот о том почему константа SIO_RCVALL должна содержать именно такое число никто пока не сказал. В МСДН по этому поводу указано ряд других констант которые получаются установлением определенных битов но вот про двоичное число: 10000000000000000000000000011001 равное 0x98000001 там ничего не сказано! Помогите плз.

[QUOTE=Mad Kit]...но вот о том почему константа SIO_RCVALL должна содержать именно такое число никто пока не сказал... [/QUOTE]

А никто тебе это и не скажет, просто в Microsoft решили что именно это число должно быть.

Вот что лежит в mstcpip.h


Вот что лежит в winsock2.h

и там же


После последовательного применения оператора OR как раз и получится 0x98000001 :-)

В твоем примерчике зачем-то переопределили то, что уже определено заранее :-)))))))

Большое спасибо.

Tak а проблему с ишодясшим трафиком как решить

У меня на виртуальном интерфеисе не читает ишодяшии
а на физическом - Ок

Кто может знает в чем дело

входящий траф считать очень просто - описано выше.
исходящий траф считать очень сложно, нужно вклиниться в систему. но есть способ, решения есть у любой проблемы - нужно написать layered service provider, и можно контролировать весь траф на системе, узнавать кто, куда, откуда и т.д... или написать драйвер ndis... я пока изучаю и то, и другое, успехи есть, но малые, помочь особо не могу :-)))

Тогда у меня вопрос по входящему трафику

А входящие ВПН пакеты он тоже считает ?
Каким образом ?
Ведь там адресат зашифрован ?

Пример.

Есть сетевая карта ПК1 192.168.0.1
и ПК 2 192.168.2.50


Задача считать трафик между ПК1 и ПК2 идущий через ВПН


Имеется ВПН сервер Напр 214.136.35.28 .
ПК1 к нему подключается.
На ПК1 тут же Создаётся виртуальный интерфейс. Напр 10.0.0.1
Прокладывается маршрут все пакеты
на ПК2- 192.168.2.50 направлять через 10.0.0.1 (в ВПН)

Теперь если ты наблюдаешь сетевую карту то видишь пакеты
пересылаемые между ПК1 и ВПН-сервером
192.168.0.1 и 214.136.35.28 но
не знаешь какой из них идёт на ПК2

Если ты наблюдаешь пакеты через виртуальный интерфейс
то как ты правильно заметил (я тоже это вижу)
видны только входящие
от ПК2 192.168.2.50 на вирт интерфейс 10.0.0.1
и ни одного исходящего.

Так вот у меня подозрение, что даже входящий трафик
мы видим не полный. мы видим только какие то сервисные
ТСП пакеты, но не сами ВПН пакеты с информацией.
Их мы не видим ни входящие ни исходящие.
Я проверял суммы с трафиком между ПК1 и ВПН-сервером
192.168.0.1 и 214.136.35.28

Так вот там входящий траффик значительно больше.
ЧТо подтверждает мои подозрения.

Если ты не используешь ВПН,
а хочешь посчитать прямое соединение
то проблем нет.
возьми сниффер v2software у меня он считает отлично и вход и выход.
Хочешь - скину.

А в случае с ВПН - надо либо раскодировать пакет
либо действительно делать это на уровне НДИС

набери NDIS тут
http://www.codeproject.com тут есть примеры драйверов

Если чего получится - можешь скинуть ?
student-uni sobaka mail.ru
мне похоже это предстоит тоже копать

Спасибо

хм... насчет VPN я мало что знаю. Допустим у компУтера адрес 192.168.0.56, он сможет принимать входящие пакеты только с адресов 192.168.0.1 - 192.168.0.255. Где-то я прочел про это, а вот где - не помню.
Если очень хочется натворить чудес в сети, то нужно разбирать source замечательной програмки winpcap ;) А насчет NDIS - это конечно, тоже выход, но я пришел к выводу что это уж больно сложно. Мне нужно было перехватывать ВЕСЬ траф на ОДНОМ компе, и это можно сделать и на более высоких уровнях - тот же LSP это позволяет.

Но я все равно что-нибудь придумаю, если что получится - скину. :-)))