Usb сниффер своими руками

Введение в перехват USB команд с помощью Wireshark

Введение

Недавно у меня на работе возникла задача повторить работу программы настройки одного навигационного устройства и поэтому я стал изучать тему, как можно перехватить данную информацию без полного реверс инжинеринга самого ПО и прошивки устройства. В итоге выяслилось что это можно сделать по средствам перехвата USB трафика, о чем я ниже напишу.

Кратко о USB

USB является хост-ориентированной шиной с топологией многоуровневой звезды. На шине может присутствовать только один хост и до 127 устройств. Каждое устройство может иметь до 32 концевых точек (endpoint) — 16 на приём и 16 на передачу. Все передачи на шине инициирует только хост — устройство может передавать данные только тогда, когда хост запросит их.

Также у USB есть многослойная система протоколов. Самый нижний слой обычно реализован в железе, поэтому он не так важен для нас.

Далее идет транспортный слой, который работает через каналы (pipe). Каналы делятся на:

• потоковые, которые передают разные данные
• каналы сообщений, которые используются для управления устройствами, в каждом устройстве минимум один такой канал.

Верхний уровень — это уровень протоколов приложения (или класса в USB терминах), например USB Mass Storage (флэшки) или Human Interface Devices (HID) — устройства для взаимодействия человека с компьютером.

На уровне программного обеспечения, минимальная неделимая единица – трансфер. По типам трансферы бывают следующие:

• прерывания (interrupt) — передают данные по чуть-чуть в реальном времени, хост не должен тормозить, и эти события не должны потеряться
• изохронные (isochronous) — работают также как и прерывания, но могут передавать больше данных и могут допускать их потерю, если это не критично
• пакетные (bulk) — предназначены для больших объёмов
• управляющие (control) — используются для управления устройствами, и только у них есть жёстко заданный формат запросов и ответов.

Для отправки сообщений устройству используются управляющие трансферы, так как они (единственные из всех) являются двунаправленными и ориентированы на обмен сообщениями, они состоят из 3-х фаз:

1. Хост предает девайсу пакет с настройками (подобно заголовку сообщения)
2. Далее передаются данные (аналогично телу сообщения), направление передачи зависит от настроек.
3. Посылается подтверждение о корректной обработки сообщения, направление противоположно предыдущем из п. 2.

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

Пример перехвата USB трафика с Wireshark

Для перехвата USB траффика можно использовать популярный снифер Wireshark. Для Windows также необходимо установит USBPcap.

Запустить прехват можно выбрав соответствующий режим в wireshark:

Разберем подробней пример дампа:

Этот дамп содержит 2 части:

1. Это подключение физического устройства в USB (пакеты 1-9);
2. Отправка команд на переключение устройства в другой режим (пакеты 9-16).

Схематично взаимодействие будет выглядеть так:

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

Наибольший интерес вызывают пакеты 9-16, так как видно что это контрольные трансферы (URB_CONTROL) а значит именно с их помощью происходит управление устройствам.

Итак первая команда (пакет 9) отправляет какую-то команду на устройство. Об этом свидетельствует префикс out, так как команды всегда идут от хоста, то перфикс задает напрваление относительно него.

Если посмотреть структуру запроса, то можно понять тип запроса, сам запрос длину тела и сами данные которые отправляются на устройство. В нашем случае не важно что означают эти параметры так как нам нужно просто воспроизвести функциональность стороннего ПО.

Следующий код запрашивает состояние устройства:

Затем отправляется еще одна команда с данными (пакет 13) и еще раз читает состояние (пакет 13), после чего можно заметить что девайс переподключился (пакет 17-18).

Реализация перехваченной функциональности

После анализа дампа понятно какие команды нужно отправить на устройство для воспроизведения работы анализируемого ПО.

Для простоты воспроизведем эти команды с помощью пакета PyUSB.

Скрипт будет выглядеть так:

Также важно отметить что команды отправляются не функцией write как описано в документации, а функцией ctrl_transfer , которая как раз отвечает за работу с контрольными трансферами.

Заключение

По сути анализ работы по USB дампам не сильно отличается от анализа сетевого трафика и если у вас есть минимальный опыт работы c wireshark то вы сможете без проблем разобраться с базовыми вещами не требующими глубокого понимания.

Источник

Нужен USB сниффер на Arduino

Есть компьютер и фискальный регистратор. Работают по USB, все ОК.

Нам интересно знать, что продает касса. Нужно установить в разрыв (проводов) платы Ардуино (теоретически не только их) и:

а) Аккуратно все передавать «как было». Чтобы система работала как и раньше. Либо мы создаем повторитель, либо, что еще лучше «провода как были, так и идут». Мы к нужным параллельно подключаемся.

б) Нужно знать, что пошло в продажи.

в) Соответственно, нужно знать, попал чек в фискалку (но 99% что должен попать).

P.S. Информацию не модифицируем.

г) При некоторых чеках (например там нужны нам товар) мы передаем эту информацию в еще 1 порт. Либо RS232, либо USB.

Собственно, USB сниффер не такая уж редкая вешь. И в сети есть хорошее видео (на Ютубе).

Там исполнитель взял 2 платы — Леонардо + USB Host Shield

1. Почему он взял 2 платы — почему 1 не хватает? Какие еще расклады у меня (по части Ардуино) есть.

2. У него это работает как повторитель (то есть получили сигнал, сохрали значение, отбили на другом порту) или же речь идет о параллельном подключение (идут 2 или 4 провода, к 3 из 4 параллельно подключились и слушаем. Если например «наша слушалка накроется», то работать все будет «как прежде», так как провода никто не перерезал.

3. Как этот «бутерброд» будет отображаться на компьютере? как некое новое устройство или как?

P.S. Мне желательно сделать с «параллельным подключением» и без «нового устройства». Т.е. если фискальный регистратор имеет какой то HID ID, то пусть он и сохраняется.

Посоветуйте варианты или предложите Ваши услуги.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Источник

Пишем простой сниффер под Windows

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

upd: По совету Weageoo, выложил на гитхаб.

Источник