3 पॉइंट द्वारा GN⁺ 2025-09-16 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • घर के अंदर कुत्ते पर नज़र रखने के लिए Tapo कैमरा खरीदा, लेकिन अनपेक्षित रूप से TP-Link डिवाइस और ऐप कैसे काम करते हैं इसका रिवर्स-इंजीनियरिंग जैसा विश्लेषण करने लगा
  • onboarding प्रक्रिया और encrypted API communication की संरचना का विश्लेषण करने के लिए MITM, APK decompile, और decryption script बनाना जैसी कई तकनीकों का उपयोग किया
  • शुरुआती admin password की खोज और session key derivation प्रक्रिया के जरिए encrypted messages को decrypt किया, और डिवाइस व cloud account के बीच अविश्वसनीय synchronization समस्या को पहचाना
  • पूरे onboarding flow का विश्लेषण करके मुख्य API call प्रक्रिया, account creation, password change, और Wi‑Fi connection जैसी चीज़ों को Bash script से automate किया
  • Tapo firmware security design की कमियाँ, कम परिष्कृत encryption implementation, और अनियमित account synchronization जैसी बातें दिखाती हैं कि सस्ते IoT डिवाइसों में कैसी समस्याएँ होती हैं

परियोजना का अवलोकन

  • लेखक ने घर के अंदर कुत्ते पर नज़र रखने के लिए कम कीमत वाला Tapo कैमरा खरीदा और इस्तेमाल किया
  • इस्तेमाल के दौरान setup की असुविधा और ऑनलाइन जानकारी की कमी के कारण, उत्पाद के काम करने के तरीके को गहराई से समझने की प्रेरणा मिली
  • frigate integration और 2way audio enable करने में अप्रत्याशित समस्याएँ आईं, जिससे cloud integration के बिना direct onboarding तरीके में रुचि बनी

Onboarding और authentication संरचना का विश्लेषण

  • Tapo कैमरा की connection प्रक्रिया का विश्लेषण करने के लिए MITM proxy और frida dynamic hooking tool का उपयोग करके ऐप और कैमरा के बीच का traffic intercept किया गया
    • नई ऐप्स अक्सर proxy ignore करना, certificate pinning जैसी bypass-रोधी सुविधाएँ रखती हैं, इसलिए dynamic tools वाला तरीका प्रभावी रहा
  • इस bypass सेटअप के बाद, कैमरा onboarding flow में default administrator account login प्रक्रिया को ठीक-ठीक पहचाना गया
  • यह भी पता चला कि default login API, cloud account password से अलग, डिवाइस-विशिष्ट default password के साथ काम करता है

Encryption संरचना और default password की खोज

  • APK decompile (JADX का उपयोग) और code analysis के जरिए, admin account का default password (TPL075526460603) हासिल किया गया
  • cloud password बदलने पर भी पहले से linked कैमरा डिवाइस उस बदलाव को नहीं पहचानते, इससे ऐप और कैमरा के बीच password synchronization की अशुद्धि की पुष्टि हुई
  • default password पता चलने के बाद, session key (lsk, ivb) derivation logic लागू करके encrypted API messages को real time में decrypt करना संभव हुआ

mitmproxy scripting और API विश्लेषण

  • PyTapo open source project को संदर्भ बनाकर, वास्तविक Tapo onboarding प्रक्रिया के API flow का बारीकी से विश्लेषण किया गया
  • tapo_decrypt_pretty.py script के माध्यम से
    • login handshake का पता लगाना
    • session key निकालना
    • encrypted API को decrypt करके अधिक पठनीय output देना, और JSON में सहेजना
  • पूरे onboarding API call रिकॉर्ड में से केवल महत्वपूर्ण चरण चुनकर एक automated workflow बनाया गया
    • Wi‑Fi सूची देखना (scanApList)
    • RTSP/ONVIF account enable करना
    • administrator password बदलना
    • Wi‑Fi connection करना

