Reverse Engineering Bluetooth Protocols
1.0.0
In diesem Dokument wird der Prozess beschrieben, den ich durchlaufen habe, um das Bluetooth-Protokoll meines Radardetektors Cobra IRAD 900 umzukehren. Mein ursprüngliches Ziel war es, meine Raspberry Pi 3 -Schnittstelle mit dem Gerät über Bluetooth zu haben, um Warnungen zu verarbeiten, ohne die iOS/Android -Anwendung verwenden zu müssen, um schließlich als schöne Schnittstelle zu meinem Raspberry Pi "Carputer" zu dienen.
Es ist wichtig zu beachten, dass ich keine anfängliche Erfahrung mit dem Bluetooth -Protokoll hatte, aber es war insgesamt eine ziemlich unterhaltsame Lernerfahrung.
Als ich dieses Projekt zum ersten Mal begann, hatte ich keine Ahnung, wo ich anfangen sollte, außer mit Google. Ich wusste, wie man den normalen Webverkehr schnüffelt, aber Bluetooth war für mich ein bisschen eine schwarze Box. Bei einigen schnellen Suche fand ich die Pybluez -Bibliothek sowie Beispiele zur Kommunikation über RFComm. Ich habe auch mehrere gute Ressourcen gefunden, darunter einen interessanten Blog -Beitrag von Travis Goodsspeed.
Wenn ich jedoch nur wenig Anleitung zu diesem Thema habe, habe ich auch viel Zeit für Ressourcen wie diese verbracht und dachte, dass Bluetooth Le das war, wonach ich gesucht habe.
Mit meinem alten iPhone 5 Jailbroken 5 konnte ich BTServer verwenden, um den von meinem iPhone gesendeten und empfangenen Bluetooth -Verkehr zu protokollieren. Da die Protokolldateien von mehreren Bluetooth -Geräten umgeben waren, wuchsen sie schnell, obwohl dies kein großes Problem war. Zum Glück wurden die Protokolle als .pklg -Datei ausgegeben, sodass es einfach ist, die entsprechenden Pakete in Wireshark zu filtern.
Mit dem Paketfilter bluetooth.src == B8:92:1D:00:3F:61 konnte ich die rohen Pakete sehen, die die iOS -App an den Radardetektor sendete. Ich nahm ein paar Beispielaufnahmen der Kommunikation zwischen meinem Telefon und dem Radardetektor, von denen einige Warnungen generiert wurden, und einige ohne.
Die Bluetooth -Daten werden über das RFCOMM -Protokoll übertragen. Wenn sich die Geräte zum ersten Mal verbinden, senden sie einige Informationen hin und her und synchronisieren wahrscheinlich nur Einstellungen (dazu später mehr). Danach folgen die beiden Geräte einem vorhersehbaren Muster zwischeneinander. Der Radardetektor sendet ein RFCOMM -Paket in regelmäßigen 1/2 Sekunden -Intervallen über Bluetooth. Mit einiger Zeit und Geduld konnte ich die vom Radardetektor zum iPhone gesendete Nutzlaststruktur entschlüsseln.
Nutzlaststruktur: Radardetektor → iPhone
| Artikel | Wert (Hex) | Größe |
|---|---|---|
| Präambel | 55 | 1 Byte |
| Nutzlastgröße | xx xx | 2 Bytes |
| Aktion | xx | 1 Byte |
| Reserviert | 00 | 1 Byte |
| SEQ | xx | 1 Byte |
| Reserviert | xx xx xx xx xx xx | 6 Bytes |
| Alarm | xx | 1 Byte |
| Alarmtyp | xx | 1 Byte |
| ... | ... | ... |
Wenn der Radardetektor ausgeführt wird, sendet er Pakete im obigen Format. Obwohl Computernetzwerk nicht mein Fachgebiet ist, werde ich versuchen, so gut wie möglich zu erklären.
Das vorgeschriebene Präambel -Byte wird immer mit dem Wert 0x55 gesendet. Dies gibt an, dass es sich um den Beginn einer neuen Nutzlastnachricht vom Gerät handelt, anstatt von einem früheren Paket fortzufahren. Anschließend ist ein 2-Byte-Wert, der die Größe des Restes der Nachricht enthält (alles nach den ersten 3 Bytes). Der Aktionswert gibt die Art der Informationen an, die das Paket sendet.
In der SEQ -Nummer werden die Dinge interessant. Wenn Sie eine Klasse über Networking besucht haben oder ein bisschen über TCP wissen, wissen Sie wahrscheinlich bereits, wofür es ist. Der Radardetektor sendet einen 1-Byte-Wert an das iPhone, und die iOS-Anwendung muss mit einer ACK-Anzahl von gleichem Wert antworten. Andernfalls wird der Radardetektor erkennen, dass etwas schief ist und sich selbst trennen.
Das Alert -Byte gibt an, ob ein Alarm ausgelöst wird. In diesem Fall ist es Wert von Wert 0x41 und das folgende Byte wird verwendet, um die Art des Alarms zu senden, der gesendet wird. Ich konnte nicht zu viel über die Werte herausfinden, da ich keine echte Radarpistole besitze. Ein Mann auf Instructables machte jedoch einen Lidar -Waffensimulator mit einem Arduino. Das half sehr bei der Analyse der Pakete.
Um die iOS -App zu erhalten, um die Verbindung zum Gerät zu verwalten, muss eine Antwort im richtigen Format gesendet werden. Zum Glück ist die Antwort auf den Radardetektor viel einfacher und beträgt nur 9 Bytes.
Antwort: iPhone → Radardetektor
| Artikel | Wert (Hex) | Größe |
|---|---|---|
| Präambel | 55 | 1 Byte |
| Nutzlastgröße | xx xx | 2 Bytes |
| Aktion | 02 | 1 Byte |
| Reserviert | 00 | 1 Byte |
| Ack | xx | 1 Byte |
| Reserviert | 00 42 | 2 Bytes |
| Schalter | xx | 1 Byte |
Wie bereits erwähnt, muss der ACK -Wert der gleiche Wert haben wie der zuvor empfangene SEQ -Wert, andernfalls wird die Verbindung nicht verbunden. Das war leicht genug. Einige andere Protokolle haben möglicherweise weniger offensichtliche Methoden zur Kundenprüfung. Zum Glück war dies nicht der Fall. Interessanterweise gibt es eine andere counter , die verwendet wird. Ich habe nie wirklich herausgefunden, wofür das Byte ist, aber es verringert sich für jede Reaktion auf das Gerät um 1. Beide Werte waren leicht genug, um in ein Python -Skript zu codern, und nahm überhaupt nicht zu viel Arbeit an.
Wie ich bereits erwähnt habe, werden einige Einstellungen und Daten hin und her synchronisiert, wenn die iOS -App zum ersten Mal mit dem Radardetektor hergestellt wird. Es war nicht wirklich eine Priorität von mir, diese Pakete herauszufinden und abzubauen, und ich wollte nicht zu viel Zeit damit verbringen. Ich habe das gesamte Paketprotokoll in Wireshark als XML -Datei (data.xml) exportiert und dann ein Python -Skript (Parsedata.py) verwendet, um die Informationen für die spätere Verwendung zu verarbeiten und zu speichern.
Beim Laden öffnet Radar.py die vorverarbeiteten Daten in der Datei packetData.dat. Anschließend wird nach Bluetooth für den Radardetektor gesetzt und versucht, sich daran zu verbinden. Sobald der Radardetektor angeschlossen ist, sendet er einige Datenpakete an das angeschlossene Gerät. Zum Glück sind sie jedes Mal genau die gleichen Pakete in derselben Reihenfolge. Das Python -Skript wird die Daten aus der PaketData.dat -Datei für das von es empfangene Paket durchsucht. Sobald das Haupt-Python-Skript ein Maching-Paket gefunden hat, sendet es die entsprechende zuvor aufgezeichnete Antwort an den Radardetektor.
Überraschenderweise hat es gut geklappt. Ich würde mir jedoch vorstellen, dass ich die Datendatei aktualisieren müsste, wenn ich Einstellungen in der iOS -App geändert habe. Es war kein allzu großes Problem, da ich das Gerät nur einmal konfigurieren müsste und die App wahrscheinlich nie wieder verwenden.
Angesichts aller Informationen, die ich herausgefunden habe, konnte ich ein Python -Skript schreiben, das die Verbindung des iPhone emuliert. Wenn ein Paket nicht in der Datenbank mit aufgezeichneten Antworten gefunden wird, erstellt es ein Antwortpaket mit der zuvor beschriebenen Struktur.
Rückblickend war es ein wirklich lustiges Projekt, mit dem ich nie wirklich Erfahrung hatte. Als Informatik-Major war es interessant, etwas mit Hardware zu tun, das einmal mehr oder weniger außergewöhnlich ist.
Brandon Asuncion // [email protected]
Alle Kommentare/Feedback werden geschätzt!
