USBpcap что это за программа

Энумерация – часть вторая

Событийно-ориентированное программирование (event driven programming) – это то, что нужно, что бы лучше понимать работу программ микроконтроллера с аппаратной поддержкой USB. Иначе такие программы называют – программы управляемые событиями. Логика программы реализуется, как максимально изолированные обработчики спонтанных событий. Во многих объектно-ориентированных средах разработки – эта парадигма реализована. При программировании микроконтроллеров, такими обработчиками событий могут быть обработчики прерываний, а основная программа может выродиться в загрузчик пробелов, выполнять пустой цикл. Кончено обработчики прерываний общаются между собой через доступную всем обработчикам область памяти. Особенно эффективно решаются задачи, алгоритм работы которых описывается конечным автоматом. Часто такие задачи возникают при описании коммуникационных протоколов и работы технологических механизмов.

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

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

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

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

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

Переход напряжения из «0» в «1» на шине VBUS. При подключении USB устройства к хосту. Переходит из состояния «подключено» в состояние «запитано».

Переход напряжения из «1» в «0» на шине VBUS. Из любого состояния переходит в состояние «подключено».

Команда «сброс шины» (Bus Reset). Из любого состояния, кроме «подключено», переходит в состояние «дежурное».

Хост перевел сегмент шины c USB устройством в состояние «приостановлено» (Suspended state), состояние шины Bus Idle более 3 миллисекунд. Переход в состояние «приостановлено» возможен из любого состояния, кроме «подключено».

Хост выводит USB устройство из состояния «приостановлено». Хост посылает специальную команду «пробуждение» (Resume). Суть команды, из состояния J шина переводится в состояние K на 20 миллисекунд, и затем в состояние SE0 на 1,33 микросекунд и опять в состояние J на 0,66 мксек. На рисунке 21 представлена временная диаграмма. После этой команды USB устройство должно быть готово к приему пакетов SOF. По этой команде происходит возврат в активное состояние, из которого USB устройство перешло в состояние «приостановлено».

Нужно вспомнить, что USB устройство может по своей инициативе сообщить хосту о необходимости пробуждения. Устройство USB выводит хост из спящего состояния командой «удаленное пробуждение» (Upstream Resume), переводит шину на интервал от 1 до 15 миллисекунд в состояние K (K-state), перед этим шина должна быть в состоянии J как минимум 5 миллисекунд.

Команда достигает хоста и он в свою очередь отвечает командой «пробуждение» направленной к USB устройству. Команда «пробуждение» от хоста описана выше.

Стандартные управляющие запросы, должны корректно обрабатываться USB устройством. Некоторые из них выполняют функцию событий, приводящих к изменению состояния USB устройства.

На управляющий запрос Get_Device_Descriptor по нулевому адресу, в состоянии «дежурное», USB устройство остается в дежурном состоянии, выполнив посылку первых 8 байт дескриптора устройства хосту.

Управляющий запрос Set_Address назначает адрес, эффективен только в состоянии «дежурное», в остальных состояниях, должен рассматриваться как некорректный. Событие переводит USB устройство в состояние «адресовано» и присваивает адрес.

На управляющий запрос Get_Device_Descriptor , USB устройство посылает дескриптор устройства целиком, оставаясь в состоянии «адресовано». Затем хост по меньшей мере еще два раза посылается этот управляющий запрос, для получения дескриптора конфигурации и дескрипторов конечных точек. После приема дескрипторов USB устройство остается в состоянии «адресовано».

На управляющий запрос Set_Configuration, с ненулевым номером конфигурации, USB устройство переходит из состояния «адресовано» в состояние «сконфигурировано».

На управляющий запрос Set_Configuration , с нулевым номером конфигурации, если USB устройство в состоянии «сконфигурировано», переходит в состояние «адресовано».

Программное обеспечение контроллера, должно так же распознавать события по каналам передачи данных. Когда по инициативе хоста, USB устройство обработает транзакцию, то генерируется событие, которое можно условно назвать «транзакция данных обработана». Организовать обработку события можно либо опросом флагов, либо обработкой прерывания. Транзакции по каналам данных обрабатываются аппаратурой SIE. Да и по каналам управления транзакции обрабатываются аппаратурой SIE.

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

