Кто ещё исполняется в вашем Android: семь команд adb без root и что означает их вывод

После статьи про то, кто исполняется в телефоне помимо ОС, меня несколько раз спросили одно и то же: а как посмотреть на своём? Я собрал семь команд, которые работают через обычный adb shell без root на большинстве Android на Qualcomm, и объяснил, что означает каждая строка вывода. На всё уходит минут десять, если отладка по USB уже включена.

Сразу оговорка. Все выводы ниже сняты с моего Galaxy Tab S6 (Snapdragon 855); пути для других чипов я взял из открытых деревьев устройств и исходников ядер, а не проверял руками. На MediaTek, Exynos и Tensor пути другие, часть команд вернёт пустоту, и в конце я написал, что смотреть там. Если у вас команда отработала иначе, напишите в комментариях модель и вывод: соберём таблицу по устройствам.

Что нужно: включённая отладка по USB, adb на компьютере (входит в Android platform-tools), кабель. Root не нужен ни для одной команды ниже, кроме одной, и там я это отметил.

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

На моём планшете вывод такой (комментарии мои):

a640_zap      # GPU: подписанный «zap»-шейдер, без него GPU не стартует
adsp          # аудио-DSP: свой Hexagon, своя ОС
cdsp          # вычислительный DSP: камера, ML
ipa_fws       # IPA: аппаратный ускоритель сети между модемом и ОС
modem         # сотовый модем + GNSS + вся логика Wi-Fi
slpi          # сенсорный хаб: акселерометр, гироскоп, шагомер
venus         # видеокодек
wlanmdsp      # WLAN-часть модемной прошивки

Каждая строка это отдельный подписанный образ, который загрузчик или ядро передаёт своему процессору внутри SoC. На Tab S6 их восемь. На телефонах 8‑й серии обычно 10–14: добавляются npu, второй cdsp, spss (защищённый процессор), прошивки дисплея и тача. Число само по себе ни о чём не говорит, но оно хорошо калибрует интуицию «в телефоне работает Android».

Если каталог пустой или недоступен, попробуйте ls /vendor/firmware или ls /odm/firmware; у части вендоров модемная прошивка лежит в отдельном разделе, который монтируется в /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    # модем
17300000.remoteproc-adsp
8300000.remoteproc-cdsp
2400000.remoteproc-slpi

Это те сопроцессоры, которыми ядро управляет явно: запускает, останавливает, перезапускает при падении. Шестнадцатеричное число это адрес блока регистров в карте памяти SoC. Если строк нет вообще, у вас старое ядро с другим интерфейсом или SELinux закрыл sysfs; тогда достаточно команды 1.

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

T865XXU5CVH2          # версия прошивки модема
2023-10-01            # патч системы (Android)
2023-08-01            # патч вендорской части (прошивки, драйверы)

Первая строка это версия прошивки baseband, её можно проверить на сайте вендора. Вторая и третья интереснее. Android показывает в настройках патч системы, а патч вендорской части (модем, DSP, драйверы) живёт в отдельном свойстве, и он часто отстаёт. На моём планшете разница два месяца. В чужих отчётах по устройствам не‑Pixel встречается и полгода. Это и есть реальный лаг обновлений того слоя, который не видит ни антивирус, ни MDM.

Если ro.vendor.build.security_patch пустой, посмотрите ro.vendor.build.date или 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

Между DMA‑устройствами и памятью на ARM стоит SMMU. Он может транслировать адреса устройства в физические по таблицам ОС, и тогда устройство физически не дотянется до того, что ему не отобразили. Свойство qcom,smmu-s1-bypass выключает эту трансляцию для конкретного устройства. Если оно стоит у icnss или wifi, Wi‑Fi‑прошивка пишет в вашу RAM напрямую, а единственный забор перед ней это гипервизор вендора.

Второй результат на планшете, ipa, это сетевой ускоритель между модемом и ОС; у него та же история. На новых чипах (Snapdragon 8 Gen 1 и позже) для Wi‑Fi это свойство обычно уже снято, и вместо него стоит iommus. Напишите, что у вас: как раз это и хочется свести в таблицу.

Если find возвращает «Permission denied», попробуйте ls /proc/device-tree/soc/ | grep -i icnss и дальше ls внутрь найденного узла. Дерево читается без root на большинстве устройств, но не на всех.

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   # на моём Tab S6 fsg отсутствует, на большинстве есть
modemst1 -> /dev/block/sda11
modemst2 -> /dev/block/sda12
persist  -> /dev/block/sda6
frp      -> /dev/block/sda9

Единственная команда, которой без root чаще всего откажут: каталог /dev/block закрыт для пользователя shell. Из recovery (TWRP или аналог) она работает. Показывает разделы, которые сброс к заводским настройкам не трогает: modemst1/2 и fsg (файловая система модема, включая его калибровки и настройки сети), persist (калибровки сенсоров, ключи DRM, на многих устройствах ещё и всякое от вендора), frp (защита от сброса, привязка к аккаунту Google).

