Who else is running in your Android: seven adb commands without root and what their output means

After the article on who executes in a phone besides the OS, several people asked me the same thing: how do I look at mine? I collected seven commands that work over a plain adb shell without root on most Qualcomm‑based Android devices, and explained what every line of output means. The whole thing takes about ten minutes if USB debugging is already on.

A caveat first. All outputs below were taken from my Galaxy Tab S6 (Snapdragon 855); the paths for other chips come from public device trees and kernel sources, not from my own testing. On MediaTek, Exynos and Tensor the paths differ, some commands return nothing, and at the end I wrote what to look at there. If a command behaved differently for you, post the model and the output in the comments: let's build a table by device.

What you need: USB debugging enabled, adb on the computer (part of Android platform-tools), a cable. Root is not needed for any command below except one, and I marked it.

adb shell "ls /vendor/firmware_mnt/image /vendor/firmware 2>/dev/null | grep -E '\.(mdt|mbn)$' | sed 's/\..*//' | sort -u"

On my tablet the output is this (comments are mine):

a640_zap      # GPU: signed “zap” shader, without it the GPU won't start
adsp          # audio DSP: its own Hexagon, its own OS
cdsp          # compute DSP: camera, ML
ipa_fws       # IPA: hardware network accelerator between modem and OS
modem         # cellular modem + GNSS + all Wi-Fi logic
slpi          # sensor hub: accelerometer, gyro, step counter
venus         # video codec
wlanmdsp      # WLAN part of the modem firmware

Every line is a separate signed image that the bootloader or the kernel hands to its own processor inside the SoC. On the Tab S6 there are eight. On 8‑series phones usually 10–14: npu, a second cdsp, spss (the secure processor), display and touch firmware get added. The number by itself means little, but it recalibrates the intuition that “the phone runs Android”.

If the directory is empty or inaccessible, try ls /vendor/firmware or ls /odm/firmware; some vendors keep the modem firmware in a separate partition mounted at /vendor/firmware_mnt.

adb shell "cat /sys/class/remoteproc/remoteproc*/name 2>/dev/null; cat /sys/bus/msm_subsys/devices/*/name 2>/dev/null"

4080000.remoteproc-mss    # modem
17300000.remoteproc-adsp
8300000.remoteproc-cdsp
2400000.remoteproc-slpi

These are the co‑processors the kernel manages explicitly: starts, stops, restarts on a crash. The hexadecimal number is the address of the register block in the SoC's memory map. If there are no lines at all, you have an old kernel with a different interface or SELinux closed sysfs; command 1 is enough then.

adb shell getprop gsm.version.baseband && adb shell getprop ro.build.version.security_patch && adb shell getprop ro.vendor.build.security_patch

T865XXU5CVH2          # modem firmware version
2023-10-01            # system (Android) patch level
2023-08-01            # vendor patch level (firmware, drivers)

The first line is the baseband firmware version, which you can check on the vendor's site. The second and third are more interesting. Android shows the system patch level in Settings, but the vendor part (modem, DSPs, drivers) has its own property, and it often lags. On my tablet the gap is two months. In other people's reports on non‑Pixel devices, six months is not unusual. That is the real update lag of the layer neither antivirus nor MDM can see.

If ro.vendor.build.security_patch is empty, look at ro.vendor.build.date or ro.bootimage.build.date.

adb shell "find /proc/device-tree -name 'qcom,smmu-s1-bypass' 2>/dev/null"

/proc/device-tree/soc/qcom,icnss@18800000/qcom,smmu-s1-bypass
/proc/device-tree/soc/qcom,ipa@1e40000/qcom,smmu-s1-bypass

Between DMA devices and memory on ARM sits the SMMU. It can translate device addresses to physical ones through tables the OS owns, and then the device physically cannot reach what was not mapped for it. The qcom,smmu-s1-bypass property turns that translation off for a particular device. If it is set on icnss or wifi, the Wi‑Fi firmware writes into your RAM directly, and the only fence in front of it is the vendor's hypervisor.

The second hit on the tablet, ipa, is the network accelerator between the modem and the OS; same story. On newer chips (Snapdragon 8 Gen 1 and later) this property is usually gone for Wi‑Fi, replaced by iommus. Tell me what you have: this is exactly what I want to tabulate.

If find returns “Permission denied”, try ls /proc/device-tree/soc/ | grep -i icnss and then ls inside the node you found. The tree is readable without root on most devices, but not all.

adb shell "ls -l /dev/block/by-name/ 2>&1 | grep -Ei 'modemst|fsg|fsc|persist|frp|efs'"

fsc      -> /dev/block/sda13
fsg      -> /dev/block/sda14   # absent on my Tab S6, present on most
modemst1 -> /dev/block/sda11
modemst2 -> /dev/block/sda12
persist  -> /dev/block/sda6
frp      -> /dev/block/sda9