Огромную помощь в изучении шины USB может оказать анализатор протокола USB. Аппаратура такого анализатора подключается к шине, захватывает пакеты и демонстрирует на мониторе. Но такая аппаратура дорого стоит и не всегда доступна.

Другое подспорье – это программный анализатор, по своим возможностям он не сравним с аппаратным анализатором, но может оказаться очень полезным. Существует множество программных анализаторов. Мной использовалась свободная программа Wireshark (www.wireshark.org). Это программный анализатор широкого применения, чаще он применяется для анализа сетевого трафика, но можно использовать и для анализа активности USB устройств. Существуют порты как для Windows так и для Linux. Для Windows XP необходимо устанавливать версию не старше 1.10. Для Windows нужно дополнительно установить программу USBPcap, не путать с WinPcap. С Windows порядок работы следующий. После установки Wireshark, распаковываем архив с USBPcap и запускаем консольную программу USBPCapCMD.exe. Программа выводит список корневых хабов и устройств, подключенных к хабам в системе, и спрашивает, какой номер хаба выбираете, иначе говоря, какой слот будем прослушивать. Введите номер соответственный USB устройству. Затем просит ввести название файла, куда программа сбросит все захваченные данные. По Ctrl+C прерывается процесс прослушивания. Запускаем Wireshark и открываем полученный файл дампа. Можно вести мониторинг с помощью Wireshark и в реальном режиме, на родном сайте http://desowin.org/usbpcap/, привед.н образец командной строки.

Для Linux нужно ядро не моложе 2.6.21 и загруженный модуль usbmon. Только начиная с версии 1.1.0 библиотеки libpcap, правильно работает Wireshark для Linux, поэтому проверьте версию библиотеки на вашей системе. Средства перехвата даннх встроены в ядро Linux и никаких дополнительных программ устанавливать не надо.

Чтобы захватить процесс энумерации, запускаем прослушивание нужного слота, а затем в этот слот вставляем штекер исследуемого USB устройства. Экран Wireshark с запросами процесса энумерации показан на рисунке 22.

Для Windows, захватом данных занимается USBPcap, а Wireshark используется для понятного представления данных. В свою очередь USBPcap состоит из 2-х частей. Одна часть – это драйвер, работающий в пространстве ядра операционной системы, и вторая часть – это консольная программа, работающая в пространстве пользователя. В стек USB ядра операционной системы, данные поступают от драйвера в виде пакетов URB (USB request blocks). Это особые структуры, которые в себе содержат данные запросов от хоста к USB устройству. Проще говоря, URB– это некий контейнер, содержащий запрос или транзакцию ввода-вывода. Программа USBPcap перехватывает URB и передает программе пользовательского уровня. Важно понимать, что Wireshark показывает URB и содержащиеся в них данные. Без труда можно разобраться, где запросы, а где транзакции ввода-вывода.

Выводимые на экран данные можно фильтровать по различным признакам. Например фильтровать по адресу USB устройства. Из меню «Analyze -> Display filters». Создать новый фильтр «new», затем жмем кнопку «Expression». Появляется окно конструктора фильтров, выбираем секцию «USB» и необходимый атрибут, и в конце «Apply». На рисунке 23 показаны снимки экрана. Программа анализатора дает наглядное представление о процессе энумерации. Важно на начальных этапах изучения шины USB, брать простые устройства. В качестве простейшего устройства для изучения шины, можно взять загрузчик DFU микроконтроллера AT90USB162. Об этом загрузчике сказано ниже.

USBpcap что это за программа

USBpcap что это за программа

Это программы, позволяющие прослушать и декодировать данные, передаваемые по шине USB на интересующее устройство.

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

USBlyzer. Стоит около $200 [1].

USBTrace. Стоит около $195.00 [2].

SnoopyPro-0.22 — бесплатный и весьма толковый снифер [3]. Давно не поддерживается, документация практически отсутствует, но вполне себе работает.

[Как пользоваться Snoopy Pro]

Краткая справка HOWTO, как установить и запустить прослушивание пакетов для произвольного устройства USB.

