Sapito

लेखक: Sebastian Garcia ([email protected], @eldracote), Veronica Valeros ([email protected], @verovaleros)

Sapito के बारे में

Sapito एक मल्टीकास्ट DNS (mDNS) स्निफर और इंटरप्रेटर है जो Python में लिखा गया है। Sapito किसी pcap या इंटरफ़ेस से पैकेट सूँघता (sniff) है और निष्कर्षों की व्याख्या करता है। इसका मतलब है कि Sapito mDNS प्रश्नों और उत्तरों को समझने में सक्षम है, जिससे संदेशों का अर्थ निकलता है। यह कुछ उपकरणों की पहचान भी कर सकता है, जैसे MacOS कंप्यूटर और कई प्रकार के iPads। रंग-कोडित आउटपुट महत्वपूर्ण जानकारी को उजागर करने में मदद करता है।

यदि आपको कोई बग मिलता है, तो कृपया इसे टूल के आउटपुट के साथ [email protected] पर रिपोर्ट करें। यदि आपके पास अपराधी पैकेटों वाली pcap है, तो बग रिपोर्ट के साथ उसे भेजना अत्यंत उपयोगी होगा।

डॉकर इमेज

Sapito की एक सार्वजनिक डॉकर इमेज है जिसमें 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 रिमोट को कार्य करने योग्य बनाती है - यानी वह ऐप या कंट्रोल सेंटर की अंतर्निहित सुविधा जो iPhone और iPad से Apple TV डिवाइसों को दूर से नियंत्रित करने के लिए उपयोग होती है। यह सेवा नेटवर्क पर Bonjour के माध्यम से विज्ञापित की जाती है ताकि iOS डिवाइस AppleTV को खोज सकें।

._companion-link._tcp.local

यह सेवा स्पष्टतः Apple द्वारा प्रलेखित (documented) नहीं है, लेकिन AirPlay 2 प्रणाली को कार्य करने में शामिल प्रतीत होती है।

._raop._tcp.local

इस नेटवर्क सेवा को रिमोट ऑडियो आउटपुट प्रोटोकॉल (Remote Audio Output Protocol) कहा जाता है। यह मूल रूप से कहता है कि AppleTV एक AirPlay ऑडियो रिसीवर के रूप में कार्य करता है। यह Bonjour विज्ञापन iOS डिवाइसों को Apple TV को एक 'स्पीकर' के रूप में खोजने की अनुमति देता है जिसमें आप ऑडियो भेज सकते हैं।

._sleep-proxy._udp.local

यह एक Bonjour स्लीप प्रॉक्सी है। विचार यह है कि AppleTV उन अन्य उपकरणों के लिए विभिन्न नेटवर्क क्वेरी का उत्तर दे सकता है जो ऊर्जा उपयोग कम करने के लिए वर्तमान में लो-पावर मोड में हैं। उदाहरण के लिए, यह एक Mac हो सकता है जो साझा iTunes लाइब्रेरी या साझा प्रिंटर प्रदान करता है। AppleTV तब इन सर्वरों के नेटवर्क अनुरोधों का उत्तर दे सकता है जबकि Mac स्लीप मोड में हो - उदाहरण के लिए उपयोगकर्ता को नेटवर्क पर उपलब्ध साझा प्रिंटरों की सूची देखने की अनुमति देता है। हालाँकि, जब उपयोगकर्ता कुछ प्रिंट करना चुनता है, तो AppleTV Mac को जगाएगा और अनुरोध उसे स्थानांतरित कर देगा।

_homekit._tcp.local

यह HomeKit से संबंधित एक नेटवर्क सेवा है, जो घर में उपकरणों के साथ संचार और नियंत्रण के लिए Apple की प्रणाली है। सोचिए नियंत्रणीय प्रकाश बल्ब, पर्दे, घंटियाँ, जो भी हो। AppleTV ऐसी स्थिति में एक प्रॉक्सी के रूप में कार्य करता है ताकि उपयोगकर्ता दूर से (यानी घर पर न होते हुए भी) उपकरणों को नियंत्रित कर सके, भले ही वे उपकरण केवल ब्लूटूथ वाले हों और पहुँच की सीमा से बाहर हों। ध्यान दें कि नेटवर्क पर सामान्य HomeKit उपकरण इसके बजाय _hap._tcp के रूप में विज्ञापित होते हैं।

._touch-able._tcp.local

यह उन नेटवर्क सेवाओं में से एक और है जो Apple TV रिमोट को कार्य करने योग्य बनाती है। यह सेवा डिवाइस प्रमाणीकरण से संबंधित है। अर्थात यदि आप उदाहरण के लिए Apple TV पर एक YouTube वीडियो चलाना चाहते हैं, तो Apple TV यह मांग कर सकता है कि ऐसा करने की अनुमति दिए जाने से पहले डिवाइस प्रमाणित हो। व्यवहार में प्रमाणीकरण इस प्रकार काम करता है कि Apple TV स्क्रीन पर एक PIN-कोड प्रदर्शित करता है जिसे उपयोगकर्ता iOS डिवाइस पर दर्ज करता है। यह PIN-कोड 'touch-able' के रूप में विज्ञापित सेवा का उपयोग करके डिवाइस को प्रमाणित करने के लिए स्थानांतरित किया जाता है।

कुछ पैकेटों में प्रश्न और उत्तर एक ही पैकेट में क्यों होते हैं?

Known-Answer suppression के कारण¹:

root@kitploit:~

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.