Motorrad-Dashboard mit Google Maps: So reverse-engineerte ich die Bluetooth-Schnittstelle

Es klang wie eine praktische Lösung: Ein Motorrad mit Bluetooth-fähigem Armaturenbrett, das per Smartphone mit Navigationsdaten versorgt werden kann. Doch in der Praxis entpuppte sich die Umsetzung als frustrierend. Die Hersteller-App war umständlich, die Navigation lief über einen unbekannten Kartenanbieter, und an Individualisierung war nicht zu denken. Doch statt sich mit den Unzulänglichkeiten abzufinden, stellte sich ein Entwickler eine einfache Frage: Wenn das Motorrad nur über Bluetooth mit dem Handy kommuniziert – wie komplex kann das Protokoll schon sein? Die Antwort fand er nicht in Handbüchern, sondern durch systematisches Reverse Engineering.

Der erste Schritt: Das Unbekannte sichtbar machen

Ohne offizielle Dokumentation blieb nur ein Weg: die Schnittstelle selbst analysieren. Mit einem GATT-Scan – einer Methode, um alle verfügbaren Bluetooth-Dienste und -Charakteristiken eines Geräts zu erkunden – zeigte sich schnell, dass das Armaturenbrett nur über eine einzige herstellerspezifische Schnittstelle verfügte. Diese bestand aus zwei Charakteristiken: einer, an die das Smartphone Daten sendete, und einer, über die das Motorrad Rückmeldungen lieferte. Mehr gab es nicht.

Um die tatsächlichen Datenflüsse zu verstehen, griff der Entwickler auf die HCI-Snoop-Protokollierung von Android zurück. Diese Funktion zeichnet alle Bluetooth-Pakete auf, die zwischen Geräten ausgetauscht werden. Nach dem Pairing von Handy und Motorrad und einer kurzen Testfahrt lagen die Rohdaten vor – doch die Interpretation gestaltete sich als Rätsel. Hexadezimalzahlen ohne Kontext sind schwer zu entschlüsseln, und ohne weitere Hinweise blieb unklar, welche Bytes welche Bedeutung hatten.

Vom kompilierten Code zur lesbaren Anleitung

Der nächste logische Schritt führte zur Hersteller-App selbst. Durch das Extrahieren der APK-Datei und das Decompilieren mit JADX ließ sich der Quellcode der Anwendung in eine annähernd lesbare Form bringen. Überraschenderweise waren viele Klassennamen und Methoden nicht obfuskiert – ein Glücksfall für den Reverse Engineer. Mit diesem Wissen konnte er die im Datenverkehr beobachteten Nachrichten mit dem Code der App abgleichen.

Um die Lücke zwischen Bytefolgen und tatsächlicher Bedeutung zu schließen, setzte der Entwickler auf Frida, ein Tool, das es ermöglicht, laufende Anwendungen zu instrumentieren und Funktionen mit ihren realen Parametern zu überwachen. So ließ sich genau nachvollziehen, wie die App eine Navigationsanweisung wie „Linkskurve in 200 Metern“ in ein 30-Byte-Paket umwandelte und an das Motorrad sendete.

Nach und nach kristallisierte sich das Protokoll heraus: Jede Nachricht bestand aus genau 30 Bytes, strukturiert in einen festen Header, ein ASCII-Zeichen für den Nachrichtentyp, den eigentlichen Inhalt, eine Prüfsumme und ein Terminierungsbyte. Besonders aufschlussreich war die Entdeckung, dass das Motorrad reaktiv arbeitete – es sendete nur Daten, wenn das Smartphone eine Anfrage stellte. Diese Eigenschaft erklärt, warum erste Versuche mit einem passiven Sniffer scheiterten: Das Armaturenbrett blieb stumm, bis die App aktiv wurde.

Fehler als Teil des Prozesses – und wie sie korrigiert wurden