1. Скачайте архив программы [3]. В архиве один-единственный исполняемый файл SnoopyPro.exe, который не требует установки (очень люблю такие программы!). Распакуйте его в произвольное место (папку) на диске, например в папку c:Program FilesSnoopyPro.

Читать еще:  Где программа хранит свои данные после запуска

2. Запустите файл SnoopyPro.exe. Появится окно USB Devices со списком установленных в Windows устройств. Выберите в меню File -> Unpack Drivers, затем выберите File -> Install Service.

3. Выберите в списке интересующее вас устройство (оно должно быть подключено к компьютеру). Устройство проще найти, зная VID и PID устройства. В столбце VID/PID списка текст будет как раз содержать эти VID и PID. К примеру, Ваше устройство имеет VID 0x0B9B и PID 0x4012, тогда строка в списке, соответствующая искомому устройству, будет иметь вид «USBVid_0b9b&Pid_4012. «. Щелкните на эту строку правой кнопкой, и выберите Install and Restart.

4. Во втором окне программы SnoopyPro запустится окно лога. Окно лога можно также запустить через меню File -> New. В лог будут накапливаться прослушанные пакеты, и число пакетов в левом верхнем углу пакета будет постоянно увеличиваться.

5. Остановите сбор лога, и тогда Вы сможете его просмотреть. Для остановки сбора лога нажмите кнопку с черным квадратиком.

Собранный лог можно сохранить в файл (File -> Save As. ) или экспортировать в XML (File -> Export. ).

[Free USB Analyzer]

Программа также называется Device Monitoring Studio (т. е. у неё бывают опции для мониторинга не только USB, но и последовательных портов, сети). Опция для мониторинга сети называется USB Monitor.

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

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

USBpcap что это за программа

Привет, друзья! Приятно видеть, что вы нас читаете и комментируете! Это значит, что пишем не зря. Сегодня я проводил весьма интересные эксперименты и хотелось бы поделиться некоторыми результатами.

Нас интересуют данные, передаваемые по шине USB. Можно ли как-то “прослушивать” этот трафик? Оказывается, можно.

Качаем программу USBPcap, устанавливаем:

Теперь запускаем файл USBPcapCMD.exe с правами администратора:

Запуск USB сниффера

Мониторить мы будем работу с флешкой, которую я заботливо вставил в порт 3 первого корневого хаба. В программе он определился под номером 2. Вводим цифру 2. Затем вводим результирующий файл (1.pcap), в него будет записываться все, что происходит на этой шине.

Немножко модифицируем содержимое текстового файла на флешке:

Запишем наглядную последовательность в файл

После этого завершаем консольное приложение сниффера нажатием клавиш Ctrl+C и открываем файл 1.pcap (появился в каталоге программы) через WireShark:

Команды обмена данными с USB устройством

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

Периодический опрос USB устройства

Итак, нетрудно заметить, что периодически (примерно раз в секунду) происходит опрос USB устройства:

Мы это видим как Test Unit Ready LUN . Моментально приходит отклик. Таким образом система узнает, что к хабу подключено устройство.

Листаем дальше. А вот и команда Write(10) . Посмотрите, я выделил там красным маркером – есть параметр LBA. Насколько я понимаю, это абсолютный адрес блока. Ниже идёт пакет непосредственно с данными для записи. Приглядимся. Да это же 0-ой сектор! Со всеми вытекающими. Файловой системой (FAT) и окончанием 0x55AA

Команда на запись USB устройства

Ладно. Идём дальше. Следующая команда на запись уже поинтереснее. Я выделил маркером LBA адрес: 0x000001F0 . Надо сказать, что тут у меня было некоторое замешательство. 0x000001F0 адрес – это как раз окончание загрузочного сектора. Зачем что-то писать сразу после него? Тем более, что не совсем соответствуют данные (переданные в следующем пакете) тем, что находятся за 0-ым сектором. Посмотрите, я там выделил синими стрелками. Последовательность 0xE5 , 0x78 , 0x00 , 0x74 ,…. и так далее. И кстати, вот я подумал, а что если адреса LBA – это не совсем то, что указано?

Запись корневого каталога FAT

Мои ожидания оправдались! Путём несложных арифметических преобразований получаем:

0x000001F0 *200 = 0x0003E000

