Insights Blog Bug Hunting auf der Autobahn — So ...

Bug Hunting auf der Autobahn — So fuzzst du das Car-Infotainment-System

Verfasst von Behnam Yazdanpanah
Agenda

Dieser Beitrag wurde aus dem Englischen übersetzt. Zum Originalbeitrag.

DIY Car Hacking: Wir bauen einen USB-Fuzzer für reale Schwachstellen

Hast du dich jemals gefragt, was passiert, wenn das Autoradio versucht, eine beschädigte Audiodatei abzuspielen? In den meisten Fällen wird der Track einfach übersprungen – und nichts weiter passiert. Gelegentlich friert jedoch das gesamte Infotainment-System ein oder startet neu.

Moderne Fahrzeuge sind im Grunde komplexe Computersysteme auf Rädern – und wie jede Software enthalten auch sie Fehler. Inspiriert durch Forschungsergebnisse von der DEFCON 31 haben wir einen eigenen einfachen Fuzzer auf Basis eines Raspberry Pi entwickelt, um solche Schwachstellen automatisiert aufzuspüren.

In diesem Artikel zeigen wir, wie das funktioniert – und wie du selbst ein entsprechendes Setup aufbauen kannst.

 

Teil 1: Das „Warum“ — Was ist Fuzzing und warum das Autoradio?

Black-Box-Fuzzing: Grundprinzip

  • Wir behandeln das Infotainment-System (IVI) des Fahrzeugs als Black Box. Das heißt: Wir haben keinen Zugriff auf den Quellcode, wissen aber, welche Eingaben das System erwartet – nämlich Audio- und Videodateien von einem USB-Stick.
  • Fuzzing bedeutet, ein System gezielt mit unerwarteten oder manipulierten Eingabedaten zu füttern, um sein Verhalten zu analysieren. In unserem Fall injizieren wir fehlerhafte oder „verrauschte“ Daten (z. B. beschädigte MP3-Dateien), um zu beobachten, ob das System fehlerhaft reagiert oder abstürzt.
Zielsystem: Der Media Player
  • Warum der Media Player? Ganz einfach: Er ist ein ideales Angriffsziel.
    Media Player enthalten komplexe Parser, die zahlreiche Dateiformate verarbeiten müssen (MP3, WAV, AAC usw.).
  • Schon ein einzelnes manipuliertes Bit im Header einer Datei kann ausreichen, um das System zum Absturz zu bringen oder einfrieren zu lassen. Genau hier setzen wir an.

Zielsetzung: Reproduzierbare Bugs finden

Unser Ziel ist es nicht, das System unbrauchbar zu machen („Bricking“). Stattdessen suchen wir nach reproduzierbaren Softwarefehlern.

Wenn wir eine bestimmte manipulierte Datei identifizieren, die zuverlässig einen Crash auslöst, können wir diesen Fehler an den Hersteller melden. So können Patches entwickelt werden, die die Sicherheit und Robustheit des Systems verbessern.

Teil 2: Das „Wie“ — Ein Blick ins Gehirn des Fuzzers

Das Herzstück: Ein Python-Skript

Der gesamte Prozess wird durch ein Python-Skript automatisiert. Dieses läuft kontinuierlich – über Stunden oder sogar Tage – und erzeugt systematisch Tausende von Testfällen.

Der Fuzzing-Loop im Detail

1. Mutation

Das Skript startet mit einer gültigen „Seed-Datei“ (z. B. test.mp3) und verändert diese mithilfe des Tools Radamsa. Jede Iteration erzeugt neue, zufällig modifizierte Varianten der Datei. Zusätzlich wird dem virtuellen USB-Laufwerk in jeder Runde ein zufälliger Name zugewiesen.

2. Setup

Der Raspberry Pi mountet ein virtuelles Disk-Image, löscht alte Inhalte, kopiert die neu erzeugten Dateien hinein und schreibt das neue Volume-Label in den Bootsektor.

3. Emulation (USB-Gerät vortäuschen)

