Сниффер для локальной сети c builder. Пишем простой сниффер под Windows. Описание структуры IP-пакета

Дата: 27.12.2022

В этой статье мы рассмотрим создание простого сниффера под ОС Windows.
Кому интересно, добро пожаловать под кат.

Введение

Цель: написать программу, которая будет захватывать сетевой трафик (Ethernet, WiFi), передающийся по протоколу IP.
Средства: Visual Studio 2005 или выше.
Подход, который здесь описан, не принадлежит лично автору и успешно применяется во многих коммерческих, а также категорически бесплатных программах (привет, GPL).
Сей труд предназначен прежде всего для новичков в сетевом программровании, которые, однако, имеют хотя бы базовые знания в области сокетов вообще, и windows-сокетов в частности. Здесь я часто буду писать общеизвестные вещи, потому что предметная область специфическая, если что-то пропустить - в голове будет каша.

Надеюсь, Вам будет интересно.

Теория (читать не обязательно, но желательно)

В данный момент подавляющее большинство современных информационных сетей базируются на фундаменте стека протоколов TCP/IP. Стек протоколов TCP/IP (англ. Transmission Control Protocol/Internet Protocol) - собирательное название для сетевых протоколов разных уровней, используемых в сетях. В настоящей статье нас будет интересовать в основном протокол IP - маршрутизируемый сетевой протокол, используемый для негарантированной доставки данных, разделяемых на так называемые пакеты (более верный термин – дейтаграмма) от одного узла сети к другому.
Особый интерес для нас представляют IP-пакеты, предназначенные для передачи информации. Это достаточно высокий уровень сетевой OSI-модели данных, когда можно обстрагироваться от устройства и среды передачи данных, оперируя лишь логическим представлением.
Совершенно логичным является то обстоятельство, что рано или поздно должны были появится инструменты для перехвата, контроля, учета и анализа сетевого трафика. Такие средства обычно называется анализаторами трафика, пакетными анализаторыми или снифферами (от англ. to sniff - нюхать). Это - сетевой анализатор трафика, программа или программно-аппаратное устройство, предназначенное для перехвата и последующего анализа, либо только анализа сетевого трафика, предназначенного для других узлов.

Практика (разговор по существу)

На данный момент создано достаточно много программного обеспечения для прослушивания трафика. Наиболее известный из них: Wireshark . Естественно, пожинать его лавры цель не стоит - нас интересует задача перехвата трафика методом обычного «прослушивания» сетевого интерфейса. Важно понимать, что мы не собираемся заниматься взломом и перехватывать чужой трафик. Нужно всего лишь просматривать и анализировать трафик, который проходит через наш хост.

Для чего это может понадобиться:

Смотреть текущий поток трафика через сетевое соеднинение (входящий/исходящий/всего).
Перенаправлять трафик для последующего анализа на другой хост.
Теоретически, можно попытаться применить его для взлома WiFi-сети (мы ведь не собираемся этим заниматься?).

В отличие от Wireshark, который базируется на библиотеке libpcap/WinPcap, наш анализатор не будет использовать этот драйвер. Чего уж там, у нас вообще не будет драйвера, и свой NDIS(о ужас!) мы писать не собираемся. Про это можно прочитать в этом топике . Он будет просто пассивным наблюдателем, использующим только библиотеку WinSock. Использование драйвера в данном случае избыточно.

Как так? Очень просто.
Ключевым шагом в превращении простого сетевого приложения в сетевой анализатор является переключение сетевого интерфейса в режим прослушивания (promiscuous mode), что и позволит ему получать пакеты, адресованные другим интерфейсам в сети. Этот режим заставляют сетевую плату принимать все кадры, вне зависимости от того, кому они адресованы в сети.

Начиная с Windows 2000 (NT 5.0) создать программу для прослушивания сегмента сети стало очень просто, т.к. ее сетевой драйвер позволяет перевести сокет в режим приёма всех пакетов.

Включение неразборчивого режима