Открываем флешку в WinHEX и идём по адресу. Видим корневой каталог! Чтож, всё логично!

Корневой каталог FAT

Здесь у меня остался некоторый мусор от переименованного файла “Новый текстовый документ.txt“, смещения с 0x0003E000 по 0x0003E07F . Игнорируем. Представим, что 0x0003E080 адрес – это на самом деле 0x0003E000 ! На практике так оно и есть.

Очищеный корневой каталог

Запись данных в файл на флешке

Следующая команда на запись – в блок 0x00000210 . Видим, что записывается последовательность 0x31 , 0x31 , 0x31 , 0x32 , 0x32 ,… Ага!

Умножаем блок на 200:

0x00000210 * 200 = 0x00042000 , переходим на этот адрес:

Содержимое файла на флешке

Ну точно! Это как раз кластер, которые занимает файл 1.txt, и с этого смещения начинается его содержимое 111222333444. Именно ASCII коды этих символов и выглядят как 0x31, 0x31, 0x31, 0x32,…. Всё сошлось!

Смотрим следующую команду на запись:

Запись в таблицу FAT

Интересно. Конечно, у меня есть догадка, но лучше бы её проверить. Видим LBA 0x00000004 .

Умножаем на 200, получаем адрес 0x00000800

Поясняю, F8 – идентификатор носителя (жесткий диск). Далее идёт два байта заполнителя FFFF. А дальше – FFFF – это запись нашего файла. Это означает, что в таблице размещения файлов наш файл занимает один единственный кластер и это первая запись FAT. Посмотрите ссылку, чтобы разобраться.

Следующее смещение на предыдущем скрине – 0x0000000FA . Разбирать не будем, просто скажу, что это вторая копия FAT-таблицы (резервная).

Вот, в общем-то и всё. Надо сказать, я до этого не совсем понимал, как происходит запись на носители типа USB. Теперь это становится понятным. Существуют методические материалы по программированию USB устройств и драйверов, у меня же есть одна замечательная идейка, которую я хочу воплотить в жизнь. Для этого нужно написать небольшую программку, наподобие этого сниффера.

USB Analyzer
Мониторинг USB портов и
анализ активности USB-устройств

USB Analyzer — это простая в использовании программа для мониторинга данных USB-устройств для ОС Windows. Она предлагает простой, но всеобъемлющий режим отображения мониторинга и анализа активности USB-устройств.

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

Реверс протокола USB устройства

Возникла такая задача.

Есть USB приставка типа осциллографа, и программа под winXP, от его разработчика, которая запускает измерения, устанавливает частоту дискретизации, получает и отображает данные.

Ни исходников программы, ни описания протокола, по которому она с устройством общается, нет.

Возникла необходимость разработки своего приложения род Linux для работы с осциллографом, автоматической обработки данных и передачи результата в OpenScada.

Нужно выяснить, как программа общается с устройством. Думаю использовать сниффер USB. Кто-нибудь имеет такой опыт? Какую лучше программу-сниффер использовать под XP? Как удобнее тестировать полученный таким образом результат под Linux?

USBPcap – USB Packet Capture For Windows

USBPcap is an open-source USB Packet Capture tool for Windows that can be used together with Wireshark in order to analyse USB traffic without using a Virtual Machine.

Currently, the live capture can be done on “standard input” capture basis: you write a magic command in cmd.exe and you get the Wireshark to capture raw USB traffic on Windows.

USBPcapDriver has three “hats”:

  • Root Hub (USBPCAP_MAGIC_ROOTHUB)
  • Control (USBPCAP_MAGIC_CONTROL)
  • Device (USBPCAP_MAGIC_DEVICE)

What you won’t see using USBPcap

As USBPcap captures URBs passed between functional device object (FDO) and physical device object (PDO) there are some USB communications elements that you will notice only in hardware USB sniffer.

  • Bus states (Suspended, Power ON, Power OFF, Reset, High Speed Detection Handshake)
  • Packet ID (PID)
  • Split transactions (CSPLIT, SSPLIT)
  • Duration of bus state and time used to transfer packet over the wire
  • Transfer speed (Low Speed, Full Speed, High Speed)

Moreover, you won’t see complete USB enumeration. You will only see the USB control transfer send to device after the device has been assigned its address.

