- Ein ESP32-basiertes Smart-Home-Gerät wurde per Reverse Engineering analysiert und in Home Assistant integriert
- Die mobile App wurde untersucht, um die Verbindung zum Cloud-Server zu bestätigen
- Netzwerkverkehr wurde abgefangen, um die Gerätesteuerung zu erproben
- Der ESP32-Flash wurde gedumpt und analysiert, um Firmware-Modifikationen zu versuchen
- Die Paketstruktur wurde analysiert, um Verschlüsselung und Prüfsumme zu verstehen
Einführung
- In letzter Zeit wird versucht, alle Geräte mit Home Assistant zu verbinden
- Ein bestimmter Luftreiniger lässt sich nur über seine eigene App verbinden, daher soll er gehackt und integriert werden
- Es wird auf die Probleme von Produkten hingewiesen, die von Internetverbindung und Cloud-Konto abhängig sind
Plan
- Es wurde bestätigt, dass die mobile App mit einem Cloud-Server verbunden ist und Fernsteuerung ermöglicht
- Es wird nach einer Methode gesucht, durch Abfangen des Netzwerkverkehrs das Gerät zu steuern
Analyse der mobilen App
- Die Android-App wurde analysiert und es wurde bestätigt, dass sie mit React Native entwickelt wurde
- Es wurde entdeckt, dass sie sich über WebSocket mit dem Cloud-Server verbindet
Netzwerkanalyse
- Mit Pi-hole wurden DNS-Abfragen überprüft und mit Wireshark der Datenverkehr analysiert
- Über UDP-Pakete wurde die Kommunikation zwischen Gerät und Server bestätigt
Paketanalyse
- Mit einem UDP-Proxy wurde der Verkehr zwischen dem Gerät und dem Cloud-Server vermittelt
- Mit Wireshark wurde die Paketstruktur analysiert und die Möglichkeit von Verschlüsselung festgestellt
Physische Zerlegung
- Das ESP32-basierte Gerät wurde zerlegt und die Firmware vom Flash-Chip gedumpt
- Mit esptool wurden die Daten über eine serielle Verbindung ausgelesen
Flash-Analyse
- Mit esp32knife wurden die Flash-Daten analysiert und die Partitionstabelle geprüft
- Im FAT-Dateisystem wurden wichtige Dateien gefunden
Erste statische Analyse
- Mit Ghidra wurden die Strings der Firmware analysiert und die Nutzung einer Kryptobibliothek bestätigt
- Mit der Bibliothek mbedtls werden die Algorithmen ECDH und HKDF implementiert
Firmware-Modifikation
- Mit Ghidra wurde die CapSense-Funktion deaktiviert und das Gerät mit der modifizierten Firmware gebootet
- Das Problem mit der Prüfsumme wurde gelöst und die modifizierte Firmware erfolgreich geflasht
Paket-Header
- Die Struktur des Paket-Headers wurde analysiert, um Seriennummer und Nachrichtenkennung zu identifizieren
- Die Muster von Client-Anfragen und Server-Antworten wurden erkannt
Paket-Prüfsumme
- Die CRC-Prüfsumme wurde überprüft, um die Integrität der Paketdaten zu verifizieren
1 Kommentare
Hacker-News-Kommentare
Die langfristige Lösung besteht darin, keine Haushaltsprodukte zu kaufen, die lokale Steuerung ignorieren
Dass ein Luftreiniger seine Leistung erhöht, wenn die Luftqualität im Innenraum sinkt, erfordert keine IoT-Geräte, keine App, keine Funkkommunikation und keinen Hub
An Verkäufer von ESP32-basierten IoT-Geräten:
An Besitzer von ESP32-basierten IoT-Geräten:
Ich frage mich, ob man herausfinden kann, welche Pins auf dem Board des Geräts verbunden sind, es vollständig mit ESPHome flashen und eine benutzerdefinierte YAML-Konfiguration schreiben könnte
Jedes Mal, wenn ich in einem Designteam für IoT-Geräte war, war ein auf Sicherheit fokussierter Ingenieur für den Boot-Schutz zuständig
Feedback zum Artikel:
Ich frage mich, warum keine standardisierte Lösung verwendet wurde
Es war selten, dass bei ESP32-IoT-Geräten Firmware-Verschlüsselung verwendet wurde
Eine Meinung dazu, dass Serviceingenieure entschieden haben, keine Standardprotokolle wie DTLS zu implementieren
Wer smarte Geräte verwendet, sollte DD-WRT, OpenWrt, Tomato oder Asuswrt-Merlin nutzen, um die Geräte in einem vom privaten Netzwerk getrennten VLAN zu isolieren
Man sollte ein gekauftes Produkt nicht hacken müssen, um es zu benutzen