1 points par GN⁺ 2025-04-16 | 1 commentaires | Partager sur WhatsApp
  • Rétro-ingénierie d’un appareil de maison connectée basé sur ESP32 pour l’intégrer à Home Assistant
  • Analyse de l’application mobile pour confirmer la connexion à un serveur cloud
  • Interception du trafic réseau pour tenter de contrôler l’appareil
  • Dump et analyse de la flash ESP32 afin de tenter une modification du firmware
  • Analyse de la structure des paquets pour comprendre le chiffrement et la somme de contrôle

Introduction

  • Tentative récente de connecter tous les appareils à Home Assistant
  • Un purificateur d’air précis ne se connecte qu’à son application propriétaire, d’où la volonté de le pirater pour l’intégrer
  • Mise en avant des problèmes des produits dépendants d’une connexion Internet et d’un compte cloud

Plan

  • Vérification que l’application mobile se connecte à un serveur cloud et permet le contrôle à distance
  • Recherche d’une méthode pour contrôler l’appareil en interceptant le trafic réseau

Analyse de l’application mobile

  • Analyse de l’application Android montrant qu’elle a été développée avec React Native
  • Découverte d’une connexion au serveur cloud via WebSocket

Inspection du réseau

  • Utilisation de Pi-hole pour vérifier les requêtes DNS et de Wireshark pour analyser le trafic
  • Confirmation des communications entre l’appareil et le serveur via des paquets UDP

Analyse des paquets

  • Utilisation d’un proxy UDP pour relayer le trafic entre l’appareil et le serveur cloud
  • Analyse de la structure des paquets avec Wireshark et confirmation de la possibilité d’un chiffrement

Démontage physique

  • Démontage de l’appareil basé sur ESP32 et extraction du firmware depuis la puce flash
  • Utilisation de esptool pour lire les données via une connexion série

Analyse de la flash

  • Utilisation de esp32knife pour analyser les données de la flash et vérifier la table de partitions
  • Découverte de fichiers importants dans le système de fichiers FAT

Analyse statique initiale

  • Utilisation de Ghidra pour analyser les chaînes du firmware et confirmer l’usage d’une bibliothèque de chiffrement
  • Implémentation des algorithmes ECDH et HKDF via la bibliothèque mbedtls

Modification du firmware

  • Désactivation de la fonctionnalité CapSense avec Ghidra, puis modification du firmware pour démarrer l’appareil
  • Résolution du problème de somme de contrôle et flash réussi du firmware modifié

En-tête des paquets

  • Analyse de la structure de l’en-tête des paquets pour identifier le numéro de série et l’identifiant de message
  • Identification des schémas des requêtes client et des réponses serveur

Somme de contrôle des paquets

  • Vérification de la somme de contrôle CRC pour valider l’intégrité des données des paquets

1 commentaires

 
GN⁺ 2025-04-16
Avis sur Hacker News
  • La solution à long terme consiste à ne pas acheter de produits domestiques qui ignorent le contrôle local

    • Si un mot de passe Wi‑Fi est obligatoire, je renverrais le produit
    • Si l’on veut sacrifier la sécurité et la vie privée, c’est un choix personnel, mais il faut proposer une option permettant de refuser sans perte de fonctionnalités
    • Je n’achèterais pas de caméra de sonnette qui ne prend pas en charge RTSP
  • Le fait qu’un purificateur d’air augmente son activité lorsque la qualité de l’air intérieur se dégrade ne nécessite ni appareil IoT, ni application, ni communication sans fil, ni hub

    • Il suffit d’ajouter au purificateur d’air un capteur de qualité de l’air et un petit LCD pour ajuster les paramètres
    • Le fait que l’éclairage du couloir s’allume automatiquement fonctionne sans cloud, HomeAssist, WiFi, Zigbee, application ni remplacement de batterie
    • Cela fonctionne sans problème même quand le réseau tombe en panne depuis 10 ans
  • Aux vendeurs d’appareils IoT basés sur ESP32 :

    • Mettre à niveau un appareil intelligent pour l’intégrer à un système domotique n’affecte pas les autres instances ni les services cloud
    • Les données produit sensibles sont obscurcies ou supprimées
  • Aux propriétaires d’appareils IoT basés sur ESP32 :

    • Je crée un projet open source pour retirer le cloud des produits de maison intelligente et les déboguer, et j’en apprends beaucoup sur les aspects techniques
    • J’ai consacré beaucoup d’efforts à la rédaction de ce billet et j’aimerais avoir des retours sur la forme
  • Je me demande s’il serait possible d’identifier quelles broches sont connectées sur la carte de l’appareil, de le flasher entièrement avec ESPHome et d’écrire une configuration yaml personnalisée

  • Chaque fois que j’ai fait partie d’une équipe de conception d’appareils IoT, l’ingénieur axé sur la sécurité s’occupait de la protection du boot

    • Je suis surpris qu’il n’y ait eu aucune résistance au dump du firmware et au reflashage
    • Je me demande pourquoi le chiffrement de la flash n’est pas utilisé
  • Retour sur l’article :

    • Pour la note sur l’utilisation des clés d’appareil, le plus clair est d’avoir des clés par appareil
    • Je voudrais partager un retour sur la complexité et les risques de la gestion de clés par appareil
    • Le chiffrement au niveau de l’appareil peut causer beaucoup de problèmes à l’usine, et s’il est possible de s’en passer pour le produit, mieux vaut l’ignorer
  • Je me demande pourquoi une solution standardisée n’a pas été utilisée

    • Cela semblerait plus rentable que de créer sa propre solution
  • J’ai rarement vu l’usage du chiffrement du firmware sur des appareils IoT ESP32

    • S’il avait été impossible de lire le firmware, il aurait été difficile de créer les certificats
    • Mais en même temps, c’est impressionnant
  • Avis sur la décision des ingénieurs service de ne pas implémenter de protocole standard comme DTLS

    • Je ne suis pas certain que chaque appareil possède sa propre clé privée unique
    • Si tous les appareils partagent la même clé privée du firmware, on peut rétroconcevoir un seul appareil pour mener une attaque MITM contre les autres
  • Les personnes qui utilisent des appareils intelligents devraient se servir de DD-WRT, OpenWrt, Tomato, Asuswrt-Merlin pour isoler leurs appareils dans un VLAN séparé du réseau privé

  • On ne devrait pas avoir à pirater un produit acheté pour pouvoir l’utiliser

    • L’économie de la « rente de situation » devrait être régulée ou interdite