Перехват данных на шине USB: Практика

Привет, друзья! Приятно видеть, что вы нас читаете и комментируете! Это значит, что пишем не зря. Сегодня я проводил весьма интересные эксперименты и хотелось бы поделиться некоторыми результатами.

Читать еще:  Openal что это за программа

Нас интересуют данные, передаваемые по шине USB. Можно ли как-то “прослушивать” этот трафик? Оказывается, можно.

Качаем программу USBPcap, устанавливаем:

Теперь запускаем файл USBPcapCMD.exe с правами администратора:

Запуск USB сниффера

Мониторить мы будем работу с флешкой, которую я заботливо вставил в порт 3 первого корневого хаба. В программе он определился под номером 2. Вводим цифру 2. Затем вводим результирующий файл (1.pcap), в него будет записываться все, что происходит на этой шине.

Немножко модифицируем содержимое текстового файла на флешке:

Запишем наглядную последовательность в файл

После этого завершаем консольное приложение сниффера нажатием клавиш Ctrl+C и открываем файл 1.pcap (появился в каталоге программы) через WireShark:

Команды обмена данными с USB устройством

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

Итак, нетрудно заметить, что периодически (примерно раз в секунду) происходит опрос USB устройства:

Мы это видим как Test Unit Ready LUN . Моментально приходит отклик. Таким образом система узнает, что к хабу подключено устройство.

Листаем дальше. А вот и команда Write(10) . Посмотрите, я выделил там красным маркером – есть параметр LBA. Насколько я понимаю, это абсолютный адрес блока. Ниже идёт пакет непосредственно с данными для записи. Приглядимся. Да это же 0-ой сектор! Со всеми вытекающими. Файловой системой (FAT) и окончанием 0x55AA

Команда на запись USB устройства

Ладно. Идём дальше. Следующая команда на запись уже поинтереснее. Я выделил маркером LBA адрес: 0x000001F0 . Надо сказать, что тут у меня было некоторое замешательство. 0x000001F0 адрес – это как раз окончание загрузочного сектора. Зачем что-то писать сразу после него? Тем более, что не совсем соответствуют данные (переданные в следующем пакете) тем, что находятся за 0-ым сектором. Посмотрите, я там выделил синими стрелками. Последовательность 0xE5 , 0x78 , 0x00 , 0x74 ,…. и так далее. И кстати, вот я подумал, а что если адреса LBA – это не совсем то, что указано?

Запись корневого каталога FAT

Мои ожидания оправдались! Путём несложных арифметических преобразований получаем:

0x000001F0 * 200 = 0x0003E000

Открываем флешку в WinHEX и идём по адресу. Видим корневой каталог! Чтож, всё логично!

Корневой каталог FAT

Здесь у меня остался некоторый мусор от переименованного файла “Новый текстовый документ.txt“, смещения с 0x0003E000 по 0x0003E07F . Игнорируем. Представим, что 0x0003E080 адрес – это на самом деле 0x0003E000 ! На практике так оно и есть.

Очищеный корневой каталог

Запись данных в файл на флешке

Следующая команда на запись – в блок 0x00000210 . Видим, что записывается последовательность 0x31 , 0x31 , 0x31 , 0x32 , 0x32 ,… Ага!

Умножаем блок на 200:

0x00000210 * 200 = 0x00042000 , переходим на этот адрес:

Содержимое файла на флешке

Ну точно! Это как раз кластер, которые занимает файл 1.txt, и с этого смещения начинается его содержимое 111222333444. Именно ASCII коды этих символов и выглядят как 0x31, 0x31, 0x31, 0x32,…. Всё сошлось!

Смотрим следующую команду на запись:

Запись в таблицу FAT

Интересно. Конечно, у меня есть догадка, но лучше бы её проверить. Видим LBA 0x00000004 .

Умножаем на 200, получаем адрес 0x00000800

Содержимое FAT

Поясняю, F8 – идентификатор носителя (жесткий диск). Далее идёт два байта заполнителя FFFF. А дальше – FFFF – это запись нашего файла. Это означает, что в таблице размещения файлов наш файл занимает один единственный кластер и это первая запись FAT. Посмотрите ссылку, чтобы разобраться.

