Die MCU fungiert als Vermittler zwischen dem CAN-Bus-System deines Fahrzeugs und deinem Android-Headunit. Sie fängt Fahrzeugdaten ab, filtert sie und übersetzt sie, bevor sie an Android weitergeleitet werden.

Leider gibt es keinen universellen Standard für die MCU-Kommunikation. Jeder MCU-Hersteller kann sein eigenes Protokoll und Paketformat definieren. Dadurch kann derselbe Tastendruck je nach MCU-Hersteller durch völlig unterschiedliche Byte-Sequenzen dargestellt werden.

Diese Anwendung ermöglicht es dir, die rohen Byte-Streams zu untersuchen, die zwischen der MCU und Android ausgetauscht werden. Obwohl die genaue Struktur je nach Hersteller variiert, folgen viele MCUs einem ähnlichen paketbasierten Format, das typischerweise besteht aus:

• einem Header- oder Start-Byte
• einem Identifikationsbyte
• einem Längenbyte
• einem oder mehreren Datenbytes
• einem Prüfsummenbyte

Ein typisches Paket könnte so aussehen:

0x2D, 0x22, 0x02, 0x84, 0x01, 0x56

Diese Sequenz lässt sich wie folgt aufschlüsseln:

Byte	Beschreibung
0x2D	Header- oder Start-Byte
0x22	Identifikator für ein Tastenereignis
0x02	Länge der folgenden Nutzdaten
0x84	Tastenkennung
0x01	Tastenstatus oder Ereignistyp
0x56	Prüfsumme

In diesem Beispiel scheint 0x2D den Beginn eines neuen Pakets zu markieren. Der Identifikator 0x22 wird wahrscheinlich verwendet, um Tastenereignisse zu kennzeichnen. Das Längenbyte 0x02 gibt an, dass die nächsten zwei Bytes die eigentlichen Nutzdaten enthalten.

Das erste Nutzdatenbyte, 0x84, identifiziert höchstwahrscheinlich die spezifische Taste, die gedrückt wurde. Das zweite Nutzdatenbyte, 0x01, kann ein „Taste gedrückt“-Ereignis darstellen. Diese Annahme lässt sich oft bestätigen, indem man ein zweites Paket beobachtet, das beim Loslassen der Taste gesendet wird, bei dem dieselbe Sequenz erscheint, jedoch mit dem Wert 0x00.

Das letzte Byte, 0x56, ist wahrscheinlich eine Prüfsumme, die von der MCU verwendet wird, um die Integrität des Pakets zu überprüfen. Ein Hinweis darauf ist, dass das nächste Byte im Stream ein neues Paket mit einem weiteren 0x2D-Header beginnt, was darauf hindeutet, dass 0x56 das Ende des aktuellen Pakets markiert.

---

Unterschiedliche MCU-Hersteller verwenden unterschiedliche Formate

Nicht jede MCU folgt genau dieser Struktur.

Zum Beispiel verwenden viele KSW-basierte Systeme ein Paketlayout ähnlich wie:

Header, Update, Identifikator, Länge, Daten, Prüfsumme

Andere MCU-Hersteller wählen völlig andere Ansätze. Manche Pakete enthalten gar keine Prüfsumme. Andere verzichten auf ein dediziertes Header-Byte oder verwenden Pakete mit fester Länge, sodass ein Längenfeld nicht notwendig ist.

---

Erkennen von Paketstrukturen

Beim Reverse Engineering eines unbekannten MCU-Protokolls ist Wiederholung dein wichtigster Hinweis.

Achte auf:

• Bytes, die konsistent am Anfang von Nachrichten erscheinen
• Bytes, die sich ändern, wenn unterschiedliche Tasten gedrückt werden
• Bytes, die unabhängig von der gedrückten Taste konstant bleiben
• Werte, die sich bei Drehreglern oder Scrollrädern erhöhen oder verringern
• ähnliche Pakete, die sich nur durch ein einzelnes Byte unterscheiden (Taste gedrückt vs. losgelassen)
• wiederkehrende Muster, die auf ein Längenfeld oder eine Prüfsumme hindeuten

Durch das Beobachten dieser Muster über mehrere Tastendrücke und Fahrzeugaktionen hinweg kannst du schrittweise die Struktur des Protokolls bestimmen und herausfinden, welche Bytes für das Remapping relevant sind.

Dabei gilt: Es ist selten notwendig, jedes einzelne Byte vollständig zu verstehen. In den meisten Fällen reicht es aus, die Bytes zu identifizieren, die eindeutig das gewünschte Tastenereignis darstellen, um zuverlässige Zuordnungen zu erstellen.