Je suis de retour sur le hack des objets Xiaomi Mi Smarthome qui fonctionne en ZigBee. Dans cet article, je vais vous expliquer comment j’ai trouvé la clef pour déchiffrer les données envoyées par vos petits objets Xiaomi MI.
Résumons:
Dans le premier article, je vous ai montré comment prendre le contrôle sur un capteur Xiaomi avec le fameux port de programmation. (J’avais choisi le capteur de température / humidité dans cet exemple)
Puis, je vous avez montré comment transformer votre capteur en sniffer ZigBee afin de comprendre comment tout ça fonctionnait.
Grâce à ces deux articles, on avait pu voir comment la gateway Xiaomi dialoguait avec vos IoT… Mais j’étais resté bloqué sur la lecture des données. En effet, le sniffer ne pouvait pas décoder car il manquait un jeu de clef.
Hé bien, dans ce chapitre, je vous montre comment trouver la clef qui permettra de déchiffrer les données.
Ma note
Votre note
Recherche et étude du protocole
Pour tout vous dire, je ne pensais pas y arriver et je ne pensais pas que le protocole était aussi « étendu ». A vrai dire, je pensais que la seule solution pour trouver la clef était d’effectuer un « brute force » et d’y passer quelques siècles (vu le chiffrement AES 128).
Mais je ne le dis jamais assez, je suis très curieux et pugnace dans certains cas. J’ai pris donc la décision d’étudier le protocole (ZigBee pro vu ce que retourne le sniffer). La tâche n’est pas facile, car il faut du temps, beaucoup de temps, sans mettre de côté les autres projets qui me tiennent à cœur.
Je ne vais pas non plus vous faire un cours complet sur le protocole ZigBee (je n’en suis pas capable et pas encore expert) mais je vais vous partager ce que j’en ai compris.
Historique ZigBee PRO
Il existe plusieurs protocoles à base de 802.15.4 sur du 2.4Ghz. (je vous laisse allez voir la norme sur wikipedia) dont le fameux ZigBee. Et sur ce protocole, il existe plusieurs couches comme :
- Jennic (NXP)
- Zigbee pro
- Zigbee IP
- Zigbee RF4CE
Ils ont tous des spécificités différentes mais voici comment fonctionne le ZigBee PRO.
Cette couche est un standard pondu par la ZigBee alliance permettant de créer un réseau maillé pour que des objets puissent communiquer entre eux.
Le réseau maillé est donc composé de :
- Coordinateurs (c’est par exemple la gateway Xiaomi)
- Routeurs (comme son nom l’indique reroute les paquets comme le plug Xiaomi)
- Capteurs ou objets connectés (bouton poussoir, capteur température, capteur mouvement …)
Historiquement, ce protocole était plutôt destiné à l’industrie (comme beaucoup), puis destiné à la gestion d’éclairage (comme les Philips HUE) et vu l’engouement pour la domotique, ils ont décidé de le rendre compatible pour le pilotage et la gestion d’énergie de la maison.
Chacune de ces étapes ont été caractérisées par l’implémentation d’une couche protocolaire. En gros, il y a, le ZigBee Pro puis le ZigBee Light Link et le ZigBee HA par dessus comme suit :
Dans le schéma précédent, on voit qu’il existe plein de protocoles d’applications mais je ne vais m’intéresser qu’à 2 d’entre eux: le ZLL (protocole Philips Hue) et le ZHA (protocole du Xiaomi). Comme on peut le remarquer, les deux peuvent fonctionner en parallèle.
Fonctionnement du ZigBee
Pour fonctionner et pour des raisons de sécurité, le ZigBee pro fonctionne un peu comme beaucoup de protocole radio.
En effet, au moment de la connexion, l’objet demande au coordinateur d’intégrer son réseau (appairage ou comissioning). Après un jeu de négociation (échange de clefs), l’objet est accepté …ou pas et intègre… ou pas le réseau ZigBee. L’objet peut ensuite parler librement (bien entendu, en utilisant la clef préalablement négocié).
Voici comment fonctionne le comissioning du ZigBee ZLL et ZHA.
Dans ce billet, je ne vais parler que du ZHA (ZigBee Home Automation) car je me consacre pour le moment qu’aux objets de chez Xiaomi.
Alors vous allez me dire :
"Comment tu sais que le protocole utilisé par les Xiaomi est le protocole ZHA ?"
Et bien, grâce à certains commentaires et quelques recherches, je suis tombé sur beaucoup de communication autour d’une Box domotique : la SmartThings de chez Samsung. Grâce à leur forum actif, j’ai pu me rendre compte que du travail avait déjà été effectué et qu’il en résultait (sur la fin) que le protocole « ressemblait » à du ZHA sans pour autant que les objets soient marqués « ZHA compliant ».
Certaines personnes, en modifiant uniquement des scripts, ont réussi à appairer des capteurs Xiaomi alors c’est à ce moment là que j’ai repris espoir !!!
Si une autre box ZigBee, sans modifier le matériel, peut être compatible alors il y a de grande chance qu’il y est une faille quelque part.
Le protocole ZHA
Je me suis donc intéressé à cette couche protocolaire. Pour tout connaître sur le protocole, je suis allé chez les créateurs, récupérer de la documentation. Vous y verrez tous ce que l’on peut faire avec le « Home Automation ».
Puis, je suis tombé sur le manuel utilisateur du Zigbee Home Automation chez NXP. C’est compliqué de résumé… mais en gros, cette stack permet de cloisonner sous forme d’arbre simple (un peu comme les MIB sous SNMP, je ne sais pas si vous connaissez), les fonctionnalités de votre capteur.
En gros, en lisant simplement les différents attributs et données du protocole, vous êtes en mesure de savoir quel type de capteur il s’agit et comment interagir avec lui.
En tout cas, comme de par hasard, on retrouve presque tous les types proposés par les solutions Xiaomi.
Ce protocole est assez complet et complexe car il fonctionne sous forme de « cluster » et vous avez la capacité de créer des groupes et des scénarios bien précis. En général et comme je vois la domotique dans sa globalité, c’est plutôt la box domotique qui devrait s’en occuper…
Bref, à force de recherche, et en étudiant certains codes sources de chez NXP, je suis tombé sur une clef qui revenait souvent :
The Trust Center Link Key : 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39
Cette clef est en fait une clef par défaut du protocole permettant de négocier une autre clef lors de l’appairage de votre objet.
Comme on le voit dans le schéma de fonctionnement précédent, le but est de récupérer la clef réseau (NWK Key) qui se trouve la trame de type « TRANSPORT ».
Voyons comment procéder pour mettre tout ça en pratique.
De la théorie à la pratique
Pour commencer on reprend bien entendu les bons outils à savoir le capteur en mode sniffer et le logiciel qui va permettre d’afficher les trames sur mon ordinateur, Ubiqua Protocol Analyser.
Alors, je n’ai toujours pas réussi à faire fonctionner Wireshark avec mon sniffer et pourtant j’ai pas mal cherché mais même en redirigeant les flux du port COM vers une carte réseau (à l’aide de socat), je n’ai pas réussi. Je pense qu’il y a une commande à envoyer(sur la COM) pour activer le « sniffage » que je ne connais pas. (Mais je ne perds pas espoir). Il faut que je « flic » ce que fait Ubiqua Protocol Analyser pour activer le sniffer.
Comme j’avais passé les 21 jours de démonstration, j’ai redemandé une licence de démo (avec un autre compte mail).
C’est parti !
Insérer la Link Key dans le logiciel
Pour que le logiciel puisse décoder les trames, il faut lui ajouter la clef:
pour cela, il faut aller dans Tools –> Options –> Security
Il suffit de cliquer sur Add puis sélectionner le type de clef, ici c’est la Trust Center Link Key et de copier/coller la clef.
Lancement du « sniffage »
Il suffit ensuite de lancer le « sniffage » et de manipuler les objets pour les faire communiquer.
Dans mon cas, j’ai mis en place ma passerelle Xiaomi et un bouton poussoir de chez Xiaomi. La passerelle a été paramétrée sur mon téléphone grâce à l’application fourni.
Je procède donc à l’appairage en ajoutant un sous-device de type bouton poussoir (tout ça dans l’application téléphone). La passerelle se met donc en écoute (30 sec). Je me saisi donc de mon bouton poussoir et à l’aide d’une aiguille (fourni avec), je fais une pression longue sur le bouton prévu à cet effet.
Voici un extrait de ce que j’ai obtenu :
Bingo ! La clef de « linkage » est la bonne et le sniffer arrive à décoder l’ensemble des trames. Du coup, j’ai bien obtenu ma clef réseau (NWK KEY) sur la trame de Transport… Comme on l’a vu dans le diagramme d’action plus haut.
Et voici les données de la trame :
Alors ne croyez pas que je ne veuille pas vous donner la clef réseau, c’est juste qu’elle est différente pour chaque passerelle ou trust center. Du coup, je ne peux vous montrer que la méthode … (mais c’est déjà pas mal non ?)
Enfin voici le décodage d’une trame (j’ai choisi le capteur de température / humidité, c’est plus parlant)
La partie « données » se trouve dans la partie verte avec la valeur de 64.22% d’humidité et 22.90°C
Et voilà, on est en mesure, maintenant, de décoder toutes les trames des capteurs Xiaomi Mi Smart home. J’ai placé sur mon Github un fichier Excel reprenant la plupart des attributs des capteurs Xiaomi liés au protocole Zigbee ZHA.
Conclusion
Nous avons vu dans ce billet comment décoder les trames des capteurs Xiaomi Mi Smarthome. Ça pouvait paraître simple parce qu’il suffisait de regarder la documentation chez NXP pour trouver la clef pour l’appairage mais débutant sur le protocole ZigBee, ce n’était pas gagné d’avance.
Cet article marque pour moi un tournant car maintenant, on est en mesure de faire pleins de choses. La qualité des objets Xiaomi est surprenante et leur prix défie toute concurrence. Le protocole enfin ouvert, ça donne encore plus de bonnes perspectives… Je ne sais pas si le fait d’utiliser la clef par défaut est volontaire ou pas (j’ai l’impression qu’ils font tous ça) mais ça ouvre encore plus de possibilité pour en faire des objets presque parfaits. ( j’ai du mal à trouver des défauts).
Cependant, ce hack relève encore un problème et ouvre le débat de la sécurité des objets connectés. Heureusement que le système physique d’appairage existe car sinon ce serait la foire et tout le monde pourrait récupérer les informations de tout le monde. (Je ne sais pas si c’est vraiment grave si on reste dans les sondes simples)
Bref, grâce à ce hack, je passe aussi à la vitesse supérieure puisque j’ai décidé de fabriquer ma propre passerelle avec les avantages suivant :
- Pas de cloud ! (même si c’est facilement bloquable, ça reste un avantage)
- Une meilleure fiabilité (Pas de WiFi, un lien série direct vers votre Raspberry ou autre …)
- Une meilleure maîtrise des données. (vous serez les maîtres de vos données et c’est votre box qui gérera vos propres scénarios)
- Une meilleure portée !!! aujourd’hui la passerelle Xiaomi a une antenne PCB 2.4Ghz. Celle que je conçois aura une antenne externe (compatible avec antenne WiFi de toute taille avec un connecteur SMA). De plus, avec son cordon vous pourrez facilement la mettre sur un point haut.
- Pas de limitation logiciel sur le nombre de noeuds pilotables.
- A venir : Compatibilité avec tous les devices ZigBee ZHA et ZLL dont les Philips Hue
D’après ce que j’ai prévu, je vais décliner mon produit en deux versions:
- Mode normal longue portée (jusqu’à 1Km théorique…plutôt 30-40 mètres indoor)
- Mode très longue portée +3db (jusqu’à 2Km théorique…plutôt 60 mètres indoor)
Bien entendu, je vais tester les portées et m’assurer du gain de l’un sur l’autre… Si ça n’a pas d’intérêt je vous le dirais…
Enfin, en discussion avec @sarakha63, un plugin Jeedom devrait voir le jour prochainement.
A très bientôt pour de bonnes nouvelles, je l’espère…
Bonjour,
Sera t’il possible de transférer les données via une requête http ?
En tout cas bravo, super travail qui ouvre beaucoup de possibilités !
Bonjour,
La passerelle que je conçois dialoguera sur le port série. Il suffira simplement que ta Raspberry ou autre… transfère les données en HTTP…
Bravo bravo bravo !
Bravo pour le temps, le travail de dingue et surtout la pédagogie avec laquelle tu expliques le sujet
Je suis maintenant impatiens de voir le résultat
Bonne continuation
/Jordan
Superbe !
un article comme on en lit pas (assez) souvent. Continues, stp, j’ai hâte de lire ton travail sur les hue 🙂
Super boulot!!!
Moi j’avais abandonné bien avant toi lol
Super boulot!!!
Moi j’avais abandonné bien avant toi lol
Bravo et félicitations
Très content que tu sois arrivé au bout de tes recherches.
Super boulot en tout cas.
Je possède des volets roulant Zigbee de chez profalux que je vais bientôt faire flasher pour passer en HA1.2.
Crois tu que ce sera compatible? je reste disponible en cas de besoin.
Je possède une clé usb Zigbee de chez télégesis j’essaierai de sniffer le réseau pour voir.
Au plaisir de te lire
Je ne peux pas te répondre précisément car je ne connais pas les volets roulants Profalux. Cependant, s’ils sont compatibles ZHA et que tes appareils utilisent la clef par défaut Trust Center Link Key, ça devrait être compatible… Si tu as une clef ZigBee + un logiciel qui te permet de changer la clef, il ne te reste plus qu’à tester …
Merci pour ta réponse, je testerai ça dès qu’ils seront flashé dans la dernière version de HA1.2
Bravo pour le travail réalisé 🙂 et surtout le travail de rédaction je lis avec grand plaisir tous ces articles aussi passionnant les uns que les autres. Avoir les compétences techniques est déjà une richesse 🙂 mais avoir la capacité de suscité l’intérêt et de transmettre ces connaissances est juste génial
je ne peux que réclamer encore plus 🙂 d’ailleurs il y a la gamme tradfri de ikea en zigbee ….
enfin je dis ça 🙂
Merci à tous pour votre soutien… ça motive 😉
Merci pour le boulot.
Tu l’as noté en conclusion mais la question de la sécurité du zigbee se pose vraiment . Il y a peu, un immeuble entier sous Hue s’était fait hacke grâce à un drone je crois (ou en tous cas on voyais les images par drone ). Perso, je ne vois pas la sécurité seulement sous la aspect intrusion mais aussi sous le aspect vie privée. Oui j’ai un Android mais je corrige bcp de droits laissés ouverts par défaut. Bref, déjà que je n’aimais pas le zigbee vs zwave pour sa portée ridicule (sous Hue) ce côté manque de sécurité me gêne. Comme toi, je ferais peut être appel aux capteurs de temperature. Mais à un moment, lorsque bcp de maisons seront connectées. Il sera intéressant de hacker ce capteur pour déclencher un chauffage ou un climatisation à outrance pour faire chier son voisin. C’est débile mais ça rappelle furieusement les script kiddies qui font chier juste pour le Fun. Bref, vivement que les protocoles se sécurisent et éliminent les plus mauvais ď entre eux.
Merci pour cette pédagogie. J’espère que votre passerelle sera aussi compatible avec domoticz.
Super article qui laisse entrevoir de belles perspectives.
Chapeau …
Merci
Super article et belle avancé, comme il n’y a pas que jeedom, nous les autres, on espere que tu vas avoir la courtoisie de mettre les sources de ta gateway en ligne, que l’on puisse en profiter aussi 😉
C’est une évidence…
Bravo ! Très belle performance et très bonne pédagogie aussi. Je lis tes articles avec toujours autant de plaisir et j’attends avec impatience le plugin jeedom pour investir dans ces capteurs de qualité à tarif très attractif !
Par ailleurs, je dispose de la Pluzzy box de Toshiba (j’étais bêta testeur de leur solution) et depuis que Toshiba a abandonné le projet, j’ai fait une croix dessus et m’apprêtais à débrancher tout ça, faute d’interopérabilité avec mes autres équipements domotique. Voyant que Toshiba n’a pas souhaité donner l’accès à L’API, et sachant que les capteurs et actionneurs utilisent le protocole Zigbee, j’avais peu d’espoir quant au fait de pouvoir un jour les interfacer.
J’attends maintenant la suite : Episode IV – A New Hope
Hello,
Si je pouvais redonner vie à ma box Pluzzy et ses modules ce serait vraiment génial !
Cet article est excellent.
Merci.
Surtout depuis qu’on a reçu le mail de ijenko disant qu’ils éteignaient les serveurs et donc que tout notre matériel Pluzzy devait aussi utile qu’un serre-livre ou un dessous de plat (et même ça les équipements Pluzzy ne pourront pas le faire).
J’ai demandé si on pouvait disposer des spécifications d’interface, des protocoles, mais ils m’ont dit non
C’est en effet une chance que Xiaomi ait utilisé la clef standard pour l’appairage. S’ila avaient voulu rendre les choses bien plus difficile, ils auraient utilisé une clef fabricant et n’être compatibles qu’avec eux-mêmes.
Ensuite, ce n’est pas vraiment une faille: En réalité la vraie clef n’étant visible qu’a l’appairage, qui est sans doute (c’est en tout cas vrai pour le z-wave+, l’appairage doit se faire proche du controleur, genre moins de 1 ou 2m) réalisé à puissance moindre pour limiter les chances de capture, avoir un malin qui écoute au bon moment et avec un matos assez sensible c’est quand même pas gagné.
Puis il n’y a pas le choix: C’est le contrôleur qui a la vraie clef, différente pour chacun, donc sauf à contraindre les gens à acheter un lot (avec des périphériques ayant tous la même clef d’appairage que le contrôleur) et à ne pouvoir jamais racheter de capteurs séparément pour étendre leur système… Il faut bien à minima une clef d’appairage par fabricant, sinon universelle quand on ne conçoit pas la maison communicante qu’avec soi-même (genre Velux et Somfy avec leur putain d’IO Home), ce qui finit toujours par vous retomber dessus (Velux est principal responsable de la croissance de leur concurrent Fakro, qui est lui en z-wave et propose des dimensions compatibles en rénovation).
Super boulot et j’attend le plugin Jeedom avec impatience 😉
Super boulot,
Sur le point cloud, en attendant la fin de ton boulot, tu as les types de trame qu’il faut bloquer sur le firewall pour éviter le dialogue de la passerelle avec l’extérieur?
Bah il faut juste interdire ta passerelle de sortir vers l’extérieur. Je ne connais pas le type de trames… désolé… Inconvénient, elle ne se mettra plus à jour.
Merci pour cet article !
j’ai également mis en place le blocage de la gateway vers l’extérieur sur mon routeur, mais apparemment mes capteurs xiaomi (comme les boutons ou les ampoules yeelight que j’ai bloqué également) semblent ne plus répondre aux commandes après quelques heures (pas de problème dans l’immédiat suite au blocage)….est ce que quelqu’un à remarqué cela? ou suis je le seul….
Je suis bluffé, et en peine aussi de trouver un moyen de reutiliser les 10 equipements Pluzzy. Je ne me sents pas l’etoffe ni le temps, mais si qq’un y arrive, je cotise a hauteur de mes moyens!
Je viens de lire ton article
Même si je pense que peu de personnes directement utiliserons ceci mais cela montre tout le travail que tu donne pour avancer ?
Cela évite les beau parleur qui pour eux une soirée et op tout est fini
Merci de consacrer toute c’est heure à cela.
Je pense que le nombre de celle ci doit être supérieur à ce que l’ont pense
Bonne chance pour la suite
Bonjour,
j’ai trouvé une sirène zigbee HA1.2 : https://fr.aliexpress.com/item/2017-newest-HEIMAN-Zigbee-HA1-2-smart-wireless-indoor-siren-with-standby-battery-868MHz-95DB-Zwave/32831251280.html est-ce que votre technique de découverte de clé va permettre de l’apairer au Xiaomi Hub et de l’utiliser avec l’application ? Merci !
Absolument pas. La solution Xiaomi gateway ne gère que du Xiaomi avec son application
Great work! Will buy a sensor and also try it. Looking forward to the result 🙂
Bonsoir Akila et bonne année 2018! et bravo pour tout le travail déjà effectué, je suis (l’heureux !?) possesseur d’un pack 5in1 xiaomi smarthome qu’en est il des belles perspectives? full ZigBee, un plugin home assistant est il possible? utilisation sans cloud, un interfaçage avec le raspberry ou mieux le CHIP :p
je sais ça fait beaucoup de perspectives
Bonjour akila !
Joli travail !
Où en est le projet de personnalisation du firmware de la gateway ?
@ +
Bonjour,
http://ZiGate.fr ?
++
Bonjour akila,
Merci pour l’information fournie! Je suis maintenant capable de faire des lectures de température et humidité provenant d’un capteur Xiaomi. J’ai remarqué que par defaut ces senseurs envoient des lectures uniquement lorsqu’il y a une variation de température/humidité au-dessus d’un certain niveau. Est-ce vous savez comment soit demander des lectures à intervalle de temps régulier ou encore comment modifier les niveaux requis pour l’envoi des lectures? Je suppose que ça implique l’usage d’un « Write attribute request » en utilisant un certain « Cluster Id » et « Attribute Id » (sous l’hypothèse qu’un tel changement est possible), mais lesquels et quelle valeur utiliser?
Merci!
merci, super article.
Je viens de commande la nouvelle camera xiaomi, qui fait aussi office de passerelle, penses-tu qu’il soit possible de faire la même chose ? Je n’ai pas envie de passer par le cloud xiaomi mais j’ai peur de perdre des fonctionnalités, notamment, le fait de pouvoir visualiser la video via l’application smartphone. Aurais-tu une petite idée sur la faisabilité ?
Merci encore
Bonjour, merci pour cet article très pédagogique . C’est donc toi qui a développé le zigate? Félicitation !
Merci et bonne continuation!
Aurélien
Hi Akila,
Sorry, I can only use English.
Can you please tell me know where you get The Trust Center Link Key. You said in NXP’s code but where I can get it.
Thanks you so much.
I got it. Your project has given me much enthusiasm.
Thanks.
Bonjour,
Est-ce possible d’emuler un périphérique Xiaomi ? (Boutton poussoir, ou autre.)
Cordialement
Salut.
Joli taff !
Je fais aussi quelques recherche sur ce sujet, cependant la clé par défaut n’a pas l’air d’être utilisé sur mes équipements (Mi hub, window sensor, motion sensor). Wireshark ne déchiffre aucun paquet. J’ai bien peur de Xiaomi utilise maintenant une clé constructeur.
As-tu des news sur ce sujet ?
Je taff avec une ApiMote en tant que sniffer.
Thanks !
Bon, et bien l’erreur est trouvée. Les captures effectuées par l’ApiMote déconne. Après avoir utilisé une Conbee en tant que sniffer, la trasnport key apparait bien. Xiaomi utilise donc bien la LK par défaut.
Hello, your website has many interesting things, congratulations! I would like to know how is the project to have a universal open source xbee Gateway, I am interested in purchasing. I have many Xiaomi sensors and honestly the company’s Gateway is not easy to work with.
Thanks!