Accueil    Articles    Tags    Divers   

[1/2] Weather Station Gateway : Capture de protocole

Introduction

Il y a quelque temps, mon collègue Jean-Seb m’a donné un kit de station météo composé de :

• MA10410 : Wireless digital weather station
• MA10000 : MOBILE-ALERTS gateway

Le MA10410 est simplement un capteur composé d’un écran affichant la température et l’humidité qu’il a relevées dans la pièce dans laquelle il se trouve. A la vente, il est généralement accompagné d’une sonde extérieure (que je ne possède pas) qui permet d’afficher également la température, humidité et pression extérieure.

Le MA10000 est une passerelle (gateway) permettant de récupérer les informations des capteurs météorologiques tel que le MA10410 afin de les envoyer sur les serveurs web MOBILE-ALERTS. Cette passerelle est indispensable pour cette opération puisque les capteurs ne peuvent pas d’eux même envoyer quoi que ce soit sur internet ou sur n’importe quel réseau IP.

Principe de fonctionnement

Dans cet article, je vais tenter le mieux possible d’expliquer la démarche que j’ai suivie pour comprendre de quelle façon la gateway MA10000 envoie les données de température et l’humidité dans le cloud.

J’ai donc utilisé ces deux appareils comme expliqué sur la notice et constaté le fonctionnement suivant :

La sonde communique ses informations à la gateway qui à son tour les communique au serveur du fabriquant dans le cloud. En tant qu’utilisateur vous pouvez vous connecter sur ce serveur distant et consulter l’historique des données relevées par vos sondes.

Voilà donc pour le principe de base, maintenant l’objectif va être de forcer la gateway à envoyer toutes les informations à un raspberryPi que je possède à domicile plutôt que dans le cloud du constructeur. Mais pour ça il va d’abord falloir :

• Comprendre comment interpréter les données envoyées par la gateway au serveur dans le cloud
• Comprendre comment le serveur répond à notre gateway (pour la duper et lui laisser penser qu’elle s’adresse à un serveur officiel)
• Monter un service sur un raspberryPi (ou n’importe quel autre serveur hébergé chez nous) pour simuler le serveur officiel et récupérer les informations à sa place (tout ceci sera détaillé dans le troisième article)

Bon pour les deux premiers points, il n’y a pas 36 solutions, il va falloir sortir Wireshark et écouter les communications réseau entre la gateway notre box FAI.

Capture des communications avec Wireshark

Il existe plusieurs façons de capturer les communications réseau entre deux appareils sur un même réseau local. J’ai la chance de posséder un petit switch cisco qui a la fonction « port mirroring » me permettant de choisir un port à écouter pour copier les communications (entrantes et sortantes) vers un autre port. C’est sur ce dernier port que je vais connecter un laptop faisant tourner wireshark. J’ai utilisé le câblage suivant :

• Port Mirroring copiant les paquets entrant/sortant du port 1 sur le port 2

Si vous ne possédez pas un switch avec cette feature, vous pouvez toujours utiliser l’ARP spoofing sur l’ordinateur où Wireshark se trouvera. Je ne vais pas trop rentrer dans le détail de l’ARP Spoofing (il y a des tonnes de sites qui en parlent et qui expliquent comment l’utiliser), mais pour faire simple, cela permettra à votre ordinateur :

• de faire croire à la gateway MA10000 qu’il est la box FAI.
• de faire croire à la box FAI que votre ordinateur est la gateway MA10000

Il est temps de lancer wireshark et de brancher la gateway, je vais détailler ci-dessous toutes les communications entre la gateway MA10000 et le serveur dans le cloud :

1. Au démarrage, la première chose que fera la gateway MA10000 est de demander une adresse IP, un masque de sous-réseau, l’IP de la passerelle réseau (la box FAI) ainsi que le serveur DNS à utiliser. Elle va utiliser le protocole DHCP pour ça (ligne 3 à 21). Chez moi, c’est un raspberry pi qui fait serveur DHCP et non pas la box FAI, c’est pour cette raison que c’est 192.168.51.52 qui répond à la requête DHCP et non pas 192.168.51.1 (ma box FAI). L’ip 192.168.51.120 sera attribuée à la gateway par le serveur DHCP.

2. Une fois la requête DHCP complétée, elle va demander au serveur DNS renseigné par DHCP de résoudre l’adresse www.data199.com (ligne 27). Encore une fois sur la plupart des réseaux locaux, c’est la box FAI qui fait serveur DNS, mais ici c’est encore le même raspberry pi 192.168.51.52 qui va se charger de ce service. La réponse (ligne 28) indique que le nom www.data199.com a pour IP 23.97.212.128. Il s’agit de l’adresse du serveur dans le cloud devant recueillir les données de notre gateway.

3. On arrive dans la partie qui nous intéresse et on remarque assez rapidement que le protocole HTTP est utilisé pour faire transiter les données de la gateway MA10000 jusqu’au serveur dans le cloud. On va ajouter un filtre HTTP pour y voir plus clair et retirer toutes les transactions TCP qui ne nous intéressent pas.

J’ai capturé pendant environ 10 minutes (600 secondes) et pendant ce laps de temps j’ai récupéré 3 requêtes (35, 77 et 784) et leurs réponse respective (36, 78 et 785). On va utiliser la fonction « Follow HTTP Stream » de Wireshark pour regarder les trois morceaux de communication, avec un peu de chance toutes les données seront écrites en ASCII (genre JSON) et on aura plus qu’à les lire

… Eh ben NON ! Si l’entête HTTP est bien en ASCII comme le standard le défini, le contenu de la communication (encadré en vert) est en « binaire », aussi bien pour la requête que pour la réponse. Il va donc falloir analyser ces données et tenter de comprendre comment extraire la température et l’humidité, nous verrons tout ça dans la partie 2.

FAQ :

Q: Pourquoi ne pas directement récupérer les informations du capteur de température MA10410 en interceptant les communications entre lui et la gateway MA10000 ?

A: J’avais commencé par ça. Effectivement le moins d’intermédiaire on a, mieux c’est. Mais je me suis heurté à un problème assez conséquent, pour communiquer avec la gateway, le capteur utilise la fréquence 868.3 MHz modulée en PSK. Pour récupérer les informations à la place de la gateway, j’aurai donc eu besoin d’un récepteur 868.3 MHz et me débrouiller pour démoduler le PSK en software. J’ai réussi à le faire avec une clé USB RTL-SDR et une librairie github liée, mais pour le hardware cité précédemment ce n’est pas évident à trouver à moindre coût. Ca fera peut-être l’objet d’un article.

Q: Pourquoi ne pas récupérer les informations du capteur de température sur le serveur dans le cloud, comme le ferait l’application smartphone ?

A: Effectivement ça serait probablement bien plus simple, il suffit juste de parser une page HTML. Mais l’intérêt de l’article est le reverse engineering de protocole réseau et s’il faut absolument une autre raison et que vous êtes un peu parano => vous avez probablement envie de garder ce genre de donnée météorologique sur une machine que vous seul contrôlez.

Q: Pourquoi le texte sur les images est en anglais ?

A: J’ai prévu de traduire tous mes articles en anglais (et je vais donc réutiliser les mêmes images), en ne faisant pas d’images dans les deux langues je sauvegarde un peu d’espace disque sur le serveur qui héberge le blog. Et surtout ça sera beaucoup plus facile pour m’y retrouver dans la banque d’image de WordPress si je n’ai pas tout en double.