Automation और परिणाम

  • Bash script (tapo_onboard.sh) के जरिए ऊपर की पूरी onboarding प्रक्रिया को स्वचालित रूप से चलने लायक बनाया गया
    • default admin login
    • Wi‑Fi चुनना और connect करना
    • कैमरा feed से logo हटाना
    • RTSP/ONVIF उपयोग की अनुमति देना
    • administrator password reset करना
  • कैमरा firmware संरचना में निम्नलिखित विशेषताएँ और कमियाँ मिलीं
    • कुछ APIs SHA-256 hash का उपयोग करती हैं, लेकिन कुछ अब भी MD5 जैसे पुराने cryptographic तरीकों पर टिके हैं
    • public key 2 मौजूद हैं, लेकिन किस स्थिति में कौन-सी key उपयोग करनी है यह स्पष्ट नहीं है
    • ऐप और डिवाइस के बीच password synchronization बहुत अस्थिर है

निष्कर्ष और अनुभव

  • Tapo कैमरा firmware और API security संरचना तात्कालिक जुगाड़ और कम परिष्कृत design जैसी लगती है
  • इस परियोजना के जरिए कम कीमत वाले IoT डिवाइसों की security कमजोरियों और अपूर्ण onboarding सिस्टम की वास्तविकता का अप्रत्यक्ष अनुभव हुआ
  • परियोजना का अंतिम लक्ष्य, यानी कुत्ते पर नज़र रखना, सफल रहा; और कुत्ता ज़्यादातर सोफ़े या बिस्तर पर सोता हुआ ही दिखा

2 टिप्पणियां

 
helio 2025-09-17