Hier passiert die eigentliche Magie:
Das Skript nutzt das Linux-Feature USB Gadget Mode (genauer: das Modul g_mass_storage), sodass sich der Raspberry Pi gegenüber dem Fahrzeug als USB-Massenspeichergerät ausgibt. [linuxlink....imesys.com]
Für das Infotainment-System sieht der Pi damit aus wie ein gewöhnlicher USB-Stick – obwohl im Hintergrund ein komplexes Fuzzing-System läuft.

4. Monitoring (Crash-Erkennung)

Der Fuzzer überwacht kontinuierlich, ob ein Absturz auftritt:

Kernel-Log-Monitoring (dmesg)
Wenn das Infotainment-System neu startet, wird die USB-Verbindung kurz getrennt und wiederhergestellt. Dieser Reconnect wird als schwerwiegender Fehler gewertet.

Prozess-Monitoring via ADB (optional)
Bei Android-basierten Systemen kann zusätzlich ADB genutzt werden. Dabei wird die Process-ID (PID) zentraler Media-Prozesse überwacht. Ändert sich die PID oder verschwindet der Prozess, wurde ein Crash auf Anwendungsebene ausgelöst. [linuxvox.com]

The Baseline Kernel Message Monitoring (dmesg): The fuzzer constantly checks kernel messages. If the car's entire infotainment system reboots, the USB device will momentarily disconnect and reconnect. The fuzzer sees this new connection and flags it as a high-severity crash. This method works on any system and does not require an ADB connection.

Diese Methode ermöglicht eine deutlich feinere Analyse – selbst wenn das Gesamtsystem nicht rebootet.

5. Logging & Automatisierung

Wird ein Crash erkannt, speichert das System automatisch:

  • alle betroffenen mutierten Dateien

  • das verwendete Volume-Label

  • einen Crash-Report mit Ursache (z. B. „Reboot erkannt“ oder „Media-Prozess abgestürzt“)

Alle Daten werden strukturiert abgelegt, sodass der Fehler reproduzierbar bleibt. Anschließend startet der nächste Testlauf automatisch.

1-2


Teil 3: Aufbau des Fuzzing-Labors

Benötigte Hardware

  • Fuzzer-Host: Raspberry Pi 4

    (kostengünstig, Linux-basiert, unterstützt USB-OTG – Voraussetzung für Gadget Mode)

  • Zielsystem: Infotainment-System des Fahrzeugs (mit USB-Port)

  • Kabel: USB-C auf USB-A (für Verbindung Pi ↔ Fahrzeug)
    Idealerweise separate Stromversorgung für den Pi

  • Optional:
    Zweite Verbindung für ADB (z. B. via USB-Ethernet oder zusätzlichen USB-Port)

Software-Setup

1. Raspberry Pi OS installieren: Frische, aktuelle Installation

2. Abhängigkeiten installieren:

sudo apt-get install dosfstools android-sdk-platform-tools (For formatting the disk image and using ADB).

3. Radamsa installieren

$ git clone https://gitlab.com/akihe/radamsa.git 
$ cd radamsa 
$ make 
$ sudo make install # optional, you can also just grab bin/radamsa 
$ radamsa --help

4. Virtuelles USB-Disk-Image erstellen:

  1. dd if=/dev/zero of=pi_usb.img bs=1M count=512 for a 512MB drive).

  2. mkfs.vfat pi_usb.img.

5. Seed-Dateien vorbereiten

Erstelle ein Verzeichnis seed_files mit validen, kleinen MP3- oder WAV-Dateien als Ausgangsbasis.

6. Gadget Mode aktivieren

Konfiguration des Kernel-Moduls g_mass_storage mit dem Disk-Image als Backend.

7. ADB im Fahrzeug aktivieren (optional)

Wie bei Android üblich:

  • „Build-Nummer“ mehrfach antippen

  • Entwickleroptionen aktivieren

  • USB-Debugging einschalten

Fazit: Alles zusammenführen

Sobald Hardware und Software eingerichtet sind, übernimmt das Python-Skript den Rest:

  • Generierung mutierter Dateien

  • Präsentation als USB-Gerät

  • Überwachung auf Abstürze

  • Automatische Protokollierung

Das System arbeitet vollständig automatisiert und kann rund um die Uhr laufen, um systematisch Schwachstellen im Infotainment-System zu identifizieren.

Download Fuzzer