# ADB (Android Debug Bridge)

> 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.

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.

Source: https://auto-st.com/de/glossar/adb · Updated: 2026-10-07

## 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

**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.

## Sources

- [Android Developers: Android Debug Bridge (adb)](https://developer.android.com/tools/adb)
- [Android Open Source Project: Security-Enhanced Linux in Android](https://source.android.com/docs/security/features/selinux)
- [Android Open Source Project: Android Automotive](https://source.android.com/docs/automotive)

## Related

- [Android Automotive OS (AAOS)](https://auto-st.com/de/glossar/android-automotive)
- [IVI (In-Vehicle Infotainment)](https://auto-st.com/de/glossar/ivi)
- [Android-IVI-Security-Checks, die jede Head Unit bestehen sollte](https://auto-st.com/de/insights/android-ivi-security-checks)
- [Der Bildschirm ist auch eine Angriffsfläche.](https://auto-st.com/de/ivi-security-test)
- [Automatisierter ECU-Security-Test vs. manueller Penetrationstest](https://auto-st.com/de/vergleich/automatisierter-ecu-test-vs-manueller-pentest)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/glossar/adb