CVE-2022-37255 को 7.5 अंक मिले हैं।

 
GN⁺ 2025-09-16
Hacker News राय
  • मेरा Frida script इस्तेमाल होते देखना काफ़ी दिलचस्प लगा, वह script यहाँ देखी जा सकती है, यह जानकर खुशी हुई कि script real-world environment में अच्छी तरह काम कर रही है, अगर आपने इसमें कुछ जोड़ा या बदला हो तो उसके बारे में सुनना चाहूँगा

    • HTTP Toolkit वाकई बहुत अच्छा tool है, Tim का शानदार काम है
    • मैंने जिन tools का इस्तेमाल किया है उनमें Http toolkit सबसे बेहतरीन लगा, मैंने mitmproxy, proxyman, charles proxy भी आज़माए हैं लेकिन httptoolkit सबसे अच्छा था और यह open source है
  • जानकारी के लिए, frigate में two-way audio इस्तेमाल करने के लिए सामान्य rtsp:// की जगह main stream पर tapo:// go2rtc configuration लगानी पड़ती है, TP-Link two-way audio सिर्फ अपने proprietary API में देता है, इससे ONVIF (open source tools के ज़रिए camera pan/tilt control) काम नहीं करता, इसलिए दोनों features साथ में इस्तेमाल करने के लिए एक काफ़ी आक्रामक workflow चाहिए: tapo:// stream reading रोकें → onvif client चलाएँ/ pan·tilt adjust करें → onvif बंद करें → tapo:// फिर से शुरू करें

  • मुझे लगता है कि IoT security कुल मिलाकर बुरी हालत में है, खासकर यह बात चिंताजनक है कि consumer routers ऐसे unauditable black boxes हैं जो पूरा network traffic संभालते हैं, ज़्यादातर लोगों को यह भी नहीं पता होता कि उनके router firmware को वर्षों से update नहीं मिला है और उसमें पहले से ज्ञात vulnerabilities मौजूद हैं, networking hardware का supply-chain trust model पूरी तरह टूटा हुआ लगता है

    • IoT security खराब है, इस बात से सहमत हूँ, मेरी तरफ़ से तो बस इतना है कि IoT devices ठीक से connect हो जाएँ, और कभी-कभी online-only restrictions तोड़ने के लिए exploit इस्तेमाल करने का मन भी होता है, लेकिन cloud-integrated IoT के लिए genuine use cases भी हैं, इसलिए मुझे लगता है कि initial setup के समय device को user से पूछना चाहिए कि वह क्या चाहता है, और फिर वही mode चुने जाने पर उसी में काम करना चाहिए, अगर cloud MFA चाहिए तो वह चुना जा सके, और अगर कोई सिर्फ programming के ज़रिए control करना चाहता है तो उसे offline ही रहने दिया जाए
    • user और destination के बीच अनगिनत routers होते हैं, और इन सब पर नज़र रखना संभव नहीं है, end devices पहले से मानकर चलते हैं कि router compromise हो चुका हो सकता है, इसलिए वे हर data को validate और encrypted form में भेजते हैं, इस लिहाज़ से जब तक routers का इस्तेमाल DDoS या cryptocurrency mining जैसे दुरुपयोग में न हो, उनकी security अपने आप में उतनी मायने नहीं रखती
    • ज़्यादातर लोग ISP द्वारा दिया और configure किया गया router ही इस्तेमाल करते हैं, इसलिए practically एक black box को दूसरे black box से जोड़ने जैसा है, Wi-Fi से connect करते समय ISP द्वारा तय SSID और password इस्तेमाल करने की बात सुनकर अक्सर लगता है कि ISP को बहुत ज़्यादा अधिकार दे दिए गए हैं
    • आम consumer products में ऐसा है, लेकिन अगर आप Ubiquiti या Mikrotik जैसे prosumer-grade hardware तक जाएँ तो तेज़ security updates और स्थिर firmware support मिल सकता है
  • यह blog post बेहद अच्छी तरह लिखी गई लगी, आजकल इस तरह की बहुत-सी लिखाइयाँ LLM-generated होती हैं और पढ़ने में अटपटी लगती हैं, लेकिन इस लेख ने technical depth और सहज पढ़ने के बीच शानदार संतुलन बनाया है, (मुझे पता है cover image AI-generated है, लेकिन वह लेख के मूल बिंदु से असंबंधित है)

    • मेरा नज़रिया यह है कि मैं uBlock Origin से default रूप से बड़े media files block कर देता हूँ ताकि resources बचें, cover images अक्सर वैसे भी block हो जाती हैं और उनका उपयोग भी लगभग नहीं होता, आजकल लोग इन्हें generate करने में बेवजह resources खर्च कर रहे हैं, यह थोड़ा अफ़सोसजनक लगता है
  • मुझे यह जानने की जिज्ञासा है कि Frida, mitmproxy जैसे tools को Android apps पर आगे भी इस्तेमाल किया जा सकेगा या नहीं, अगले साल signing requirements लागू होने के बाद क्या होगा, यह जानना चाहता हूँ

    • कुल मिलाकर यह शायद संभव रहेगा, लेकिन जिन apps में attestation ज़रूरी है वे काफ़ी अधिक कठिन हो जाएँगे, अभी भी Pixel जैसे devices जहाँ OEM unlock और rooting संभव है, developer work के लिए उपयोग किए जा सकते हैं, लेकिन ऐसे मामलों में device unlock status के कारण Google attestation fail कर देता है, app को unpack करके Frida inject करना और उसे developer account से sideload करना (iOS की तरह) भी संभव हो सकता है, लेकिन इसमें भी attestation failure और anti-tampering/anti-debugging attacks का सामना करना पड़ेगा
    • मुझे नहीं लगता कि ऐसे बदलावों का सीधा असर बहुत ज़्यादा होगा, क्योंकि reverse engineering ज़्यादातर rooted devices और emulators पर होती है, कम आम लेकिन non-rooted devices पर Frida को APK में gadget तरीके से inject करने वाले मामलों में मुश्किल बढ़ेगी, फिर भी developer mode में APK build और install करने का रास्ता शायद बना रहेगा, क्योंकि अगर इसे पूरी तरह बंद कर दिया जाए तो Android app development ही असंभव हो जाएगा, इसलिए संभवतः आम users के devices पर sideload block किया जाएगा लेकिन developer certificate जोड़ने जैसे रास्ते खुले रहेंगे, असली दिक्कत app distribution में आएगी, जबकि development/reverse engineering वाले use cases संभव रहेंगे, हालांकि device attestation का बढ़ना कहीं बड़ा ख़तरा है, rooted/unofficial devices पर ज़्यादा से ज़्यादा apps बिंदास तरीके से unmodified device checks लागू करने लग सकते हैं, अभी यह ज़्यादातर बड़े financial apps तक सीमित है, और जिन लोगों को अभी इसकी सच में चिंता करनी पड़ती है (जैसे GrapheneOS users) उनकी संख्या कम है, ऊपर से additional servers जैसी लागत भी होती है, इसलिए यह तुरंत आम नहीं होगा, लेकिन आगे बदलाव हो सकते हैं
    • सच कहूँ तो Frida का इस्तेमाल अभी भी आसान नहीं है, Frida चलाने के लिए rooting चाहिए, और rooting खुद ही कई models पर लगातार कठिन या असंभव होती जा रही है, ऊपर से बहुत मज़बूत root-detection SDKs और Play Integrity countermeasures भी मौजूद हैं
  • जानकारी के लिए, संबंधित उदाहरणों में The Tapo C200 research project और PyTapo: Tapo cameras के लिए Python library शामिल हैं

  • एक और संबंधित सामग्री के रूप में, (TP-Link firmware decryption और C210 V2 cloud camera bootloader analysis) यहाँ है

  • शायद OP के कुत्ते के बिस्तर से फ़र्श पर जाने की वजह radiator का चालू होना हो सकती है, लगता है कुछ अतिरिक्त sensor data की ज़रूरत होगी

    • या फिर बस उसे ठंड लग रही हो, ऐसा भी हो सकता है
  • लगता है अब हम उस दौर में पहुँच गए हैं जहाँ hardcoded admin password मिलना कोई बड़ी बात नहीं रही

    • मेरी समझ से यह बस hardcoded default password है, कोई permanent backdoor नहीं, लेख के मुताबिक onboarding process के दौरान user password बदल देता है, ज़्यादातर apps इसी तरह काम करते हैं
    • अगर installation के बाद सामान्य प्रक्रिया में password बदल दिया जाता है तो मुझे यह बहुत बड़ी समस्या नहीं लगती, पिछले 5 साल में मैंने अपने घर में जितने हो सके उतने IoT/smarthome devices लगाए हैं, और मेरा निष्कर्ष यह है कि लगभग हर vendor ऐसे products बेच रहा है जिनकी functionality पर सवाल उठता है, और अगर आप एक ही vendor पर न टिकें तो पूरा smarthome setup बनाना बहुत मुश्किल हो जाता है, और अभी तक अच्छे vendors भी हर individual need पूरी नहीं कर पाते, मेरे smartphone में Ecobee, Lutron, Hue, कई camera vendors, Meross, Smart Life जैसी ढेरों apps इंस्टॉल हैं, इनमें से सिर्फ Lutron और Hue ही hub/HomeKit के ज़रिए सीधे control हो जाते हैं, इसलिए उनकी apps की ज़रूरत नहीं पड़ती, Matter और Thread standardization को काफ़ी समय हो चुका है, फिर भी compatible devices की जगह सस्ते Wi-Fi-based products बाज़ार में भरे पड़े हैं, और उनमें से ज़्यादातर खराब हैं, सिर्फ app के ज़रिए manage होते हैं और आपको cloud services की ओर धकेलते हैं, चार cameras खरीदना मेरी भी गलती रही, लेकिन सच यह है कि हर vendor की अपनी strengths होती हैं, इसलिए users का अलग-अलग vendors से खरीदना कुछ हद तक मजबूरी है
    • ऐसा hardcoded admin password जिसे बदले बिना device इस्तेमाल ही न हो सके, अपने आप में बहुत बड़ा issue नहीं लगता
    • सच कहूँ तो शायद मुझे इस technology से ही बेवजह चिढ़ है, यहाँ इसे असली समस्या नहीं कहा जा सकता
    • एक नज़रिया यह भी है कि smartphones ही मूल रूप से सबसे ज़्यादा hostile devices हैं, network devices में कम से कम इतना फ़र्क है कि उनकी स्थिति को इस तरह observe या discover किया जा सकता है
  • मैं tapo cameras में कौन-कौन से models rtsp:// support करते हैं, इसका कोई संकलित reference ढूँढना चाहता हूँ, c210 ठीक-ठाक चल रहा है (हालाँकि cloud capture नहीं होता) और मैं इसे frigate के साथ इस्तेमाल कर रहा हूँ, आज मैंने c402 (outdoor model) खरीदा, लेकिन इसमें advanced settings में camera account नहीं है, यह निराशाजनक है, कीमत काफ़ी आकर्षक है लेकिन features में consistency की कमी लगती है, अगर किसी को कोई अच्छा outdoor camera पता हो जो सस्ता हो, rtsp stream support करता हो और solar panel भी लगाया जा सके, तो recommendation चाहूँगा

    • camera में rtsp:// support न भी हो, तब भी tapo:// go2rtc stream source इस्तेमाल करना संभव हो सकता है, मैंने अपनी frigate configuration संदर्भ के लिए यहाँ छोड़ी है