eldraco/sapitoA mDNS sniffer and interpreter.
Auteurs : Sebastian Garcia ([email protected], @eldracote), Veronica Valeros ([email protected], @verovaleros)
Sapito est un renifleur (sniffer) et interpréteur de DNS multicast (mDNS) écrit en Python. Sapito capture des paquets depuis un fichier pcap ou une interface et interprète les résultats. Cela signifie que Sapito est capable de comprendre les questions et réponses mDNS, donnant ainsi un sens aux messages. Il peut également identifier certains appareils, comme les ordinateurs MacOS et plusieurs types d'iPad. La sortie avec code couleur aide à mettre en évidence les informations importantes.
Si vous trouvez un bug, merci de le signaler avec la sortie de l'outil à [email protected]. Si vous disposez du pcap contenant les paquets en cause, il serait extrêmement utile de l'envoyer avec le rapport de bug.
Sapito dispose d'une image Docker publique avec la dernière version sur DockerHub, qui fonctionne bien sur les systèmes Linux (MacOS pas encore pris en charge).
Pour exécuter Sapito :
docker run --rm --network host --name sapito -it stratosphereips/sapito:latest python3 sapito.py -i <interface>
Il s'agit d'une annonce Bonjour pour le service réseau qui permet l'AirPlay de contenu vidéo. C'est-à-dire que cela permet aux appareils iOS de découvrir l'Apple TV comme un « écran distant » sur lequel ils peuvent afficher de la vidéo.
C'est l'un des services réseau qui fait fonctionner la télécommande Apple TV, c'est-à-dire l'application ou la fonction intégrée au Centre de contrôle permettant de contrôler à distance les appareils Apple TV depuis les iPhones et iPads. Ce service est annoncé sur le réseau via Bonjour pour garantir que les appareils iOS puissent découvrir l'AppleTV.
Ce service n'est apparemment pas documenté par Apple, mais semble impliqué dans le fonctionnement du système AirPlay 2.
Ce service réseau est appelé Remote Audio Output Protocol. Il indique essentiellement que l'AppleTV fonctionne comme un récepteur audio AirPlay. Cette annonce Bonjour permet aux appareils iOS de découvrir l'Apple TV comme une « enceinte » à laquelle vous pouvez envoyer de l'audio.
Il s'agit d'un proxy de veille Bonjour. L'idée est que l'AppleTV peut répondre à diverses requêtes réseau pour d'autres appareils actuellement en mode basse consommation afin de réduire la consommation d'énergie. Par exemple, il peut s'agir d'un Mac proposant une bibliothèque iTunes partagée ou une imprimante partagée. L'AppleTV peut alors répondre aux requêtes réseau pour ces serveurs pendant que le Mac est en mode veille, par exemple en permettant à l'utilisateur de lister les imprimantes partagées disponibles sur le réseau. Cependant, lorsque l'utilisateur choisit d'imprimer quelque chose, l'AppleTV réveille le Mac et lui transfère la requête.
Il s'agit d'un service réseau concernant HomeKit, le système d'Apple pour communiquer avec et contrôler les appareils de la maison. Pensez aux ampoules contrôlables, stores, sonnettes, etc. L'AppleTV agit comme un proxy dans ce contexte afin que l'utilisateur puisse contrôler les appareils à distance (c'est-à-dire en dehors du domicile) même si les appareils sont uniquement en Bluetooth et hors de portée. Notez que les appareils HomeKit ordinaires sur le réseau s'annoncent plutôt en tant que _hap._tcp.
C'est un autre des services réseau qui fait fonctionner la télécommande Apple TV. Ce service concerne l'authentification des appareils. Par exemple, si vous voulez lire une vidéo YouTube sur l'Apple TV, l'Apple TV peut exiger que l'appareil soit authentifié avant de le permettre. En pratique, l'authentification fonctionne par l'affichage d'un code PIN sur le téléviseur par l'Apple TV, code que l'utilisateur saisit sur l'appareil iOS. Ce code PIN est transféré à l'aide du service annoncé comme « touch-able » pour authentifier l'appareil.
En raison de la suppression des réponses connues (Known-Answer Suppression)1 :
Known-Answer Suppression (Suppression des réponses connues)
Lorsqu'un requérant DNS multicast envoie une requête pour laquelle il
connaît déjà certaines réponses, il remplit la section Réponse du
message de requête DNS avec ces réponses.
En général, cela ne s'applique qu'aux enregistrements partagés, et non
aux enregistrements uniques, car si un requérant DNS multicast possède
déjà au moins un enregistrement unique dans son cache, il ne devrait
pas s'attendre à d'autres réponses différentes à cette question,
puisque le ou les enregistrements uniques qu'il possède déjà
constituent la réponse complète ; il n'a donc aucune raison d'envoyer
la requête. En revanche, le fait d'avoir certains enregistrements
partagés dans son cache n'implique pas nécessairement qu'un requérant
DNS multicast ne recevra pas d'autres réponses à cette requête, et
c'est dans ce cas qu'il est utile d'utiliser la liste des réponses
connues pour supprimer l'envoi répété de réponses redondantes que le
requérant connaît déjà.
‘RFC 6762: Multicast DNS’. https://www.rfc-editor.org/rfc/rfc6762#section-7.1 (consulté le 01 oct. 2022). ↩