Android IVI security checks every head unit should pass

An Android infotainment unit is a phone-class device wired to a car, and most of its security comes down to configuration: the build type, the debug switches, what ADB exposes, whether SELinux enforces, and which app components are open to other apps. These checks are quick, they need no exploit, and they find a large share of what we report on head units: ADB enabled on builds that should not have it, debuggable apps, components exported without a permission and system properties readable by everyone. This guide lists the checks, the value you want to see and what a deviation means.

Build and platform flags

Start with the system properties. They tell you in seconds what kind of build is on the unit.

Property	Expected on a production build	Finding if
ro.build.type	user	userdebug or eng
ro.build.tags	release-keys	test-keys (platform signed with public test keys)
ro.debuggable	0	1 (every app debuggable, root shell possible)
ro.secure	1	0
ro.adb.secure	1	0 (ADB without host key confirmation)
ro.build.version.security_patch	recent date	far behind the platform’s current patch level

A query looks like this:

$ getprop ro.build.type
user
$ getprop ro.debuggable
0

A test-keys build deserves special attention: the platform signing keys of the AOSP test set are public, so anything signed with them is trusted as system code.

ADB exposure

ADB is the transport for the checks themselves, which is fine on a bench unit. The question is how it is reachable on the product. Check whether ADB listens on the network (service.adb.tcp.port set, or a listener on TCP port 5555), whether a USB port in the cabin allows a device-mode connection, and whether the developer options can be enabled from the user interface. A finding here means that physical or network proximity is enough for a shell, which changes the attack feasibility rating in the TARA considerably.

SELinux

getenforce should answer Enforcing. Permissive on a production unit means the mandatory access control logs violations but does not stop them, so one weak service is enough to reach the rest of the system. Also look at the domains: vendor services running in an unconfined or overly broad domain are a softer version of the same problem.

Apps and their components

Most head units ship dozens of vendor apps. For each one, check the manifest flags and the exposed components:

• android:debuggable="true" in a production APK: lets a debugger attach and read the app’s memory.
• android:allowBackup="true": app data may be extracted through backup.
• Activities, services, receivers and providers with android:exported="true" and no permission: any app on the unit can start or query them. On an IVI that can mean vehicle settings, diagnostics menus or data from a paired phone.
• usesCleartextTraffic="true": the app may talk HTTP to its backend.
• Dangerous permissions granted to apps that do not need them, and permissions granted to the shell user.

Static analysis of the APKs adds the secrets check: API keys, backend credentials, private keys and hardcoded URLs to internal endpoints in resources or code. A secret in an APK is a secret on every unit in the fleet.

Files and properties

List what an unprivileged shell can read: world-readable files under /data, /sdcard, vendor partitions and logs. Look for VINs, phone contacts, tokens and configuration with credentials. System properties are readable by every app, so a property that carries a token or a URL with credentials is effectively public. Logcat is the third place: debug logging of personal data or keys is common in development builds and sometimes survives into production.

Reading the results

Not every deviation weighs the same. A useful ranking for the report:

1. Platform level: test-keys, ro.debuggable=1, SELinux permissive, ADB reachable without confirmation. These undermine everything else.
2. Exposure: exported components without permissions, network-reachable ADB, secrets in APKs.
3. Hygiene: allowBackup, cleartext traffic, outdated patch level, verbose logging.

For each finding, record the build fingerprint (ro.build.fingerprint), the package version and the exact output. The fingerprint is how a developer knows whether the next build still has the issue.

How AutoST runs these checks

AutoST connects to the head unit or an emulator over ADB and runs the recon automatically: packages, permissions, exported components, pullable files and the SELinux posture, plus static analysis of the APKs for manifest flags and secrets. It can also run functional tests with screenshots and live logcat. Each finding comes with a remediation and lands in the same Fix Plan as the UDS and DoIP findings. The deeper IVI work, such as vendor IPC interfaces, the update path or the bridge to the vehicle bus, remains penetration testing.