Следующее смещение на предыдущем скрине – 0x0000000FA . Разбирать не будем, просто скажу, что это вторая копия FAT-таблицы (резервная).

Вот, в общем-то и всё. Надо сказать, я до этого не совсем понимал, как происходит запись на носители типа USB. Теперь это становится понятным. Существуют методические материалы по программированию USB устройств и драйверов, у меня же есть одна замечательная идейка, которую я хочу воплотить в жизнь. Для этого нужно написать небольшую программку, наподобие этого сниффера.

Друзья! Вступайте в нашу группу Вконтакте, чтобы не пропустить новые статьи! Хотите сказать спасибо? Ставьте Like, делайте репост! Это лучшая награда для меня от вас! Так я узнаю о том, что статьи подобного рода вам интересны и пишу чаще и с большим энтузиазмом!

Также, подписывайтесь на наш канал в YouTube! Видео выкладываются весьма регулярно и будет здорово увидеть что-то одним из первых!

CaptureSetup / USB

USB capture setup

This page is about capturing raw USB traffic, e.g. the packets a USB mouse will generate on the Universal Serial Bus.

Table of contents

USB attached network interfaces

A special case are network interfaces connected to a host computer through an USB cable. The operating system «converts» the raw USB packets into the network traffic (e.g. Ethernet packets) and provides a network interface that looks like an ordinary network interface. So you can capture from:

  • the USB device for raw USB traffic (if supported)
  • the network device for «normal» network packets

The USB bus will add additional overhead, so the raw USB traffic will have higher volume than the network traffic, even if the only active USB devices on the system are network adapters. (If there are other active USB devices, the raw USB traffic will include traffic to and from those devices, so it will obviously have higher volume than Ethernet traffic.)

Capturing USB traffic on Linux is possible since Wireshark 1.2.0, libpcap 1.0.0, and Linux 2.6.11, using the Linux usbmon interface.

First, check if you belong to the wireshark group with:

To add yourself to the wireshark group, run the below command, then logout and login.

sudo adduser $USER wireshark

Then ensure that non-superusers are allowed to capture packets in wireshark. Select in the below prompt:

sudo dpkg-reconfigure wireshark-common

The next two commands may need to be re-run after every reboot:

To dump USB traffic on Linux, you need the usbmon kernel module. If it is not loaded yet, run this command as root:

To give regular users privileges, make the usbmonX device(s) readable:

sudo setfacl -m u:$USER:r /dev/usbmon*

On some Linux distributions (Arch Linux, Debian, Ubuntu, possibly others), the above command may not be necessary if you already belong to the wireshark group. See CaptureSetup/CapturePrivileges#Most_UNIXes.

With Linux kernels prior to 2.6.23, you will also need to run this command as root:

mount -t debugfs none /sys/kernel/debug

and, with those kernels, the usbmon mechanism’s protocol limits the total amount of data captured for each raw USB block to about 30 bytes. With a 2.6.23 or later kernel, and libpcap 1.1.0 and later, that size limitation is removed. Use uname -r to check your kernel version.

In libpcap 1.1.0 and later, the devices on which you can capture are named usbmonX, where X is the USB bus number. On Linux 2.6.22 and later, the special «usbmon0» interface receives a combined stream of events from all USB buses. In libpcap 1.0.x, the devices were named usbX.

Simple MITM hardware with Linux

If the USB host is a black-box device such as a game console and you cannot capture USB traffic on the host’s operating system, here are two DIY-projects that help you build a simple MITM device to intercept and relay USB messages on the USB cable.

is designed to intercept USB HID traffic. Originally made for the GIMX project (which lets you connect PC game controllers to the PS4 by converting the HID protocol messages). You will need a Linux computer to capture the HID messages and an Arduino-based USB dongle. Parts are cheap. If you don’t like soldering, you can buy ready-made «GIMX USB adapters» from the developer and from enthusiasts on eBay and elsewhere.

USBProxy

  • intercepts USB traffic with a standalone Beaglebone Black, which is reconfigured to act as a USB gadget emulating the device connected to the 2nd USB port. Unlike SerialUSB, this solution works with higher-speed non-HID USB traffic as well (within the hardware limitations of the Beaglebone device).
