
A mDNS sniffer and interpreter.
Autoren: Sebastian Garcia ([email protected], @eldracote), Veronica Valeros ([email protected], @verovaleros)
Sapito ist ein Multicast-DNS-Sniffer (mDNS) und -Interpretierer, geschrieben in Python. Sapito schnüffelt Pakete aus einer Pcap-Datei oder einer Schnittstelle und interpretiert die Ergebnisse. Das bedeutet, dass Sapito in der Lage ist, die mDNS-Fragen und -Antworten zu verstehen und die Nachrichten zu deuten. Es kann auch bestimmte Geräte identifizieren, wie zum Beispiel MacOS-Computer und verschiedene Arten von iPads. Die farbcodierte Ausgabe hilft, wichtige Informationen hervorzuheben.
Wenn Sie einen Fehler finden, melden Sie ihn bitte zusammen mit der Ausgabe des Tools an [email protected]. Wenn Sie die Pcap-Datei mit den betreffenden Paketen haben, wäre es äußerst nützlich, wenn Sie sie zusammen mit dem Fehlerbericht mitsenden würden.

Sapito hat ein öffentliches Docker-Image mit der neuesten Version auf DockerHub, das auf Linux-Systemen gut läuft (MacOS wird noch nicht unterstützt).
So führen Sie Sapito aus:
docker run --rm --network host --name sapito -it stratosphereips/sapito:latest python3 sapito.py -i <interface>
Dies ist eine Bonjour-Ankündigung für den Netzwerkdienst, der AirPlay von Videoinhalten ermöglicht. D.h. dies ermöglicht es iOS-Geräten, den Apple TV als "Remote-Display" zu entdecken, auf dem sie Videos anzeigen können.
Dies ist einer der Netzwerkdienste, die die Apple-TV-Fernbedienung funktionsfähig machen – d.h. die App oder das in das Kontrollzentrum integrierte Feature zur Fernsteuerung von Apple-TV-Geräten über iPhones und iPads. Dieser Dienst wird über Bonjour im Netzwerk beworben, um sicherzustellen, dass iOS-Geräte den AppleTV entdecken können.
Dieser Dienst scheint von Apple nicht dokumentiert zu sein, scheint aber daran beteiligt zu sein, das AirPlay-2-System zum Laufen zu bringen.
Dieser Netzwerkdienst heißt Remote Audio Output Protocol. Im Wesentlichen besagt er, dass der AppleTV als AirPlay-Audioempfänger fungiert. Diese Bonjour-Ankündigung ermöglicht es iOS-Geräten, den Apple TV als "Lautsprecher" zu entdecken, an den man Audio senden kann.
Dies ist ein Bonjour-Schlafproxy. Die Idee dahinter ist, dass der AppleTV auf verschiedene Netzwerkanfragen für andere Geräte antworten kann, die sich derzeit im Energiesparmodus befinden, um den Energieverbrauch zu senken. Zum Beispiel könnte es sich um einen Mac handeln, der eine gemeinsame iTunes-Mediathek oder einen gemeinsamen Drucker anbietet. Der AppleTV kann dann Netzwerkanfragen für diese Server beantworten, während der Mac im Schlafmodus ist – z.B. indem er dem Benutzer erlaubt, die im Netzwerk verfügbaren gemeinsamen Drucker aufzulisten. Wenn der Benutzer jedoch etwas drucken möchte, weckt der AppleTV den Mac auf und überträgt die Anfrage an ihn.
Dies ist ein Netzwerkdienst bezüglich HomeKit, Apples System zur Kommunikation mit und Steuerung von Geräten im Haushalt. Denken Sie an steuerbare Glühbirnen, Jalousien, Türklingeln, was auch immer. Der AppleTV fungiert in einer solchen Umgebung als Proxy, sodass der Benutzer Geräte remote steuern kann (d.h. während er nicht zu Hause ist), selbst wenn die Geräte nur Bluetooth-fähig und außerhalb der Reichweite sind. Beachten Sie, dass gewöhnliche HomeKit-Geräte im Netzwerk stattdessen als _hap._tcp werben.
Dies ist ein weiterer der Netzwerkdienste, die die Apple-TV-Fernbedienung funktionsfähig machen. Dieser Dienst betrifft die Geräteauthentifizierung. D.h. wenn Sie zum Beispiel ein Youtube-Video auf dem Apple TV abspielen möchten, kann der Apple TV verlangen, dass das Gerät authentifiziert wird, bevor dies erlaubt wird. In der Praxis funktionieren Authentifizierungen so, dass der Apple TV einen PIN-Code auf dem Fernseher anzeigt, den der Benutzer auf dem iOS-Gerät eingibt. Dieser PIN-Code wird mithilfe des als "touch-able" beworbenen Dienstes übertragen, um das Gerät zu authentifizieren.
Wegen der Known-Answer-Suppression1:
Known-Answer Suppression
Wenn ein Multicast-DNS-Abfrager eine Abfrage sendet, auf die es bereits
einige Antworten kennt, füllt es den Antwortabschnitt der DNS-Abfragenachricht
mit diesen Antworten.
Im Allgemeinen gilt dies nur für Shared Records, nicht für Unique Records,
denn wenn ein Multicast-DNS-Abfrager bereits mindestens einen Unique Record
in seinem Cache hat, sollte es keine weiteren unterschiedlichen Antworten
auf diese Frage erwarten, da die Unique Record(s), die es bereits hat,
die vollständige Antwort darstellen; es hat also keinen Grund, die
Abfrage überhaupt zu senden. Im Gegensatz dazu bedeutet das Vorhandensein
einiger Shared Records in seinem Cache nicht unbedingt, dass ein
Multicast-DNS-Abfrager keine weiteren Antworten auf diese Abfrage erhalten
wird, und in diesem Fall ist es vorteilhaft, die Known-Answer-Liste zu
verwenden, um das wiederholte Senden redundanter Antworten zu unterdrücken,
die der Abfrager bereits kennt.
'RFC 6762: Multicast DNS'. https://www.rfc-editor.org/rfc/rfc6762#section-7.1 (abgerufen am 01. Okt. 2022). ↩