Zum Inhalt springen
AutoST by Zyberum GmbH
Menü
GlossarInfotainmentAndroid

ADB (Android Debug Bridge)

ADB ist die Android-Debug-Schnittstelle über USB oder TCP-Port 5555. Warum du sie an einer Android-Head-Unit zuerst prüfst und was ein offenes ADB einem Angreifer gibt.

Aktualisiert Diese Seite als Markdown

Kurz gesagt

ADB (Android Debug Bridge) ist die Debug-Schnittstelle von Android für die Kommandozeile: ein Client auf dem PC, ein Server auf Port 5037 und der adbd-Daemon auf dem Gerät, erreichbar über USB oder TCP, meist Port 5555. Damit installierst du Apps, öffnest eine Shell, ziehst Dateien und liest Logs. Auf einer Infotainment-Head-Unit ist ein aktiviertes, nicht authentifiziertes oder als Root laufendes ADB einer der direktesten Zugänge, und zugleich die Schnittstelle, über die ein Security-Tester die Unit prüft.

Was ist ADB?

ADB, die Android Debug Bridge, ist die Entwicklerschnittstelle von Android und besteht aus drei Teilen: dem adb-Client auf dem Entwicklerrechner, einem Server auf demselben Rechner auf TCP-Port 5037 und dem adbd-Daemon auf dem Gerät. Die Verbindung läuft über USB oder über TCP/IP, dort lauscht adbd standardmäßig auf Port 5555.

Über ADB kann ein Host eine Shell öffnen (adb shell), Apps installieren und entfernen, Dateien auf das Gerät und herunter kopieren (adb push, adb pull), Logs lesen (adb logcat), System-Properties abfragen (getprop) und Pakete untersuchen (pm list packages, dumpsys package). Auf einem debuggable Build startet adb root den adbd mit Root-Rechten neu.

Wo ist es definiert?

ADB definiert Google in der Android-Entwicklerdokumentation und im AOSP-Quellcode; eine ISO- oder SAE-Norm dafür gibt es nicht. Die Sicherheit hängt an Build-Properties: ro.debuggable entscheidet, ob Root und App-Debugging erlaubt sind, ro.adb.secure schaltet die RSA-Autorisierung der Hosts ein, und ro.build.type (user, userdebug, eng) setzt die Voreinstellungen. SELinux begrenzt, was der Shell-User erreicht, auch wenn ADB offen ist.

Was es in der Praxis bedeutet

Auf einem Smartphone liegt ADB hinter den Entwickleroptionen und einem Bestätigungsdialog. Auf Infotainment-Units sieht es oft anders aus. Wir sehen regelmäßig Head Units, bei denen adbd in Serien-Builds auf Ethernet oder WLAN lauscht, bei denen ein USB-Port im Innenraum ADB ohne Autorisierung anbietet oder deren Build userdebug ist, sodass adb root einfach funktioniert. Mit einer Shell folgen die nächsten Findings schnell: für alle lesbare System-Properties, die interne Endpunkte und Konfiguration zeigen, debuggable Apps, die per run-as Zugriff auf ihre Daten geben, exportierte Komponenten, die privilegierte Aktionen starten, und Dateien mit Zugangsdaten, die sich herunterziehen lassen.

Ein typischer erster Check am Prüfstand sind drei Befehle: adb devices, adb shell getprop ro.build.type und adb shell getenforce. Die Antworten zeigen dir in Sekunden, wie viel Härtung du erwarten kannst.

Wie AutoST es testet

AutoST nutzt ADB als Transport zu Android-Head-Units und Emulatoren. Über diese Verbindung listet es Pakete, vergebene Berechtigungen, exportierte Komponenten, herunterladbare Dateien und den SELinux-Status auf, analysiert die APKs statisch und streamt Logcat während funktionaler Tests. Das Ergebnis sind Härtungs-Findings mit je einer Abhilfe. Dass die ADB-Verbindung auf einem Serien-Build überhaupt klappt, ist oft schon das erste Finding.

Häufige Missverständnisse

Entwickleroptionen in der Oberfläche abzuschalten stoppt adbd nicht, wenn ein Hersteller-Skript den Daemon auf der Netzwerkschnittstelle startet. Und ADB ist nicht nur ein Komfort für Entwickler: Für einen Angreifer im Innenraum oder im selben Netz ist es eine Remote-Shell.

FAQ

Häufig gestellte Fragen

Sollte ADB auf einer Serien-Head-Unit abgeschaltet sein?

Ja, oder zumindest hinter einem Service-Modus mit Authentifizierung liegen. Ein Serien-Build sollte ro.debuggable=0 haben, kein adbd im Netzwerk lauschen lassen und keinen Weg bieten, die Entwickleroptionen über die normale Oberfläche einzuschalten.

Ist ADB über USB sicherer als ADB über TCP?

Es braucht physischen Zugang, das hilft, aber USB-Ports im Fahrzeug erreicht jeder im Innenraum. ADB über TCP auf Port 5555 ist schlimmer, wenn die Head Unit ein Netz mit Hotspot-Clients oder anderen Steuergeräten teilt, denn dann ist es aus der Ferne erreichbar.

Wogegen schützt die RSA-Autorisierung?

Mit ro.adb.secure=1 akzeptiert das Gerät nur Hosts, deren Public Key es autorisiert hat. Auf einer Head Unit ohne Bestätigungsdialog oder mit vorinstalliertem Key ist dieser Schutz schwächer, als er aussieht.

Quellen

Passende Seiten

Sieh es auf deinem ECU

Ein Begriff, der für dein Steuergerät zählt?

In 15 Minuten sagen wir dir, wie AutoST ihn testet, wie ein Finding aussieht und was er für deinen ISO/SAE-21434-Nachweis bedeutet.

  • Direkte Antwort von einem ECU-Security-Engineer
  • Welcher Test den Begriff abdeckt
  • Kostenlos und unverbindlich
Tom Zaubermann

Deine Demo ist mitTom ZaubermannGründer von Zyberum, früher Leiter des VW InCar Security Testing Lab

Bereits im Einsatz bei Tier-1-, Tier-2-Zulieferern und OEMs. Referenzen auf Anfrage.

Ruf uns an: +49 176 439 17074automotive@zyberum.com

Oder schreib uns eine Nachricht

Wir antworten innerhalb eines Werktags.

Ruf uns anAutoST-Team fragen

Wähle einen Termin, der dir passt

In neuem Tab öffnen