Читать еще:  Программа температура процессора Windows 7 на русском

Capturing USB traffic on macOS is possible since Wireshark 2.4.0, libpcap 1.9.0, and macOS High Sierra, using the XHC20 interface.

In order to capture on that interface, you will first have to run the command

as root, for example by running

sudo ifconfig XHC20 up

You can capture raw USB traffic on Windows with USBPcap. The Tools page lists some other options for Windows USB capture.

A word of warning about USBPcap

There have been problems with using USBPcap in the past, and while these problems should be resolved now, you may wish to familiarize yourself with these earlier problems, in the event you are still affected by it.

Wireshark Bug 11766 — USBPcap prevents mouse and keyboard from working

USBPcap Issue #3 — Windows 7 — USB bus not recognized after restart after USBPcap installation

Microsoft Security Advisory 3033929 — Availability of SHA-2 Code Signing Support for Windows 7 and Windows Server 2008 R2

You can also capture and debug USB traffic on a virtual Windows machine under VirtualBox. In some ways this is more convenient than working with a separate Windows box.

In this example, an embedded Linux device running g_ether (RNDIS ethernet gadget) connects to Windows. e.g. an NSLU2 with a USB slave modification http://www.nslu2-linux.org/wiki/HowTo/AddDeviceSideUSBPort but it should work for almost any USB device.

With this method, Linux recognises the USB device (i.e. >lsusb will still show them), but VirtualBox hooks it into Windows but Wireshark on linux still gets to snoop on all the packets.

1. Install a VirtualBox Windows guest on your Linux host. Start up the virtual Windows session.

2. Plug-in the embedded slave device via a USB cable, which itself should be either a device Windows already knows about (or in this case it was running a valid g_ether gadget stack and needed a .inf file)

3. Run >lsusb and take a note of which bus the device connects.

  • e.g
  • «Bus 003 Device 003: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget»

4. On linux side,run >ifconfig usb0 down — this prevents both the linux system and the windows system from fighting over the device

5. On the Windows virtual machine, on VirtualBox menus click the checkbox