Всё это переживает сброс by design, и в этом нет злого умысла: без калибровок модем не заработает. Просто полезно знать, что «сделал сброс перед продажей» не означает «диск чистый». Что с этим делать, я разберу отдельно.

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

package:com.android.stk          # SIM Toolkit: канал команд от апплетов SIM-карты
package:com.android.carrierconfig
package:com.samsung.android.app.telephonyui

com.android.stk это SIM Toolkit, приложение, через которое апплеты внутри SIM‑карты показывают меню и отправляют команды: открыть URL, отправить SMS, запросить местоположение. SIM‑карта сама по себе отдельный компьютер с Java Card ОС, и апплеты на неё ставит оператор, по воздуху. В 2019 году через один из таких апплетов (S@T Browser) работал Simjacker: карта силами модема отправляла местоположение и IMEI по SMS без участия Android. Наличие пакета не означает уязвимости, оно означает, что канал существует.

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

green      # цепочка загрузки проверена подписью вендора
1          # загрузчик заблокирован
locked

green означает, что вся цепочка от загрузчика до системы проверена подписью вендора. Это хорошо для защиты от подмены прошивки и одновременно означает, что список того, что загрузится, утверждает вендор, а не владелец. orange означает разблокированный загрузчик и вашу собственную ответственность. yellow и red встречаются редко и означают чужой ключ или провал проверки.

На Linux‑ноутбуке две строки показывают то же самое про Wi‑Fi и сопроцессоры:

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 или DMA-FQ означает, что адреса устройства транслируются; identity означает физические адреса; отсутствие файла означает, что IOMMU для этого устройства нет или выключен в BIOS. На Windows: Диспетчер устройств, Wi‑Fi‑адаптер, Сведения, свойство «DMA Remapping Policy»; значение 2 это трансляция, 0 и 1 физические адреса.

На MediaTek прошивки сопроцессоров лежат в /vendor/firmware с именами вида scp.img, sspm.bin, WIFI_RAM_CODE_*, modem_*.img; ядро видит их через /sys/class/remoteproc или /sys/bus/platform/drivers/mtk-scp. На Exynos и Tensor Wi‑Fi обычно отдельный чип Broadcom с прошивкой bcmdhd*.bin, модем в modem.bin, и там стоит спросить про iommus у узла wlan. На iPhone проверять нечего: перед модемом всегда стоит DART, а какой модем внутри, узнаётся по номеру модели и разборкам.

Первое: посмотреть разницу между двумя патчами и понять, насколько отстаёт слой, который вы не видите. Если разница больше квартала, это аргумент при выборе следующего устройства. Второе: если у icnss стоит smmu-s1-bypass, знать, что компрометация Wi‑Fi‑прошивки по воздуху (Broadpwn, QualPwn) на этом устройстве означает доступ к памяти ядра. Это редкое событие, но модель безопасности должна его учитывать. Третье: перед продажей устройства помнить про разделы из команды 5.

И просьба. Напишите в комментариях модель, чип и вывод команд 1, 3 и 4. Я соберу таблицу по устройствам и добавлю сюда. Особенно интересны MediaTek и Tensor, потому что у меня их нет. Если нашли ошибку в расшифровке, тоже скажите, поправлю.

Откуда это взялось

Чужой компьютер: почему ваш телефон вам не принадлежит — и что с этим делать

В вашем телефоне исполняется код восьми авторов, и ваш самый бесправный. Мы написали свою ОС, загрузили её на планшет и полгода выясняли, кто ещё живёт в чипе и чьи правила там действуют. Как это устроено, почему это касается ноутбуков, iPhone и лампочек, и три уровня ответа.

Паразит в планшете

На макетке F4VE Wi‑Fi был 950 строками за UART‑ом. На планшете Snapdragon 855 стал 32 000: девять стадий, дюжина тихих сбросов SoC, четыре сервера, которые мы поднимаем для чипа. «Wi‑Fi‑чип» — половина модема с DMA, файловой системой и собственным радио: жилец с ключами арендодателя. Что он может, кого касается (каждый Android на Snapdragon, ноутбуки с Windows, iPhone с модемом Qualcomm) и как изолировать его прозрачно.

Как я поднимал Wi‑Fi на голом Snapdragon 855 без Linux: десять тихих перезагрузок и 32 000 строк

На макетке с ESP32 Wi‑Fi занял 950 строк. На Galaxy Tab S6 без Linux те же функции заняли 32 000 строк, четыре сервера для модема и десять перезагрузок чипа без единого сообщения об ошибке. Хронология bring‑up‑а по журналу: что требует прошивка, как я научился видеть причину тихого сброса и что осталось не сделано.