The one command most often refused without root: /dev/block is closed to the shell user. From recovery (TWRP or similar) it works. It shows the partitions a factory reset does not touch: modemst1/2 and fsg (the modem's file system, including its calibration and network settings), persist (sensor calibration, DRM keys, and on many devices assorted vendor data), frp (factory reset protection, the Google account binding).

All of this survives a reset by design, and there is no malice in it: without calibration the modem won't work. It is just useful to know that “I reset it before selling” does not mean “the disk is clean”. What to do about that I will cover separately.

adb shell "pm list packages | grep -iE 'stk|uicc|carrier'"

package:com.android.stk          # SIM Toolkit: command channel from SIM applets
package:com.android.carrierconfig
package:com.samsung.android.app.telephonyui

com.android.stk is SIM Toolkit, the app through which applets inside the SIM card show menus and send commands: open a URL, send an SMS, request location. The SIM card is itself a separate computer with a Java Card OS, and the carrier installs applets on it over the air. In 2019 one such applet (S@T Browser) was the vehicle for Simjacker: the card, using the modem, sent location and IMEI over SMS without Android's involvement. The presence of the package does not mean a vulnerability; it means the channel exists.

adb shell "getprop ro.boot.verifiedbootstate; getprop ro.boot.flash.locked; getprop ro.boot.vbmeta.device_state"

green      # boot chain verified by the vendor's signature
1          # bootloader locked
locked

green means the whole chain from bootloader to system was verified by the vendor's signature. That is good against firmware tampering, and it also means the list of what boots is approved by the vendor, not the owner. orange means an unlocked bootloader and your own responsibility. yellow and red are rare and mean a foreign key or a failed check.

On a Linux laptop two lines show the same about Wi‑Fi and co‑processors:

for d in /sys/class/net/*/device; do
  echo "$(basename $(dirname $d)): $(cat $d/iommu_group/type 2>/dev/null || echo 'no IOMMU')"
done
ls /sys/class/remoteproc/*/name 2>/dev/null | xargs -r cat

DMA or DMA-FQ means device addresses are translated; identity means physical addresses; no file means there is no IOMMU for this device or it is off in the BIOS. On Windows: Device Manager, the Wi‑Fi adapter, Details, the “DMA Remapping Policy” property; 2 is translation, 0 and 1 physical addresses.

On MediaTek the co‑processor firmware lives in /vendor/firmware under names like scp.img, sspm.bin, WIFI_RAM_CODE_*, modem_*.img; the kernel sees them via /sys/class/remoteproc or /sys/bus/platform/drivers/mtk-scp. On Exynos and Tensor Wi‑Fi is usually a separate Broadcom chip with bcmdhd*.bin firmware, the modem is in modem.bin, and the thing to ask there is whether the wlan node has iommus. On an iPhone there is nothing to check: a DART always sits in front of the modem, and which modem is inside you learn from the model number and teardowns.

First: look at the gap between the two patch levels and understand how far behind the layer you cannot see is. If the gap is more than a quarter, that is an argument when choosing the next device. Second: if icnss has smmu-s1-bypass, know that an over‑the‑air compromise of the Wi‑Fi firmware (Broadpwn, QualPwn) on this device means access to kernel memory. It is a rare event, but the security model has to account for it. Third: before selling a device, remember the partitions from command 5.

And a request. Post the model, the chip and the output of commands 1, 3 and 4 in the comments. I will collect a table by device and add it here. MediaTek and Tensor are especially interesting because I don't have them. If you found a mistake in the legend, say so and I will fix it.

Where this comes from

Someone else's computer: why your phone isn't yours — and what to do about it

Code by eight authors runs in your phone, and yours is the least privileged. We wrote our own OS, booted it on a tablet and spent half a year finding out who else lives in the chip and whose rules apply. How it works, why it concerns laptops, iPhones and light bulbs, and three levels of an answer.

The Parasite in the Tablet

On the F4VE breadboard Wi‑Fi was 950 lines behind a UART. On a Snapdragon 855 tablet it became 32,000: nine stages, a dozen silent SoC resets, four servers we run for the chip. The 'Wi‑Fi chip' is half a modem with DMA, a file system and its own radio — a tenant with the landlord's keys. What it can do, whom it concerns (every Snapdragon Android, Windows laptops, iPhones with a Qualcomm modem), and how to isolate it transparently.

Bringing up Wi‑Fi on a bare Snapdragon 855 without Linux: ten silent reboots and 32,000 lines

On an ESP32 dev board Wi‑Fi took 950 lines. On a Galaxy Tab S6 without Linux the same functions took 32,000 lines, four servers for the modem and ten chip reboots without a single error message. The bring‑up chronology from the journal: what the firmware demands, how I learned to see the cause of a silent reset, and what remains undone.