[Devices]->Usb devices>[x]Your device

  • to let windows see the USB device.
  • 6. Now Windows should recognise the device and proceed with the «plug-and-pray» session for driver initialisation.

    7. In this example, I had to set up the networking options for IP address, Gateway etc on Windows to match the IP network on the gadget but for other USB device types there will be no extra setup. In any case this is just normal Windows behavior.

    8. On Linux, startup Wireshark and using the Bus number given earlier from >lsusb command to sniff for packets.

    Hints for developing something like a Windows native «USBPcap»: a kernel mode filter device driver has to be written. An older Driver Development Kit (DDK) is available which at least can compile kernel mode binaries. The most important functions to install the filter driver are CreateService() and SetupDiSetDeviceRegistryProperty() function with SPDRP_LOWERFILTERS parameter.

    Discussion

    Why was the note about inaccurate time stamps removed. — UlfLamping

    The timestamps should be ok now since libpcap works around the issue by explicitly calling gettimeofday()- ronnie

    Well, the inaccuracies I had in mind was about the «delta» involved between the data is received from the USB device and actually timestamped from the kernel. This delta will be substantially lower for e.g. PCI based nic’s than for USB ones — and should be mentioned. Or am I just wrong on this topic and this can be ignored — which should be mentioned then too? — UlfLamping

    There’s «capturing on USB-attached networking interfaces» and there’s «capturing USB traffic»; this page is for the latter, but it sounds as if the time stamp delta is an issue for the former. — Guy Harris

    USBpcap что это за программа

    Привет, друзья! Приятно видеть, что вы нас читаете и комментируете! Это значит, что пишем не зря. Сегодня я проводил весьма интересные эксперименты и хотелось бы поделиться некоторыми результатами.

    Нас интересуют данные, передаваемые по шине USB. Можно ли как-то “прослушивать” этот трафик? Оказывается, можно.

    Качаем программу USBPcap, устанавливаем:

    Теперь запускаем файл USBPcapCMD.exe с правами администратора:

    Запуск USB сниффера

    Мониторить мы будем работу с флешкой, которую я заботливо вставил в порт 3 первого корневого хаба. В программе он определился под номером 2. Вводим цифру 2. Затем вводим результирующий файл (1.pcap), в него будет записываться все, что происходит на этой шине.

    Немножко модифицируем содержимое текстового файла на флешке:

    Запишем наглядную последовательность в файл

    После этого завершаем консольное приложение сниффера нажатием клавиш Ctrl+C и открываем файл 1.pcap (появился в каталоге программы) через WireShark:

    Команды обмена данными с USB устройством

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

    Периодический опрос USB устройства

    Итак, нетрудно заметить, что периодически (примерно раз в секунду) происходит опрос USB устройства:

    Мы это видим как Test Unit Ready LUN . Моментально приходит отклик. Таким образом система узнает, что к хабу подключено устройство.

    Листаем дальше. А вот и команда Write(10) . Посмотрите, я выделил там красным маркером – есть параметр LBA. Насколько я понимаю, это абсолютный адрес блока. Ниже идёт пакет непосредственно с данными для записи. Приглядимся. Да это же 0-ой сектор! Со всеми вытекающими. Файловой системой (FAT) и окончанием 0x55AA

    Команда на запись USB устройства

    Ладно. Идём дальше. Следующая команда на запись уже поинтереснее. Я выделил маркером LBA адрес: 0x000001F0 . Надо сказать, что тут у меня было некоторое замешательство. 0x000001F0 адрес – это как раз окончание загрузочного сектора. Зачем что-то писать сразу после него? Тем более, что не совсем соответствуют данные (переданные в следующем пакете) тем, что находятся за 0-ым сектором. Посмотрите, я там выделил синими стрелками. Последовательность 0xE5 , 0x78 , 0x00 , 0x74 ,…. и так далее. И кстати, вот я подумал, а что если адреса LBA – это не совсем то, что указано?

    Запись корневого каталога FAT

    Мои ожидания оправдались! Путём несложных арифметических преобразований получаем:

    0x000001F0 *200 = 0x0003E000

    Открываем флешку в WinHEX и идём по адресу. Видим корневой каталог! Чтож, всё логично!

    Корневой каталог FAT

    Здесь у меня остался некоторый мусор от переименованного файла “Новый текстовый документ.txt“, смещения с 0x0003E000 по 0x0003E07F . Игнорируем. Представим, что 0x0003E080 адрес – это на самом деле 0x0003E000 ! На практике так оно и есть.

    Очищеный корневой каталог

    Запись данных в файл на флешке

    Следующая команда на запись – в блок 0x00000210 . Видим, что записывается последовательность 0x31 , 0x31 , 0x31 , 0x32 , 0x32 ,… Ага!

    Умножаем блок на 200:

    0x00000210 * 200 = 0x00042000 , переходим на этот адрес:

    Содержимое файла на флешке

    Ну точно! Это как раз кластер, которые занимает файл 1.txt, и с этого смещения начинается его содержимое 111222333444. Именно ASCII коды этих символов и выглядят как 0x31, 0x31, 0x31, 0x32,…. Всё сошлось!

    Смотрим следующую команду на запись:

    Запись в таблицу FAT

    Интересно. Конечно, у меня есть догадка, но лучше бы её проверить. Видим LBA 0x00000004 .

    Умножаем на 200, получаем адрес 0x00000800

    Поясняю, F8 – идентификатор носителя (жесткий диск). Далее идёт два байта заполнителя FFFF. А дальше – FFFF – это запись нашего файла. Это означает, что в таблице размещения файлов наш файл занимает один единственный кластер и это первая запись FAT. Посмотрите ссылку, чтобы разобраться.

    Следующее смещение на предыдущем скрине – 0x0000000FA . Разбирать не будем, просто скажу, что это вторая копия FAT-таблицы (резервная).

    Вот, в общем-то и всё. Надо сказать, я до этого не совсем понимал, как происходит запись на носители типа USB. Теперь это становится понятным. Существуют методические материалы по программированию USB устройств и драйверов, у меня же есть одна замечательная идейка, которую я хочу воплотить в жизнь. Для этого нужно написать небольшую программку, наподобие этого сниффера.

    Ссылка на основную публикацию
    Adblock
    detector