Помощник
 |
|
Разработка бизнес сайтов Нужны клиенты? Тогда сюда быстрее... |
Сообщение сайта
Здравствуйте, гость ( Вход | Регистрация )
 Анализатор трафика, проблемма с winpcap |
|
|
 19:04:2008, 17:38
 
|
|
Новенький  Группа: Программист Сообщений: 49 Регистрация: 26:03:2007 Из: Кривой Рог Пользователь №: 9 890 Специализация: Программист Репутация:  0 
 |
Здроавствуйте мне необходимо написать прогармму для анализа локального траффика, это сниффер(для получения пакетов) и потом анализ этих пакетов. Я почитал много литературы и узнал что лутчше это делать с помощью библиотеки/драйвера libpcap, а для виндовса winpcap, скачал эту библиотеку/драйвер установил, паралельно нашел как с этой библиотекой работать , начал исать программу и при подключении файла <pcap.h> компилятор выдает ошибку что неможет найти этого файла. Подскажите что я делаю не правильно.
P.S. Использую компилятор BCB 6 |
 |
Сообщение
#1
|
 |
|
|
4:05:2008, 21:51
|
|
Новенький Группа: Программист Сообщений: 39 Регистрация: 3:04:2008 Пользователь №: 16 361 Репутация: 1
|
Ну вроде все работает,начнем))
Рассказывать буду напримере IP. Первым делом идем к гуглю и спрашиваем RFC IP. Выдает нам что rfc ip протокола номер 791. Если траблы с английским,то ищем "RFC 791 на русском". Идем по первой попавшейся ссылке. http://www.free.net/Info/usmanov-01/rfc791.htm Если вы мазохист или же нужно досконально разобраться в протоколе,то читаем все. Находим структуру заголовка. Там вот такая бодяга. Код +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Как написано,каждая позиция соответствует одному биту. Можно читать,а можно и самому крестики/плюсики считать. Для начала объявим структуру,пока что пустую. Ну например так. Код struct ip_header { } Первым у нас идет поле Version,и занимает оно у нас 4 бита. Цитата Version (версия) 4 бита Поле версии показывает формат заголовка Internet. Данный документ описывает версию 4. Значит нам нужно поле в 4 бита. Код struct ip_header { unsigned int version: 4; } имя можно задавать любое,какое душе угодно,главное чтобы размер подходил. Далее идет поле IHL,тоже 4 бита. Цитата IHL (длина Internet заголовка) 4 бита Длина Internet заголовка измеряется в словах по 32 бита каждый и указывает на начало поля данных. Заметим, что корректный заголовок может иметь минимальный размер 5 слов. Дополняем нашу структуру: Код struct ip_header { unsigned int version: 4; unsigned int ihl: 4; } Далее у нас идет Type of Service-8 бит. Для этого поля лучше создать свою структуру Цитата Type of Service (тип сервиса) 8 бит Тип сервиса определяет с помощью неких абстрактных параметров тип требуемого обслуживания. Эти параметры должны использоваться для управления выбором реальных рабочих характеристик при передаче датаграммы через конкретную сеть. Некоторые сети осуществляют обслуживание с приоритетом, которое неким образом дает преимущество для продвижения данной датаграммы по сравнению со всеми остальными. Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью. биты 0-2 приоритет бит 3 0 - нормальная задержка, 1 - малая задержка бит 4 0 - нормальная пропускная способность, 1 - высокая пропускная способность бит 5 0 - обычная достоверность, 1 - высокая достоверность биты 6-7 зарезервированы 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | приоритет | D | T | R | 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ Разъяснять написание структуры уж не буду,просто приведу ее в конце. Структура так и будет называться TypeOfService; Дополняем структуру IP заголовка. Код struct ip_header { unsigned int version: 4; unsigned int ihl: 4; struct TypeOfService typeServ; } Total Length,Identification. Оба по 16 бит,то есть два байта. Цитата Total Length (общая длина) 16 бит Общая длина - это длина датаграммы, измеренная в октетах, включая Internet заголовок и поле данных. Это поле может задавать длину датаграммы вплоть до 65535 октетов. В большинстве хост-компьютеров и сетей столь большие датаграммы не используются. Все хосты должны быть готовы принимать датаграммы вплоть до 576 октетов длиной (приходят ли они целиком или по фрагментам). Хостам рекомендуется отправлять датаграммы размером более чем 576 октетов, только если они уверены, что принимающий хост готов обслуживать датаграммы повышенного размера. Значение 576 выбрано с тем, чтобы соответсвующим образом ограниченный блок данных передавался вместе с требуемой информацией в заголовке. Например, этот размер позволяет заполнять датаграмму полем данных размером в 512 октетов и заголовком в 64 октета. Наибольший Internet заголовок занимает 60 октетов, а его типичный размер составляет всего 20 октетов, что оставляет место под заголовки протоколов более высокого уровня. Identification (идентификатор) 16 бит Идентификатор устанавливается отправителеим для сборки фрагментов какой-либо датаграммы. А два байта у нас занимает тип short. Дописываем Код struct ip_header { unsigned int version: 4; unsigned int ihl: 4; struct TypeOfService typeServ; short length; short id; } Далее поле Flags,занимает 3 бита.В переводе RFC по ссылке,которую я дал ошибка,там написано 16 бит.На самом деле 3. Цитата Flags (различные управляющие флаги) 3 бита бит 0 зарезервирован, должен быть нуль бит 1 (DF) 0 - возможно фрагментирование, 1 - запрет фрагментации бит 2 (MF) 0 - последний фрагмент, 1 - будут еще фрагменты 0 1 2 +----+----+----+ | 0 | DF | MF | +----+----+----+ Дорисываем в структуру еще одно значение. Код unsigned int flags:3; unsigned int везде пишу не по каким-то правилам,а так,от балды  Далее: Цитата Fragment Offset (смещение фрагмента) 13 бит Это поле показывает, где в датаграмме находится этот фрагмент. Смещение фрагмента изменяется порциями по 8 октет (64 бита). Первый фрагмент имеет смещение нуль. Код unsigned short offset: 13; Далее у нас идет время жизни в размере 8 бит или одного байта. Цитата Time to Live (Время жизни) 8 бит Это поле показывает максимальное время, в течении которого датаграмме позволено находиться в системе Internet. Если это поле имеет значение нуль, то датаграмма должна быть разрушена. Значение этого поля изменяется при обработке заголовка Internet. Время измеряется в секундах. Однако, поскольку каждый модуль, обрабатывающий датаграмму, должен уменьшать значение поля TTL по крайней мере на единицу, даже если он обрабатываетт эту датаграмму менне, чем за секунду, то поле TTL следует понимать как максимальный интервал времени, в течении которого датаграмма может сущенствовать. Внимание следует обратить на разрушение датаграмм, не могущих достигнуть получателя, а также на ограничение времени жизни датаграммы. Подойдет тип char. Дописываем. Код unsigned char timeLive; Далее идет протокол в размере 8 бит,протоколы описаны в документе "Assigned Numbers". В сети не составит труда его найти. Цитата Protocol (Протокол) 8 бит Это поле показывает, какой протокол следующего уровня использует данные из Internet датаграммы. Значения для различных протоколов приводятся в документе "Assigned Numbers" [9]. Код unsigned char proto; Цитата Header Checksum (Контрольная сумма заголовка) 16 бит Поскольку некоторые поля заголовка меняют свое значение (например, время жизни), это значение проверяется и повторно рассчитывается при каждой обработке Internet заголовка. Алгоритм контрольной суммы следующий: Поле контрольной суммы - это 16 бит, дополняющие биты в сумме всех 16 битовых слов заголовка. Для вычисления контрольной суммы значение этого поля устанавливается в нуль. Контрольную сумму легко рассчитать и опытным путем доказать ее адекватность, однако это временная мера и должна быть заменена CRC процедурой в зависимости от дальнейшего опыта. Дописываем поле для контрольной суммы. Код unsigned short ckeksum; Далее идут адреса отправителя и получателя. Цитата Source Address (адрес отправителя) 32 бита Destination Address (адрес получателя) 32 бита Здесь не будем ничего придумывать своего,а исполльзуем уже определенную структуру для IP адресов. Код struct in_addr source_addr; struct in_addr dest_addr; Ну вот и все,далее идут опции,поле переменной длины, тут уж разбирайся сам,впринципе ничего сложного нет,по аналогии составляешь структуру,можно в нете найти,если неохота изобретать велосипед. Ну и в конце привожу,как все это выглядит вместе. Код struct TypeOfService { unsigned int Priority: 3; unsigned int D: 1; unsigned int T: 1; unsigned int R: 1; unsigned int reserved:2; } struct ip_header { unsigned int version: 4; unsigned int ihl: 4; struct TypeOfService typeServ; unsigned short length; unsigned short id; unsigned int flags:3; unsigned short offset: 13; unsigned char timeLive; unsigned char proto; unsigned short ckeksum; struct in_addr source_addr; struct in_addr dest_addr; } Ну вот такой маленький тутор получился. Так как в будущем планирую открыть свою хом пагу, то поставлю на всякий случай копирайт))). зы.Обычно я под другим ником,просто тут так зарегился)). ©btrfly, 2008; Сообщение отредактировал ReindeeR - 4:05:2008, 23:34 |
|
|
Сообщение
#31
|
|
|
4:05:2008, 23:35
|
|
Новенький Группа: Программист Сообщений: 39 Регистрация: 3:04:2008 Пользователь №: 16 361 Репутация: 1
|
p.s. в некоторых импровизированных таблицах все сбилось  ,так что лучше смотреть в оригинале. |
|
|
Сообщение
#32
|
|
|
10:05:2008, 21:11
|
|
Новенький Группа: Программист Сообщений: 49 Регистрация: 26:03:2007 Из: Кривой Рог Пользователь №: 9 890 Специализация: Программист Репутация: 0
|
Спасибо хороший ответ ))
Всё изложено грамотно и доступно )) Остался только один вопрос а как получить мак адрес получателя и отправителя, пробовал создавать структру как и для ап адресса, но забивает ерундой, в той структуре что написана там просто адресс источника и приемника 32 бита это только под ап отводится а как тогда мак достать? |
|
|
Сообщение
#33
|
|
|
10:05:2008, 21:21
|
|
Новенький Группа: Программист Сообщений: 39 Регистрация: 3:04:2008 Пользователь №: 16 361 Репутация: 1
|
мак передается в ethernet заголовке.
в IP заголовке соответственно айпи получателя и отправителя. ап. и если ARP,то мак можно еще и оттуда выудить. Сообщение отредактировал ReindeeR - 10:05:2008, 21:25 |
|
|
Сообщение
#34
|
|
|
21:05:2008, 17:17
|
|
Новенький Группа: Программист Сообщений: 49 Регистрация: 26:03:2007 Из: Кривой Рог Пользователь №: 9 890 Специализация: Программист Репутация: 0
|
Есть ли возможность получить имя компютера, тоесть оно передаеться в пакете или нет?
Как можно узнать конечный/начальный адресс назначения, тоесть если я к примеру получаю данные от компютера из интернета, посредством тогоже торрента, у меня сниффер получает адресс шлюза , а не той машини. |
|
|
Сообщение
#35
|
|
|
1:06:2008, 13:48
|
|
Новенький Группа: Программист Сообщений: 39 Регистрация: 3:04:2008 Пользователь №: 16 361 Репутация: 1
|
Цитата(S-haman @ 21:05:2008 - 21:17)  Есть ли возможность получить имя компютера, тоесть оно передаеться в пакете или нет? точно не помню,но вроде можно.погуглите на этот счет. Цитата(S-haman @ 21:05:2008 - 21:17) Как можно узнать конечный/начальный адресс назначения, тоесть если я к примеру получаю данные от компютера из интернета, посредством тогоже торрента, у меня сниффер получает адресс шлюза , а не той машини. с торрентами никогда не связывался,так что предположение: посмотрите протокол торрента,как и че там устроено. из айпи заголовков скорее всего нельзя вытянуть,так как там указывается шлюз сервера. |
|
|
Сообщение
#36
|
|
|
Текстовая версия | Сейчас: 6:07:2008 - 00:45 |
