# ADB (Android Debug Bridge)

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

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.

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

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

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

- [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/glossary/android-automotive)
- [IVI (In-Vehicle Infotainment)](https://auto-st.com/glossary/ivi)
- [Android IVI security checks every head unit should pass](https://auto-st.com/insights/android-ivi-security-checks)
- [The screen is an attack surface too.](https://auto-st.com/ivi-security-testing)
- [Automated ECU Security Testing vs Manual Penetration Test](https://auto-st.com/compare/automated-ecu-testing-vs-manual-pentest)

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