Sapito

Авторы: Sebastian Garcia ([email protected], @eldracote), Veronica Valeros ([email protected], @verovaleros)

О Sapito

Sapito — это сниффер и интерпретатор multicast DNS (mDNS), написанный на Python. Sapito перехватывает пакеты из pcap-файла или с интерфейса и интерпретирует результаты. Это означает, что Sapito способен понимать вопросы и ответы mDNS, разбираясь в смысле сообщений. Он также может определять некоторые устройства, например компьютеры MacOS и несколько типов iPad. Вывод с цветовой кодировкой помогает выделить важную информацию.

Если вы нашли ошибку, пожалуйста, сообщите о ней вместе с выводом инструмента на [email protected]. Если у вас есть pcap-файл с проблемными пакетами, будет чрезвычайно полезно отправить его вместе с отчётом об ошибке.

Docker-образ

Sapito имеет публичный Docker-образ с последней версией на DockerHub, который хорошо работает в Linux-системах (MacOS пока не поддерживается).

Для запуска Sapito:

docker run --rm --network host --name sapito -it stratosphereips/sapito:latest  python3 sapito.py -i <interface>

Справочная информация о некоторых службах

О службах Bonjour

._airplay._tcp.local

Это объявление Bonjour для сетевой службы, которая обеспечивает AirPlay видеоконтента. То есть оно позволяет устройствам iOS обнаруживать Apple TV как «удалённый дисплей», на котором можно отображать видео.

._mediaremotetv._tcp.local

Это одна из сетевых служб, обеспечивающих работу пульта Apple TV Remote — то есть приложения или встроенной функции Пункта управления для удалённого управления Apple TV с iPhone и iPad. Эта служба объявляется в сети через Bonjour, чтобы устройства iOS могли обнаруживать Apple TV.

._companion-link._tcp.local

По-видимому, эта служба не документирована Apple, но, похоже, участвует в обеспечении работы системы AirPlay 2.

._raop._tcp.local

Эта сетевая служба называется Remote Audio Output Protocol (протокол удалённого вывода аудио). По сути, она означает, что Apple TV работает как аудиоприёмник AirPlay. Это объявление Bonjour позволяет устройствам iOS обнаруживать Apple TV как «динамик», на который можно отправлять аудио.

._sleep-proxy._udp.local

Это Bonjour Sleep Proxy (спящий прокси). Идея в том, что Apple TV может отвечать на различные сетевые запросы за другие устройства, находящиеся в режиме пониженного энергопотребления. Например, это может быть Mac, предоставляющий общую медиатеку iTunes или общий принтер. Apple TV может отвечать на сетевые запросы к таким серверам, пока Mac находится в спящем режиме — например, позволяя пользователю просматривать список общих принтеров, доступных в сети. Однако когда пользователь решает что-то напечатать, Apple TV разбудит Mac и передаст запрос ему.

_homekit._tcp.local

Это сетевая служба, относящаяся к HomeKit — системе Apple для связи с домашними устройствами и управления ими. Подумайте об управляемых лампочках, шторах, дверных звонках и т. п. В такой конфигурации Apple TV работает как прокси, позволяя пользователю управлять устройствами удалённо (то есть вне дома), даже если устройства работают только по Bluetooth и находятся вне зоны действия. Обратите внимание, что обычные устройства HomeKit в сети объявляются как _hap._tcp.

._touch-able._tcp.local

Это ещё одна сетевая служба, обеспечивающая работу пульта Apple TV Remote. Эта служба отвечает за аутентификацию устройств. Например, если вы хотите воспроизвести видео с YouTube на Apple TV, Apple TV может потребовать аутентификации устройства, прежде чем разрешить это. На практике аутентификация работает так: Apple TV показывает PIN-код на экране телевизора, а пользователь вводит его на устройстве iOS. Этот PIN-код передаётся с использованием службы, объявляемой как «touch-able», для аутентификации устройства.

Почему в некоторых пакетах есть и вопрос, и ответы в одном пакете?

Из-за подавления известных ответов¹:

Known-Answer Suppression

   When a Multicast DNS querier sends a query to which it already knows
   some answers, it populates the Answer Section of the DNS query
   message with those answers.

   Generally, this applies only to Shared records, not Unique records,
   since if a Multicast DNS querier already has at least one Unique
   record in its cache then it should not be expecting further different
   answers to this question, since the Unique record(s) it already has
   comprise the complete answer, so it has no reason to be sending the
   query at all.  In contrast, having some Shared records in its cache
   does not necessarily imply that a Multicast DNS querier will not 
   receive further answers to this query, and it is in this case that it
   is beneficial to use the Known-Answer list to suppress repeated
   sending of redundant answers that the querier already knows.