Die Cockpituhr eines Renault Latitude aus dem Jahr 2014 ging genau eine Stunde nach, und wie gründlich der Besitzer die Menüs auch durchsuchte: Es gab schlicht keinen Weg, die Uhrzeit zu korrigieren. Was ihn daran hinderte, war kein mechanischer Defekt, sondern ein Tausende Kilometer entfernter Kartenserver, den der Hersteller längst abgeschaltet hatte.
Das verbaute Infotainmentsystem „Carminat LIVE“ stammte vom Zulieferer TomTom. Beim Kauf des Wagens hatte der Vorbesitzer noch gefragt, ob er die Navigations-SD-Karte mitnehmen wolle, und hinzugefügt: „In diesem Auto braucht man sie sogar, um die Uhrzeit einzustellen.“ Der neue Besitzer glaubte es nicht, hielt das alte Kartenmaterial ohnehin für überflüssig und lehnte ab; die Karte landete im Müll. Später sollte er feststellen, dass jedes einzelne Wort des Vorbesitzers wahr war.
Die Borduhr eines Autos, abhängig von einer Speicherkarte. Diese Architektur degradierte das physische Hardware-Eigentum des Halters zu einem temporären Mietverhältnis, das an externe Clouddienste gekoppelt war. Nachdem die Server endgültig offline gegangen waren, blieb dem Besitzer nur eine Option: den rettenden Software-Patch selbst zu schreiben.
Zeiteinstellung erfordert den Rückkauf einer veralteten SD-Karte
Im Renault Latitude wird das Display der Mittelkonsole von einer Plattform namens beaumont gesteuert. Als Hardware dient ein Samsung S5P6440 SoC, auf dem ein angepasstes TomTom-System mit Linux-Kernel 2.6.28.10 läuft.
Der zentrale Interaktionsprozess des Systems ist PNDNavigator. Weder Renault noch TomTom hatten für das Fahrzeug ein eigenständiges Systemmenü implementiert: Grundlegende Einstellungen für Uhrzeit, Systemsprache und Displayhelligkeit wurden vollständig in die UI-Definitionen von PNDNavigator gepackt. Diese UI-Definitionen wiederum wurden dynamisch von der externen SD-Karte eingelesen. Fehlt die Karte, weiß das Infotainmentsystem nicht einmal, wie die Einstellungsmaske gestartet werden soll.
Abbildung: Großflächige Fehlermeldung auf Estnisch „No maps found!“ auf dem Infotainment-Display – die SD-Karte steuert weit mehr als reine Kartendaten. Quelle: blog.nns.ee
Der Besitzer verbrachte eine volle Stunde damit, sämtliche Menüebenen zu durchforsten – die Option „Uhrzeit einstellen“ blieb unauffindbar. Der reguläre Ausweg bestand im Neukauf einer Ersatzkarte: Auf Restposten- und Gebrauchtmärkten existieren noch Exemplare, doch mit Versand nach Estland beliefen sich die Kosten auf rund 60 Euro. Nicht bereit, 60 Euro für das einfache Einstellen einer Uhr auszugeben, beschloss er, sich die Systemkontrolle auf eigene Faust zurückzuholen.
Fahrzeughersteller degradieren Basiseinstellungen zum Navigationsanhängsel
Vor über einem Jahrzehnt erfasste die erste Welle der Fahrzeugvernetzung die Automobilbranche. Die Hersteller wollten mit intelligenten Cockpits werben, verfügten jedoch über keinerlei interne Softwarekompetenz für Infotainmentsysteme. Folglich wurde die gesamte Bordelektronik an den Navigationsspezialisten TomTom ausgelagert. Unter hohem Termindruck portierte das externe Entwicklerteam die Firmware tragbarer Navigationsgeräte (PND) kurzerhand eins zu eins ins Auto: Beim Hochfahren startete stets zuerst die Navigationsanwendung, und alle grundlegenden Fahrzeugeinstellungen wurden darunter angehängt. Weil elementare Fahrzeugeinstellungen direkt mit dem Navigationsdienst verknüpft waren, verfiel die Uhrenfunktion mit dem Auslaufen der Kartendienste. Zurück blieben Besitzer mechanisch einwandfreier Fahrzeuge, die nicht einmal die Sommerzeit umschalten konnten.
Hardware-Bindung und noexec: Mehrstufige Abwehrmauern gegen den Besitzer
Der naheliegendste Rettungsversuch bestand darin, eine handelsübliche SD-Karte zu kaufen und ein eigenes Skript darauf abzulegen. Doch das System hielt gleich mehrere Verteidigungslinien bereit.
Die erste Hürde war die hardwareseitige Bindung. Das DRM-System von TomTom gleicht die CID (Card Identification) – eine unveränderliche, ab Werk im Controller eingebrannte Seriennummer – sowie die kryptografischen Signaturen der Kartendateien ab. Eine herkömmliche, leere Speicherkarte wurde bereits im ersten Schritt abgewiesen.
Die zweite Hürde lag in den Einhängungsrichtlinien des Betriebssystems: Selbst wenn eine gültige CID emuliert werden konnte, mountete das System externe Speichermedien strikt mit der Option noexec. Skripte und Binärdateien auf der Karte durften unter keinen Umständen ausgeführt werden. Sicherheitsmechanismen, die einst gegen Raubkopien von Straßenkarten entwickelt wurden, sperrten letztlich den rechtmäßigen Besitzer aus, der sein eigenes Fahrzeug reparieren wollte.
Ein gezielter Absturz durchbricht die Ausführungssperre
Der Besitzer, Rasmus Moorats, extrahierte die Firmware direkt aus dem Gerät, emulierte den S5P6440-Prozessor mittels QEMU auf seinem PC und begann mit der Disassemblierung. Er analysierte schrittweise die Binärdatei ttn, die für das Parsen von master.script zuständig ist, und dokumentierte das interne Befehlsprotokoll SHEX: Dieses akzeptiert lediglich ein einzelnes, durch Leerzeichen getrenntes Argument und übergibt es an launchserver, welcher den Aufruf über execve ausführt – ein Pfad, der durch noexec wirkungsvoll blockiert war.
Der entscheidende Durchbruch gelang über den Core-Dump-Mechanismus des Linux-Kernels. Linux gestattet es, über /proc/sys/kernel/core_pattern eine Pipe für die Erfassung von Prozessabstürzen zu definieren. Die Unterstützung von Befehlszeilenparametern in dieser Direktive wurde mit Kernel 2.6.24 eingeführt; da im Fahrzeug Kernel 2.6.28 lief, konnte core_pattern noch direkt aus dem Userspace modifiziert werden. Moorats wählte einen Prozess, der garantiert abstürzt: /bin/dbus-monitor wirft einen SIGABRT-Fehler, sobald keine Verbindung zum D-Bus-Systembus hergestellt werden kann. Da der Kernel den in core_pattern hinterlegten Befehl mit uneingeschränkten Root-Rechten ausführt, greift die noexec-Beschränkung des Dateisystems an dieser Stelle nicht.
Abbildung: Das Infotainment-Display bestätigt die Ausführung von master.script; das eigene Skript lief anschließend trotz noexec erfolgreich auf der realen Hardware. Quelle: blog.nns.ee
Das Ergebnis war ein Infotainmentsystem, auf dem eigene Skripte mit vollen Root-Rechten ausgeführt werden konnten, wodurch die vollständige Einstellbarkeit von Uhrzeit und Zeitzone wiederhergestellt wurde.
Wenn der Herstellercode nicht mehr gewartet wird
Nachdem sich die Nachricht über den erfolgreichen Root-Zugriff verbreitet hatte, begannen weitere Fahrzeugbesitzer in der Community, den Exploit zu reproduzieren. Im TomTom-Forum bestätigten Nutzer, dass derselbe Ablauf auch auf der Firmwareversion Carminat TomTom 8.843 einwandfrei funktioniert. Forumsbeiträge deckten zudem ein bemerkenswertes Detail auf: Das GPS-Navigationssystem fällt ohne Karte keineswegs komplett aus, lediglich die Anzeige und Synchronisation der Uhrzeit war betroffen. Der eigentliche Reparaturbedarf beschränkte sich auf die Satelliten-Ephemeridendateien (packedephemeris.ee, ee_meta.tlv, ee_meta.txt). Ersetzt man diese durch frische Offline-Ephemeridendaten, arbeiten Satellitenortung und Zeitsynchronisation wieder wie am ersten Tag.
Wer ein komplettes Fahrzeug für viel Geld erworben hat, muss auf Hacker-Methoden zurückgreifen, um grundlegende Cockpit-Funktionen instand zu halten. Wenn Autobauer Hardware-Funktionen an externe Clouddienste verpfänden, bleibt dem Käufer lediglich ein temporäres Nutzungsrecht. Server werden abgeschaltet, Codebasen verwaist – die Freischaltung der vollständigen Systemkontrolle ist für solche Geräte der einzige Weg, die Lebensdauer ihrer Hersteller zu überdauern.
Weiterführende Links:
- blog.nns.ee: Jailbreaking my car’s navigation system just so I can change the time
- Offizieller Diskussionsstrang der TomTom-Community (Carminat TomTom 8.843)
- Diskussion in der Lobsters-Tech-Community
