Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Сообщество системных администраторов Litl-Admin.ru Перехват данных на шине USB: Практика


Ссылка на материал

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

0x000001F0 *200 = 0x0003E000

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

 

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

Корневой каталог 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

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

 

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

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

Содержимое FAT

Содержимое FAT

 

F8, FF, FF, FF… Да это же… FAT! Кто забыл – прошу сюда:http://litl-admin.ru/utility/issledovanie-fajlovyx-sistem-fat-glava-2.htmlи сюда:http://litl-admin.ru/utility/issledovanie-fajlovyx-sistem-fat-glava-3.html

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

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

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



В избранное