[2/2] Weather Station Gateway : Protocol analysis
NOTICE : THIS ARTICLE IS NOT FULLY TRANSLATED TO ENGLISH YET
Bon maintenant qu’on a tout mis en place et qu’on sait comment récupérer des trames de communication entre notre gateway et le serveur dans le cloud, on va passer à la partie intéressante : l’analyse du protocole et tenter de retrouver notre valeur de température et d’humidité dans cette soupe de bits.
Juste avant on va rapidement regarder les trames HTTP qu’on a vues passer dans la partie précédente :
La première requête (35) arrive à 24 secondes après le début de la capture, pas grand chose à dire dessus, c’est la trame qui est envoyée dès que la gateway a fini de booter. Il y a peu de chance qu’elle contienne des informations intéressantes mais on va quand même l’analyser un peu par curiosité.
La seconde requête (77) arrive au temps arbitraire de 37 secondes après le début de la capture. Et la troisième (784) arrive à 459 secondes après le début de la capture.
Entre la requête 77 et 35 il y a un delta de 13 secondes et entre la 784 et la 77 il y a un delta de 422 secondes. Sauf que 422 secondes, ça fait 7 minutes ! Et 7 minutes, c’est l’intervalle d’envoi des données par le capteur (comme spécifié dans la notice). On est donc quasiment certain que les données de température et d’humidité se trouvent dans les paquets http 77 et 784 et probablement dans tous les autres paquets de taille 118 octets qui vont arriver toutes les 7 minutes.
Comme j’ai conscience que ce que je viens d’énoncer n’est pas forcément très clair, je vais montrer une chronologie des événements :
Récupération du maximum d’informations
Pour commencer, on va essayer de récupérer le maximum d’informations susceptibles d’être envoyées par la gateway afin de tenter de les retrouver dans notre paquet HTTP. Je n’ai rien trouvé d’intéressant sur le boitier de la gateway, par contre sur le boitier du capteur j’ai trouvé un QR code donnant les informations suivantes :
071D2532CEA2 27.05.2015 MA10410
Le premier mot est très probablement un identifiant unique ou un numéro de série (je vous rappelle qu’une gateway peut recevoir les infos de plusieurs capteurs donc ce genre de numéro d’id est indispensable). La date qui suit est probablement celle de fabrication et le dernier mot est simplement le modèle du capteur.
On a vu dans la capture wireshark que l’adresse IP de la gateway est 192.168.51.120 et on peut trouver son adresse mac de la même façon (00:1d:8c:0e:e4:59). En faisant une recherche de port ouvert avec nmap sur 192.168.51.120 on s’aperçoit que le port 80 (http) est ouvert et en se connectant dessus avec n’importe quel navigateur internet on découvre une véritable mine d’or d’informations :
Analyse de la trame de boot (paquet 35)
Parce qu’elle est envoyée par la gateway directement après que celle-ci ait fini de booter, il y a peu de chance d’avoir les informations qui nous intéressent, mais c’est un bon cas d’école avant de s’attaquer aux autres trames dont le contenu est plus complexe :
Sur la partie tout en bas, nous pouvons voir :
- A gauche : L’intégralité du paquet 35 en hexadécimal
- A droite : Une traduction de ce code hexadécimal en ASCII
On retrouve donc notre contenu HTTP qu’on pouvait lire dans la partie 1 de l’article, mais surtout on retrouve (tout en bas en surbrillance bleue) la partie DATA (15 bytes) qui nous intéresse.
A partir de maintenant (et pour les prochains articles sur ce sujet) je n’afficherai que la partie DATA de la capture, puisque le reste des informations du paquet est superflu pour notre analyse.
On a donc en DATA les 15 octets suivant : 0f 00 00 00 07 00 1d 8c 0e e4 59 00 01 00 32
A partir de là on peut regarder les informations qu’on a récupérées plus tôt et on retrouve l’adresse mac de la gateway !
0f 00 00 00 07 00 1d 8c 0e e4 59 00 01 00 32
On peut donc faire une supposition sur la structure de ce type de DATA
Code la requête = 0F : C’est probablement pour permettre au serveur d’identifier le type de requête que peut faire la gateway. Je n’en connais que deux pour l’instant :
- 0F : requête après boot de la gateway pour annoncer son @mac au serveur
- DA : requête lorsque la gateway reçoit les données du capteur qu’elle doit transmettre au serveur. Nous allons voir ça juste après.
Pour les champs valeur 16 bit 1 et 2, je ne sais pas à quoi ils servent, je ferai sans doute une article « bonus » pour essayer de comprendre.
Analyse des trames de données
Les trames de données (partant toutes les 7 minutes, lors de la réception des données du capteur) sont plus volumineuses que celles d’après boot, mais la bonne nouvelle c’est qu’elles font toujours la même taille (64 octets). Je rappelle que l’on cherche dans ces trames les données de température et d’humidité.
Pour augmenter nos chances de deviner la signification des codes hexadécimaux, j’ai laissé tourner wireshark un long moment pour avoir le plus de captures possibles (7 captures). Je vais mettre en évidence les données qui changent d’une capture à l’autre ou les données correspondantes aux informations qu’on a récupérées au début de cette partie. Je vais également ajouter la température et l’humidité relevées au moment de la capture des trames.
Recherche de l’humidité et température
Chercher l’humidité va être le plus facile. On recherche simplement une valeur entière entre 0 et 100. Il suffit de prendre une mesure d’humidité qui a été faite (par exemple, la première 65 %), de convertir cette valeur décimale (65) en hexadécimal (41) et de la chercher dans la capture. On retrouve notre 41 (encadré en vert foncé) dans la première capture et on se rend compte que ça fonctionne pour le reste des captures (sur la dernière 69 en décimale => 45 en hexa), on retrouve à chaque fois notre humidité au même endroit (octet n°18 en partant de « da »).
L’autre bonne nouvelle, c’est que le contenu n’est pas chiffré ! Et ça va vraiment nous faciliter la tâche.
Pour la température, la recherche va être plus complexe car il y a plusieurs façons d’encoder un nombre à virgule, donc appliquer la technique que l’on a utilisée pour l’humidité ne sera pas aussi simple. Je propose qu’en attendant on regarde les autres champs dans l’ordre.
Encadré Jaune
Alors lui je vous l’accorde il est pas simple à trouver. Vous remarquerez d’abord que la valeur 5f 67 fait partie de l’encadré alors qu’elle ne change jamais dans les captures. J’ai eu de la chance sur ce coup, j’ai reconnu la valeur commençant par 5f parce que je l’ai rencontrée il y a quelques temps lors d’un précédent reverse engineering. Il s’agit du temp unix symbolisant la date (nombre de secondes depuis le 1er Janvier 1970). En utilisant n’importe quel site de conversion de temps unix, vous trouvez que 5f 67 6e b7 = « GMT: Sunday, September 20, 2020 3:01:11 PM »
Si vous vous lancez dans ce genre d’analyse, chercher la valeur 5f peut vous aider à trouver cette valeur de temps unix time (du moins jusqu’au 14 Janvier 2021).
Encadré Rouge
Celui là il va être rapide, 07 1D 25 32 CE A2, c’est simplement le numéro de série du capteur qu’on a trouvé au début de cette partie. On devait un peu s’attendre à ce que la gateway l’envoie au serveur pour qu’il sache quel capteur a relevé les données qu’il reçoit.
Encadré Violet
Lui il est assez simple, c’est un nombre qui s’incrémente de 1 à chaque envoi de données. On appelle ça un numéro de séquence, vous remarquerez qu’entre deux captures on passe de 13 à 15. La raison est qu’une donnée envoyée par le capteur à la gateway a été perdu (erreur de transmission) et donc la gateway n’a rien envoyé au serveur cloud (et donc la capture n’y est pas). Pour le confirmer on peut regarder le temps unix à la trame séquence 13 (5:20:39) et celui de la trame séquence 15 (5:34:37). On a 14 minutes d’écart à la place de 7 !
Le reste ?
Et bien ce sera détaillé dans la partie suivante ! Cet article est déjà beaucoup trop long. Et ça vous fait un petit défi en attendant la réponse. Je rappelle que nous cherchons toujours à quelle position se trouve la température. Je donne tout de même un indice : Un indice
C’est dans la partie rose clair, celle juste après le numéro de séquence.