Reverse Engineering ist selten ein linearer Prozess, und falsche Annahmen gehören dazu. Eine der größten Herausforderungen bestand darin, sich selbst nicht zu sehr auf vermeintliche Fakten zu verlassen. Ein Bluetooth-Analyzer hatte zunächst eine bekannte Sicherheits-Spezifikation für digitale Schlüssel als Übereinstimmung identifiziert. Fast wäre diese Fehleinschätzung als Tatsache übernommen worden – doch die tatsächliche UUID des Dienstes passte nicht zu diesem Standard.

Eine weitere Annahme, die sich als falsch erwies, betraf die Hardware des Motorrads. Der Entwickler vermutete, dass das Fahrzeug über eine eingebaute SIM-Karte verfügte und Telemetriedaten an die Cloud des Herstellers sendete. Erst eine Überprüfung der technischen Dokumentation und der verbauten Komponenten zeigte: Das Motorrad kommunizierte ausschließlich über Bluetooth mit dem Smartphone – es gab keine eigenständige Internetverbindung.

Um solche Rückschläge zu dokumentieren und nicht zu wiederholen, führte der Entwickler ein laufendes Logbuch ein. Dort hielt er fest, welche Hypothesen er aufstellte, welche Beweise sie stützten und welche Erkenntnisse sie widerlegten. Dieser disziplinierte Ansatz erwies sich als entscheidend, um den Überblick zu behalten und effizient voranzukommen.

Die eigene App: Integration in Echtzeit

Mit dem ermittelten Protokoll war der Weg frei für eine eigene Lösung. Das Ergebnis ist REDLINE, eine Android-Anwendung, entwickelt in Kotlin und Jetpack Compose. Die App übernimmt gleich mehrere Funktionen:

• Navigationsintegration: Sie fängt die Turn-by-Turn-Anweisungen von Google Maps ab, wandelt sie in das Format des Motorrad-Protokolls um und überträgt sie per Bluetooth. So erscheint die Navigation direkt auf dem Armaturenbrett – ohne die umständliche Hersteller-App.

• Live-Telemetrie: Das Motorrad sendet regelmäßig Daten wie Geschwindigkeit, Drehzahl oder Batteriespannung, die REDLINE in Echtzeit auswertet und als digitale Anzeige aufbereitet.

• Fahrtenaufzeichnung: Jede Tour wird automatisch gespeichert, inklusive Statistiken und Geschwindigkeitsdiagramm. Die Daten lassen sich exportieren und analysieren.

• Zusatzfunktionen: Neben der Navigation zeigt die App auch eine Uhrzeit oder andere Informationen an, wenn keine Navigationsdaten vorliegen.

Die gesamte Anwendung läuft lokal auf dem Smartphone, ohne Cloud-Anbindung oder Benutzerkonto. Mit rund 14.000 Codezeilen und 205 automatisierten Tests ist REDLINE ein robustes Werkzeug. Selbst ein integrierter Frame-Inspector, der ursprünglich zur Protokollanalyse diente, wurde in die App integriert, um auch zukünftige Änderungen am Protokoll schnell erkennen zu können.

Was dieses Projekt über Reverse Engineering lehrt

Am Ende war es nicht das Protokoll selbst, das die größte Herausforderung darstellte, sondern die mentale Disziplin, die nötig war, um systematisch vorzugehen. Reverse Engineering erfordert Demut: Man muss akzeptieren, dass die eigenen Annahmen oft falsch sind, und bereit sein, sie mit harten Fakten zu überprüfen. Diese Herangehensweise übertrug sich später auch auf die reguläre Softwareentwicklung – etwa bei der Fehlersuche, bei der der Fehler fast nie dort zu finden ist, wo man zunächst sucht.

Wer selbst in die Welt des Reverse Engineerings eintauchen möchte, findet auf der Projektseite eine detaillierte Dokumentation der Frame-Formate, der verwendeten Tools und der widerlegten Hypothesen. Dort wird auch erklärt, wie man ähnliche Protokolle analysiert und eine eigene Lösung entwickelt – ganz ohne Herstellerabhängigkeiten.