Reverse Engineering Bluetooth Protocols
1.0.0
Ce document décrit le processus que j'ai suivi pour inverser le protocole Bluetooth de mon détecteur radar Cobra Irad 900. Mon objectif initial était d'avoir mon interface Raspberry Pi 3 avec l'appareil via Bluetooth pour gérer les alertes sans avoir à utiliser l'application iOS / Android, éventuellement pour servir une belle interface avec mon "carputer" Raspberry Pi.
Il est important de noter que je n'avais aucune expérience initiale avec le protocole Bluetooth, mais c'était une expérience d'apprentissage assez amusante dans l'ensemble.
Quand j'ai commencé ce projet, je ne savais pas par où commencer mais avec Google. Je savais comment renifler le trafic Web régulier, mais Bluetooth était un peu une boîte noire pour moi. Avec une recherche rapide, j'ai trouvé la bibliothèque PyBluez ainsi que des exemples de communication via RFComm. J'ai également trouvé plusieurs bonnes ressources, dont un article de blog intéressant de Travis Goodspeed.
Cependant, je ne conseillerai pas sur le sujet, j'ai également passé beaucoup de temps sur des ressources comme celle-ci, pensant que Bluetooth Le était ce que je cherchais.
Jouant avec mon ancien iPhone 5 jailbreaké, j'ai pu utiliser BTServer pour enregistrer le trafic Bluetooth envoyé et reçu par mon iPhone. Entouré de plusieurs appareils Bluetooth, les fichiers journaux ont augmenté rapidement, bien que ce ne soit pas vraiment un problème. Heureusement, les journaux ont été publiés sous forme de fichier .pklg, ce qui facilite la filtration des paquets pertinents dans Wireshark.
Utilisation du filtre de paquet bluetooth.src == B8:92:1D:00:3F:61 , je pouvais voir les paquets bruts que l'application iOS envoyait au détecteur radar. J'ai pris quelques exemples d'enregistrements de la communication entre mon téléphone et le détecteur radar, certains avec des alertes générés, et certains sans.
Les données Bluetooth sont transférées sur le protocole RFCOMM. Lorsque les appareils se connectent pour la première fois, ils envoient des informations dans les deux sens, synchronisant probablement simplement les paramètres (plus à ce sujet plus tard). Ensuite, les deux appareils suivent un schéma prévisible entre eux. Le détecteur radar envoie un paquet RFCOMM via Bluetooth à des intervalles réguliers de 1/2 seconde. Avec un peu de temps et de patience, j'ai pu déchiffrer la structure de charge utile envoyée du détecteur radar à l'iPhone.
Structure de la charge utile: détecteur radar → iPhone
| Article | Valeur (hex) | Taille |
|---|---|---|
| Préambule | 55 | 1 octet |
| Taille de la charge utile | xx xx | 2 octets |
| Action | xx | 1 octet |
| Réservé | 00 | 1 octet |
| Som | xx | 1 octet |
| Réservé | xx xx xx xx xx xx | 6 octets |
| Alerte | xx | 1 octet |
| Type d'alerte | xx | 1 octet |
| ... | ... | ... |
À mesure que le détecteur radar est en cours d'exécution, il enverra des paquets dans le format ci-dessus. Bien que le réseautage informatique ne soit pas mon domaine d'expertise, je vais essayer d'expliquer le mieux que possible.
L'octet de préambule envoyé est toujours envoyé avec la valeur 0x55 . Cela spécifie qu'il s'agit du début d'un nouveau message de charge utile de l'appareil, plutôt que de continuer à partir d'un paquet précédent. Ensuite, une valeur de 2 octets contenant la taille du reste du message (tout après les 3 premiers octets). La valeur d'action spécifie le type d'informations que le paquet envoie.
Le numéro SEQ est l'endroit où les choses commencent à devenir intéressantes. Si vous avez suivi un cours sur le réseautage ou si vous en savez un peu sur TCP, vous savez probablement à quoi cela sert. Le détecteur radar enverra une valeur de 1 octet à l'iPhone, et l'application iOS doit répondre avec un numéro ACK de la même valeur. Sinon, le détecteur radar réalisera que quelque chose est de travers et se déconnecte.
L'octet d' Alert spécifie si une alerte est déclenchée. Si c'est le cas, il est défini de valeur 0x41 , et l'octet suivant est utilisé pour spécifier le type d'alerte est envoyé. Je ne pouvais pas trop en savoir plus sur les valeurs car je ne possède pas de pistolet radar réel. Cependant, un gars sur des instructables a fait un simulateur de pistolet Lidar à l'aide d'un Arduino. Cela a beaucoup aidé à analyser les paquets.
Afin de l'application iOS pour maintenir la connexion à l'appareil, il doit envoyer une réponse dans le format correct. Heureusement, la réponse au détecteur radar est beaucoup plus simple et n'est que de 9 octets.
Réponse: iPhone → Détecteur radar
| Article | Valeur (hex) | Taille |
|---|---|---|
| Préambule | 55 | 1 octet |
| Taille de la charge utile | xx xx | 2 octets |
| Action | 02 | 1 octet |
| Réservé | 00 | 1 octet |
| Ack | xx | 1 octet |
| Réservé | 00 42 | 2 octets |
| Comptoir | xx | 1 octet |
Comme mentionné précédemment, la valeur ACK doit être la même valeur que la valeur SEQ reçue précédemment, sinon la connexion sera déconnectée. C'était assez facile. Certains autres protocoles peuvent avoir des méthodes de vérification des clients beaucoup moins évidentes; Heureusement, ce n'était pas le cas. Fait intéressant, il existe une autre variable counter variable utilisée. Je n'ai jamais vraiment compris à quoi sert l'octet, mais il diminue de 1 pour chaque réponse à l'appareil. Ces deux valeurs étaient assez faciles à coder dans un script Python et n'ont pas du tout pris trop de travail.
Comme je l'ai mentionné plus tôt, lorsque l'application iOS se connecte d'abord au détecteur radar, certains paramètres et données sont synchronisés dans les deux sens. Ce n'était pas vraiment une de mes priorités pour comprendre et décomposer ces paquets, et je ne voulais pas passer trop de temps à ce sujet. J'ai exporté l'intégralité du connexion des paquets dans Wireshark en tant que fichier XML (data.xml), puis j'ai utilisé un script Python (parsedata.py) pour traiter et stocker les informations pour une utilisation ultérieure.
Lorsqu'il est chargé, Radar.py ouvrira les données prétraitées dans le fichier PacketData.Dat. Il analyse ensuite le détecteur radar via Bluetooth et tente de s'y connecter. Une fois connecté, le détecteur radar enverra quelques paquets de données au périphérique connecté. Heureusement, ce sont les mêmes paquets exacts dans la même séquence exacte à chaque fois. Le script Python examinera les données du fichier packetdata.dat pour le paquet qu'il a reçu. Une fois que le script Python principal trouve un paquet de machine, il envoie la réponse correspondante précédemment enregistrée au détecteur radar.
Étonnamment, cela a bien fonctionné. Cependant, j'imagine que je devrais mettre à jour le fichier de données si je modifiais des paramètres dans l'application iOS. Ce n'était pas trop un problème, car j'aurais juste besoin de configurer l'appareil une fois, et probablement plus jamais d'utiliser l'application.
Compte tenu de toutes les informations que j'ai découvertes, j'ai pu écrire un script Python qui imite la connexion de l'iPhone. Si un paquet ne se trouve pas dans la base de données des réponses enregistrées, il construit un paquet de réponse avec la structure que j'ai précédemment détaillée ci-dessus.
Avec le recul, c'était un projet vraiment amusant de faire quelque chose avec lequel je n'ai jamais vraiment eu d'expérience. En tant que majeure en informatique, il était intéressant de faire quelque chose avec du matériel pour une fois plus ou moins hors de l'ordinaire.
Brandon Asuncion // [email protected]
Tous les commentaires / commentaires sont appréciés!
