ADB (Android Debug Bridge)
ADB is the Android debug interface over USB or TCP port 5555. Why it is the first thing to check on an Android head unit, and what an open ADB gives an attacker.
Updated This page as Markdown
In short
ADB (Android Debug Bridge) is the command-line debug interface of Android: a client on the PC, a server on port 5037 and the adbd daemon on the device, reachable over USB or TCP, usually port 5555. It installs apps, opens a shell, pulls files and reads logs. On an infotainment head unit an ADB port that is enabled, unauthenticated or running as root is one of the most direct ways in, and it is also the interface a security tester uses to assess the unit.
What is ADB?
ADB, the Android Debug Bridge, is the developer interface of Android. It has three parts: the adb client on the developer machine, a server on the same machine listening on TCP port 5037, and the adbd daemon on the device. The connection runs over USB or over TCP/IP, where adbd listens on port 5555 by default.
Through ADB a host can open a shell (adb shell), install and remove apps, copy files to and from the device (adb push, adb pull), read logs (adb logcat), query system properties (getprop) and inspect packages (pm list packages, dumpsys package). On a debuggable build, adb root restarts adbd with root privileges.
Where is it defined?
ADB is defined by Google in the Android developer documentation and the AOSP source code; there is no ISO or SAE standard for it. Its security depends on Android build properties: ro.debuggable decides whether root and app debugging are allowed, ro.adb.secure enables RSA key authorization of hosts, and ro.build.type (user, userdebug, eng) sets the defaults. SELinux restricts what the shell user can reach even when ADB is open.
What it means in practice
On a phone, ADB is behind developer options and a confirmation dialog. On infotainment units the picture is often different. We regularly see head units where adbd listens on Ethernet or Wi-Fi in production builds, where a USB port in the cabin offers ADB without authorization, or where the build is userdebug so adb root simply works. With a shell, the next findings come quickly: world-readable system properties that show internal endpoints and configuration, debuggable apps that allow run-as into their data, exported components that start privileged actions, and files with credentials that can be pulled.
A typical first check on the bench is three commands: adb devices, adb shell getprop ro.build.type and adb shell getenforce. The answers tell you within seconds how much hardening to expect.
How AutoST tests it
AutoST uses ADB as its transport to Android head units and emulators. Over that connection it enumerates packages, granted permissions, exported components, pullable files and the SELinux posture, runs static analysis on the APKs and streams logcat during functional tests. The results are hardening findings with a fix each. That the ADB link works at all on a production build is often the first finding.
Common misunderstandings
Disabling developer options in the user interface does not stop adbd if a vendor script starts it on the network interface. And ADB is not only a developer convenience: for an attacker in the cabin or on the same network it is a remote shell.
FAQ
Frequently asked questions
Should ADB be disabled on a production head unit?
Yes, or at least locked behind a service mode that needs authentication. A production build should have ro.debuggable=0, no adbd listening on the network and no way to enable developer options from the normal user interface.
Is ADB over USB safer than ADB over TCP?
It needs physical access, which helps, but USB ports in the vehicle are reachable by anyone in the cabin. ADB over TCP on port 5555 is worse when the head unit shares a network with Wi-Fi hotspot clients or other ECUs, because then it is reachable remotely.
What does RSA authorization protect against?
With ro.adb.secure=1 the device only accepts hosts whose public key it has authorized. On a head unit without a confirmation dialog, or with a pre-installed key, that protection is weaker than it looks.
Sources
Related pages
- GlossaryAndroid Automotive OS (AAOS)Android Automotive OS runs natively on the head unit and talks to the vehicle through the Vehicle HAL. How it differs from Android Auto and what we find on the bench.
- GlossaryIVI (In-Vehicle Infotainment)IVI is the vehicle head unit that runs apps, media and connectivity, often on Android or Linux. Why it is a large attack surface and what hardening checks look for.
- InsightsAndroid IVI security checks every head unit should passHardening checks for an Android head unit: build type, debug flags, ADB exposure, SELinux, exported components, app flags and secrets, and what each means.
- PlatformThe screen is an attack surface too.AutoST checks Android infotainment over ADB: dangerous permissions, exposed components, pullable files, SELinux posture and APK static analysis, with per-finding fixes.
- ComparisonsAutomated ECU Security Testing vs Manual Penetration TestAutomated ECU testing catches repeatable weaknesses on every build; a manual pentest finds logic flaws and chained attacks. What each finds, costs and when to use which.
