स्मार्ट होम डिवाइस हैकिंग (2024)

 (jmswrnr.com)
1 पॉइंट द्वारा GN⁺ 2025-04-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ESP32-आधारित स्मार्ट होम डिवाइस को reverse engineering करके Home Assistant के साथ integrate किया गया
  • मोबाइल ऐप का विश्लेषण करके cloud server के साथ इसके connection की पुष्टि की गई
  • network traffic intercept करके डिवाइस control करने की कोशिश की गई
  • ESP32 flash को dump और analyze करके firmware modification की कोशिश की गई
  • packet structure का विश्लेषण करके encryption और checksum को समझा गया

परिचय

  • हाल में Home Assistant से सभी डिवाइस जोड़ने की कोशिश की जा रही है
  • एक खास air purifier केवल अपने ऐप से ही connect होता है, इसलिए उसे hack करके integrate करने की कोशिश की गई
  • internet connection और cloud account पर निर्भर प्रोडक्ट्स की समस्याओं की ओर इशारा किया गया

योजना

  • यह पुष्टि की गई कि मोबाइल ऐप cloud server से connect होता है और remote control संभव बनाता है
  • network traffic intercept करके डिवाइस को control करने के तरीके तलाशे गए

मोबाइल ऐप विश्लेषण

  • Android ऐप का विश्लेषण करके पुष्टि की गई कि यह React Native में विकसित किया गया है
  • यह पाया गया कि यह WebSocket के जरिए cloud server से connect होता है

नेटवर्क जांच

  • Pi-hole का उपयोग करके DNS queries की जांच की गई और Wireshark से traffic analyze किया गया
  • UDP packets के जरिए डिवाइस और server के बीच communication की पुष्टि की गई

पैकेट विश्लेषण

  • UDP proxy का उपयोग करके डिवाइस और cloud server के बीच traffic relay किया गया
  • Wireshark से packet structure का विश्लेषण किया गया और encryption की संभावना की पुष्टि की गई

भौतिक डिसअसेंबली

  • ESP32-आधारित डिवाइस को खोलकर flash chip से firmware dump किया गया
  • esptool का उपयोग करके serial connection के जरिए डेटा पढ़ा गया

फ्लैश विश्लेषण

  • esp32knife का उपयोग करके flash डेटा analyze किया गया और partition table की पुष्टि की गई
  • FAT file system में महत्वपूर्ण files पाई गईं

प्रारंभिक static analysis

  • Ghidra का उपयोग करके firmware strings का विश्लेषण किया गया और encryption library के उपयोग की पुष्टि की गई
  • mbedtls library का उपयोग करके ECDH और HKDF algorithm implement किए गए

फर्मवेयर संशोधन

  • Ghidra के जरिए CapSense feature को disable किया गया और firmware modify करके डिवाइस को boot कराया गया
  • checksum समस्या को हल करके modified firmware को सफलतापूर्वक flash किया गया

पैकेट हेडर

  • packet header की संरचना का विश्लेषण करके serial number और message identifier की पुष्टि की गई
  • client request और server response के pattern को समझा गया

पैकेट checksum

  • CRC checksum की पुष्टि करके packet data की integrity verify की गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-04-16
Hacker News राय

  • दीर्घकालिक समाधान यह है कि ऐसे घरेलू उत्पाद न खरीदे जाएँ जो local control को नज़रअंदाज़ करते हों

    • अगर WiFi password अनिवार्य हो, तो मैं उत्पाद वापस कर दूँगा
    • अगर आप security और privacy की क़ीमत पर समझौता करना चाहते हैं, तो यह व्यक्तिगत पसंद है, लेकिन functionality खोए बिना मना करने का विकल्प दिया जाना चाहिए
    • मैं ऐसा doorbell camera नहीं खरीदूँगा जो RTSP को support न करता हो

  • air purifier का indoor air quality गिरने पर अपना operation बढ़ाना किसी IoT device, app, wireless communication, hub की माँग नहीं करता

    • air purifier पर air quality sensor और एक छोटा LCD लगाकर settings समायोजित करना काफ़ी है
    • hallway light का अपने-आप चालू होना cloud, HomeAssist, WiFi, Zigbee, app, battery replacement के बिना काम करता है
    • पिछले 10 सालों में network down होने पर भी यह बिना समस्या के काम करता रहा है

  • ESP32-आधारित IoT device विक्रेताओं के लिए:

    • smart home system के साथ integrate करने के लिए smart device को upgrade करना दूसरे instances या cloud services को प्रभावित नहीं करता
    • संवेदनशील product data को obfuscate या delete कर दिया जाता है

  • ESP32-आधारित IoT device मालिकों के लिए:

    • smart home products से cloud हटाने और debugging के लिए open source project बनाते हुए तकनीकी पक्षों के बारे में बहुत कुछ सीखा
    • इस पोस्ट को लिखने में बहुत मेहनत की, और format पर feedback मिले तो अच्छा लगेगा

  • यह जानने की जिज्ञासा है कि device के board पर कौन-से pins जुड़े हैं, और क्या इसे ESPHome के साथ पूरी तरह flash करके custom yaml configuration लिखा जा सकता है

  • जब भी मैं IoT device design team में रहा, security-केंद्रित engineer boot protection संभालता था

    • यह हैरानी की बात है कि firmware dump करके दोबारा flash करने के ख़िलाफ़ कोई प्रतिरोध नहीं था
    • समझ नहीं आता कि flash encryption क्यों नहीं किया जाता

  • लेख पर feedback:

    • device key के उपयोग पर note में यह सबसे स्पष्ट है कि keys device-specific हों
    • device-specific key management की complexity और risk पर feedback साझा करना चाहता हूँ
    • device encryption factory में बहुत समस्याएँ पैदा कर सकता है, और अगर product इसे वहन कर सकता है, तो इसे नज़रअंदाज़ करना बेहतर है

  • यह जानने की जिज्ञासा है कि standardized solution का उपयोग क्यों नहीं किया गया

    • अपना solution बनाने की तुलना में यह ज़्यादा cost-effective लगता है

  • ESP32 IoT devices में firmware encryption का उपयोग कम ही देखा है

    • अगर firmware पढ़ा नहीं जा सकता, तो certificates बनाना मुश्किल होता
    • लेकिन साथ ही यह प्रभावशाली भी है

  • service engineers द्वारा DTLS जैसे standard protocol को implement न करने के फ़ैसले पर राय

    • यह स्पष्ट नहीं है कि हर device के पास unique private key है या नहीं
    • अगर सभी devices एक ही firmware private key साझा करते हैं, तो एक device को reverse engineer करके दूसरे devices पर MITM attack किया जा सकता है

  • smart devices इस्तेमाल करने वालों को DD-WRT, OpenWrt, Tomato, Asuswrt-Merlin का उपयोग करके devices को personal network से अलग VLAN में isolate करना चाहिए

  • खरीदे गए product का इस्तेमाल करने के लिए hacking की ज़रूरत नहीं होनी चाहिए

    • "rent-seeking" economy को regulate किया जाना चाहिए या उस पर प्रतिबंध लगना चाहिए