long flag = 1; SOCKET socket; #define SIO_RCVALL 0x98000001 ioctlsocket(socket, SIO_RCVALL, &RS_Flag);

Наша программа оперирует IP-пакетами, и использует библиотеку Windows Sockets версии 2.2 и «сырые» сокеты (raw sockets). Для того чтобы получить прямой доступ к IP-пакету, сокет нужно создавать следующим образом:

Создание сырого сокета

s = socket(AF_INET, SOCK_RAW, IPPROTO_IP);

Здесь вместо константы SOCK_STREAM (протокол TCP) или SOCK_DGRAM (протокол UDP), мы используем значение SOCK_RAW . Вообще говоря, работа с raw sockets интересна не только с точки зрения захвата трафика. Фактически, мы получаем полный контроль за формированием пакета. Вернее, формируем его вручную, что позволяет, например, послать специфический ICMP-пакет…

Идем дальше. Известно, что IP-пакет состоит из заголовка, служебной информации и, собственно, данных. Советую заглянуть сюда , чтобы освежит знания. Опишем в виде структуры IP-заголовок (спасибо отличной статье на RSDN ):

Описание структуры IP-пакета

typedef struct _IPHeader { unsigned char ver_len; // версия и длина заголовка unsigned char tos; // тип сервиса unsigned short length; // длина всего пакета unsigned short id; // Id unsigned short flgs_offset; // флаги и смещение unsigned char ttl; // время жизни unsigned char protocol; // протокол unsigned short xsum; // контрольная сумма unsigned long src; // IP-адрес отправителя unsigned long dest; // IP-адрес назначения unsigned short *params; // параметры (до 320 бит) unsigned char *data; // данные (до 65535 октетов) }IPHeader;

Главная функция алгоритма прослушивания будет выглядеть следующим образом:

Функция захвата одного пакета

Здесь все просто: получаем порцию данных с помощью стандартной функции socket-функции recv , а затем копируем их в структуру типа IPHeader .
И, наконец, запускаем бесконечный цикл захвата пакетов:

Захватым все пакеты, которые попадут на наш сетевой интерфейс

while (true) { IPHeader* hdr = RS_Sniff(); // обработка IP-пакета if (hdr) { // печатаем заголовок в консоли } }

Немного оффтопика

Здесь и далее у некоторых важных функций и переменных автор сделал префкис RS_ (от Raw Sockets). Проект делал 3-4 года назад, и была шальная мысль написать полноценную библиотеку для работы с сырыми сокетами. Как это часто бывает, после получения сколь-нибудь значимых(для автора) результатов, энтузиазм угас, и дальше учебного примера дело не полшло.

В принципе, можно пойти дальше, и описать заголовки всех последующих протоколов, находящихся выше. Для этого необходимо анализировать поле protocol в структуре IPHeader . Посмотрите на пример кода (да, там должен быть switch, чёрт возьми!), где происходит раскрашивание заголовка в зависимости от того, какой протокол имеет пакет, инкапсулированный в IP:

/* * Выделение пакета цветом */ void ColorPacket(const IPHeader *h, const u_long haddr, const u_long whost = 0) { if (h->xsum) SetConsoleTextColor(0x17); // если пакет не пустой else SetConsoleTextColor(0x07); // пустой пакет if (haddr == h->src) { SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_RED | FOREGROUND_INTENSITY); // "родной" пакет на отдачу } else if (haddr == h->dest) { SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_GREEN | FOREGROUND_INTENSITY); // "родной" пакет на прием } if (h->protocol == PROT_ICMP || h->protocol == PROT_IGMP) { SetConsoleTextColor(0x70); // ICMP-пакет } else if(h->protocol == PROT_IP || h->protocol == 115) { SetConsoleTextColor(0x4F); // IP-in-IP-пакет, L2TP } else if(h->protocol == 53 || h->protocol == 56) { SetConsoleTextColor(0x4C); // TLS, IP with Encryption } if(whost == h->dest || whost == h->src) { SetConsoleTextColor(0x0A); } }

Однако это существенно выходит за рамки этой статьи. Для нашего учебного примера вполне достаточно будет посмотреть ip-адреса хостов, с которых и на которые идет трафик, и посчитать его количество в единицу времени(готовая программа в архиве в конце статьи).

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

Преобразование IP-заголовка в строку

На основании приведенных выше базовых сведений, получается вот такая небольшая программа (жуткое название ss, сокр. от англ. simple sniffer), реализующая локальное прослушивание IP-трафика. Интерфейс ее приведен ниже на рисунке.

Исходный и бинарный код предоставляю как есть, таким как он был несколько лет назад. Сейчас мне на него страшно смотреть, и все же, он вполне читабельный (конечно же, нельзя быть таким самоуверенным). Для компиляции будет достаточно даже Visual Studio Express 2005.

Что у нас получилось в итоге:

Сниффер работает в режиме пользователя, однако требует привилегии администратора.
Пакеты не фильтруются, отображаясь как есть (можно добавить настраиваемые фильтры - предлагаю подробно рассмотреть эту тему в следующей статье, если интересно).
WiFi-трафик тоже захватывается(все зависит от конкретной модели чипа, у Вас может и не работать, как у меня несколько лет назад), хотя есть AirPcap, которая чудесно это умеет делать, но стоит денег.
Весь поток дейтаграмм логируется в файл (см. архив, приложенный в конце статьи).
Программа работает в качестве сервера на порту 2000. Можно подключиться с помощью утилиты telnet к хосту и произвести мониторинг потоков трафика. Количество подключений ограничено двадцатью (код не мой, нашел на просторах сети и применял для экспериментов; удалять не стал - жалко)

Спасибо за внимание, проздравляю иок и всех-всех-всех с наступающим Рождеством!

В этой статье мы рассмотрим создание простого сниффера под ОС Windows.
Кому интересно, добро пожаловать под кат.

Введение

Надеюсь, Вам будет интересно.

Теория (читать не обязательно, но желательно)

Практика (разговор по существу)

Для чего это может понадобиться:

Смотреть текущий поток трафика через сетевое соеднинение (входящий/исходящий/всего).
Перенаправлять трафик для последующего анализа на другой хост.
Теоретически, можно попытаться применить его для взлома WiFi-сети (мы ведь не собираемся этим заниматься?).

В отличие от Wireshark, который базируется на библиотеке libpcap/WinPcap, наш анализатор не будет использовать этот драйвер. Чего уж там, у нас вообще не будет драйвера, и свой NDIS(о ужас!) мы писать не собираемся. Про это можно прочитать в . Он будет просто пассивным наблюдателем, использующим только библиотеку WinSock. Использование драйвера в данном случае избыточно.

Включение неразборчивого режима

long flag = 1; SOCKET socket; #define SIO_RCVALL 0x98000001 ioctlsocket(socket, SIO_RCVALL, &RS_Flag);
Наша программа оперирует IP-пакетами, и использует библиотеку Windows Sockets версии 2.2 и «сырые» сокеты (raw sockets). Для того чтобы получить прямой доступ к IP-пакету, сокет нужно создавать следующим образом:

Создание сырого сокета

s = socket(AF_INET, SOCK_RAW, IPPROTO_IP);
Здесь вместо константы SOCK_STREAM (протокол TCP) или SOCK_DGRAM (протокол UDP), мы используем значение SOCK_RAW . Вообще говоря, работа с raw sockets интересна не только с точки зрения захвата трафика. Фактически, мы получаем полный контроль за формированием пакета. Вернее, формируем его вручную, что позволяет, например, послать специфический ICMP-пакет…

Описание структуры IP-пакета

Функция захвата одного пакета

IPHeader* RS_Sniff() { IPHeader *hdr; int count = 0; count = recv(RS_SSocket, (char*)&RS_Buffer, sizeof(RS_Buffer), 0); if (count >= sizeof(IPHeader)) { hdr = (LPIPHeader)malloc(MAX_PACKET_SIZE); memcpy(hdr, RS_Buffer, MAX_PACKET_SIZE); RS_UpdateNetStat(count, hdr); return hdr; } else return 0; }
Здесь все просто: получаем порцию данных с помощью стандартной функции socket-функции recv , а затем копируем их в структуру типа IPHeader .
И, наконец, запускаем бесконечный цикл захвата пакетов:

Захватым все пакеты, которые попадут на наш сетевой интерфейс

while (true) { IPHeader* hdr = RS_Sniff(); // обработка IP-пакета if (hdr) { // печатаем заголовок в консоли } }

Немного оффтопика

Преобразование IP-заголовка в строку

inline char* iph2str(IPHeader *iph) { const int BUF_SIZE = 1024; char *r = (char*)malloc(BUF_SIZE); memset((void*)r, 0, BUF_SIZE); sprintf(r, "ver=%d hlen=%d tos=%d len=%d id=%d flags=0x%X offset=%d ttl=%dms prot=%d crc=0x%X src=%s dest=%s", BYTE_H(iph->ver_len), BYTE_L(iph->ver_len)*4, iph->tos, ntohs(iph->length), ntohs(iph->id), IP_FLAGS(ntohs(iph->flgs_offset)), IP_OFFSET(ntohs(iph->flgs_offset)), iph->ttl, iph->protocol, ntohs(iph->xsum), nethost2str(iph->src), nethost2str(iph->dest)); return r; }
На основании приведенных выше базовых сведений, получается вот такая небольшая программа (жуткое название ss, сокр. от англ. simple sniffer), реализующая локальное прослушивание IP-трафика. Интерфейс ее приведен ниже на рисунке.

Что у нас получилось в итоге:

Сниффер работает в режиме пользователя, однако требует привилегии администратора.
Пакеты не фильтруются, отображаясь как есть (можно добавить настраиваемые фильтры - предлагаю подробно рассмотреть эту тему в следующей статье, если интересно).
WiFi-трафик тоже захватывается(все зависит от конкретной модели чипа, у Вас может и не работать, как у меня несколько лет назад), хотя есть AirPcap, которая чудесно это умеет делать, но стоит денег.
Весь поток дейтаграмм логируется в файл (см. архив, приложенный в конце статьи).
Программа работает в качестве сервера на порту 2000. Можно подключиться с помощью утилиты telnet к хосту и произвести мониторинг потоков трафика. Количество подключений ограничено двадцатью (код не мой, нашел на просторах сети и применял для экспериментов; удалять не стал - жалко)

Спасибо за внимание, проздравляю хабровчан и хабровчанок и всех-всех-всех с наступающим Рождеством!

Добрый день! Как-то возникла на работе проблема - имеется устройство, работающее по I2С и протокол которого необходимо было понять. Следовательно, нужен сниффер под интерфейс I2С, который бы выводил все, что приходит-уходит по I2C, на порт UART и далее через преобразователь на COM-порт компьютера.

Начало

Под рукой валялись только пара атмег8 и я решил почему бы не использовать их. Далее, встал вопрос схемы сниффера.

Было 2 варианта - включать сниффер параллельно, либо в разрыв цепи. Очевидно, что первый вариант выглядит гораздо проще, что на деле оказалось совсем не так. Но обо всем по порядку.

Вкратце, о самом интерфейсе. В I2C (TWI по-атмеловски) используется два провода - SCL и SDA. Первый отвечает за тактирование сигнала, второй за передачу непосредственно информации. Также интерфейс располагает состояниями СТАРТ и СТОП.

Так вот, первая моя мысль была - взять щуп и с одной стороны подключить его к ноге внешнего прерывания на atmega8 с другой на линию SDA и ловить передний фронт, и по прошедшему времени определять 0 или 1. Очевидно, что работать это должно было очень плохо, так как не отрабатывался корректно сигнал СТОП.

Вторая мысль была сделать все то же, но прерывание ловить на линии SCL, и по прерыванию читать линию SDA, подключенную на обычную цифровую ногу. Здесь все выглядело уже более жизнеспособно, кроме того же состояния СТОП, но я решил попробовать собрать на макетке и посмотреть что же будет.

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

Код обработчика прерывания выглядел следующим образом:

ISR(INT0_vect) { cli(); if (bitIsHigh(PINB, 0)) uart_send_char("1"); else uart_send_char("0"); sei(); }
В порт потекли нули и единички, но сразу стало очевидно, что данные некорректные - их было гораздо меньше ожидаемых и они менялись при повторении одного и того же запроса. В процессе выяснения причин все свелось к тому, что данные теряли из-за обращения к uart интерфейсу, который, к слову, работал на максимальной стабильной скорости 38 кбит/с, при этом сам I2C работал на 100 кбит/с. Поднимать скорость работы UART не представлялось возможным ввиду отсутствия кристалла необходимой частоты, чтобы перевести uart на допустимую скорость. Следовательно нужно было убирать работу с uart из прерывания. Получил что-то следующее:

Static uint8_t data = 0; static uint8_t idx = 7; ISR(INT0_vect) { cli(); data |= bitIsHigh(PINB, 0) << (idx--); if (!idx) { uart_send_char(data); data = 0; idx = 7; } sei(); }
Работать все стало стабильнее, вот только данные все равно не несли никакого смысла. После нескольких часов проработки алгоритма, включения обработки СТОП и пр. все же решено было пойти другим путем.

На верном пути

Сколько бы я ни пытался реализовать сниффер по параллельной схеме включения, ничего из этого не вышло. Исходя из этого оставался только один вариант - нужно было включать микроконтроллер в разрыв, то есть он должен быть одновременно мастером для ответного устройства и подчиненным для оригинального мастера. Звучит, наверное, запутанно, но на деле все не так.

Так как atmega8 на борту имеет только один аппаратный I2C, то очевидно, что для работы нужно написать программную поддержку протокола.

В итоге получился следующий код:

ISR(TWI_vect) { cli(); uint8_t status = TWSR; uint8_t b; char s; s = 0; _delay_ms(1); switch (status & I2C_STATUS_MASK) { case I2C_STATUS_SR_RX_ADR_ACK:/* case I2C_STATUS_SR_RX_ADR_NACK:*/ uart_send_str("-AW:"); uart_send_int(TWDR); i2csoft_start(); i2csoft_open_write(I2C_ADDRESS); break; case I2C_STATUS_SR_RX_DATA_ACK:/* case I2C_STATUS_SR_RX_DATA_NACK:*/ b = TWDR; sprintf(s, " %.2X", b); uart_send_str(s); i2csoft_write_byte(b); break; case I2C_STATUS_SR_RX_STOP_RESTART: uart_send_str("E\n"); _delay_ms(10); do { _delay_us(5); i2csoft_start(); } while (!i2csoft_open_read(I2C_ADDRESS)); break; case I2C_STATUS_BUS_ERROR: uart_send_str("B\n"); break; case TW_ST_SLA_ACK: uart_send_str("-AR:"); uart_send_int(TWDR); b = i2csoft_read_byte(); sprintf(s, " %.2X", b); uart_send_str(s); TWDR = b; break; case TW_ST_DATA_ACK: b = i2csoft_read_byte(); sprintf(s, " %.2X", b); uart_send_str(s); TWDR = b; break; case TW_ST_DATA_NACK: case TW_ST_LAST_DATA: b = i2csoft_read_byte(false); uart_send_str("L\n"); break; default: uart_send_char("U"); uart_send_int(status); uart_send_char(" "); break; } TWCR |= (1< Мастер устройство подключается на аппаратный I2C атмеги, исполняющее устройство подключается на любые 2 цифровые ноги, одна из которых работает в режиме SCL, другая - SDA. Все, что делает приведенный выше код - это получает по I2C прерывание и вызывает аналогичное состояние на программном интерфейсе, при этом в uart записывается служебная информация, помогающая понять что происходит. Выставленные задержки подбирались для конкретного устройства и могут несколько отличаться для других. В итоге получаем вполне добротный сниффер.

Если кому-нибудь будет интересно, то исходники можно взять с