Шесть убеждений о телефоне, которые я потерял, загрузив на Galaxy Tab S6 свою ОС

Полгода назад я был уверен, что понимаю, как устроен телефон. Процессор исполняет операционную систему, ОС управляет железом, авиарежим выключает радио, factory reset стирает данные, пароль от Wi‑Fi защищает трафик, а ошибка ^[1] возвращает сообщение об ошибке. Потом мы загрузили на Samsung Galaxy Tab S6 (Snapdragon 855) собственную операционную систему, и я полгода поднимал на ней Wi‑Fi. К сентябрю из шести убеждений не осталось ни одного: каждое сломалось на конкретном событии, у большинства есть лог.

Коротко, что выяснилось. В устройстве исполняется код по меньшей мере восьми авторов, и ваш (ОС и приложения) самый бесправный из них. Заборы между DMA чипов и вашей памятью ^[2] держат гипервизор Samsung и TrustZone Qualcomm, а у Wi‑Fi‑прошивки в стоковом Android эти заборы выключены одной строкой в device tree. Файлы модема лежат на вашем диске в разделах, которые сброс не трогает. И ничего из этого не свойство нашей ОС: мы лишь получили возможность посмотреть.

Ниже по одному убеждению за раз: во что я верил, на каком событии это сломалось (с логами), что оказалось на самом деле и как проверить на своём устройстве. Содержание: кто говорит → шесть убеждений → кого это касается → как проверить своё → не только Snapdragon → чего я не знаю → просьба к комментаторам.

Кто говорит и на чём

Роль, инструмент и главная оговорка.

Я отвечал за Wi‑Fi в небольшой команде, которая пишет операционную систему на Rust с чистого листа: ядро без std, планировщик, хранилище, графика. Та же система работает процессом на macOS и Linux, в QEMU на ARM64, на Cortex‑M4 со 128 КиБ памяти и на этом планшете. Я не безопасник; всё, что ниже сказано про атаки, взято из опубликованных отчётов, и я называю их по имени.

Заменять Android на планшете мы не собирались. Планшет понадобился как инструмент. Увидеть, что чипы требуют от хоста и как реагируют на ответы, можно одним способом: обслуживать их самому, без вендорских драйверов. Язык ни при чём: на C или в mainline Linux в логах будет то же самое.

И оговорка, без которой текст читается неправильно. Кто грузит чип, кто владеет IOMMU, где лежат файлы модема, у кого ключ от Wi‑Fi: всё это задано загрузчиком, TrustZone и гипервизором до старта любой операционной системы. Наша ничего здесь не меняет; она дала возможность посмотреть. Дальше это разбор железа, а не рассказ о нашей системе.

Убеждение 1. Ошибка возвращает сообщение об ошибке

Около десяти перезагрузок всего чипа без единой строки в логе.

На микроконтроллере ошибка выглядит как HardFault с адресом в регистре. Я ждал того же. Первый раз планшет перезагрузился примерно через десять секунд после команды remoteproc.list, в простое. Без паники, без исключения, без прерывания: консоль по USB замолчала, через секунду появился логотип загрузчика.

Таких эпизодов за bring‑up было около десяти. Я пошёл искать улики и выяснил, что искать негде. DRAM после warm reset загрузчик S‑Boot отдаёт пустой; проверял в четырёх местах (собственная NOLOAD‑страница образа, последние 64 КиБ нашей RAM, свободная память на 2,5 ГиБ, область ramoops Samsung), и каждая загрузка приходила чистой. На четыре пустых вердикта ушло полдня.

Регистры причины включения в микросхеме питания PM8150 (PON_REASON1, WARM_RESET_REASON1/2, POFF_REASON1/2) после такого сброса показывают ту же картину, что после штатного PSCI SYSTEM_RESET: hard reset как причина, warm reset, упорядоченное выключение. Лог TrustZone в IMEM у Samsung зашифрован и чистится сбросом. Попытка прочитать его отладочным инструментом дала одиннадцатый сброс: узел tz-log заявляет 12 КиБ там, где у родительского IMEM четыре.

Что тогда переживает сброс? Сама микросхема питания, она работает от батареи. В её блоке SDAM (Android видит его как nvmem) нашлись 72 свободных байта. Туда перед каждым опасным шагом пишется имя шага (pas auth, smem toc, wlfw fw_ready wait), после шага метка снимается. Следующая загрузка читает, что осталось. Вот один из случаев (формат нашего тула, сокращено):

sys.boot                          # первая команда после каждой перезагрузки
last_reset: reset                 # PON PM8150: та же картина, что после PSCI SYSTEM_RESET
previous:
  reason: reset                   # "the last run was up when it ended, and left no words"
  step:   wlfw fw_ready wait      # метка стояла в SDAM и не была снята

Метка не говорит, кто сбросил и почему. Она говорит, где мы были. Здесь: все наши запросы прошивке Wi‑Fi ушли и были приняты, сброс пришёл на ожидании её ответа. Это сдвинуло подозрение с «мы неверно послали» на «прошивка что-то тронула по нашей просьбе». Сначала я подозревал регион MSA: сверил адрес живьём, поменял размер с 1,5 на 1 МиБ. Сброс остался. Виноваты оказались два невключённых такта (rfclka2 и qdss); после них FW_READY_IND пришла через 8 секунд после старта модема.

Что осталось от убеждения. SoC отвечает на ошибку хоста перезагрузкой всего чипа, кода ошибки нет. Из десяти случаев ошибку вернул один: secure world отказался отдать модему память по адресу, который в живом дереве оказался памятью гипервизора (0x8bc0_0000 из офлайн‑dtsi другого релиза против живого 0x8c20_0000). Кто перезагружает и почему, хосту не видно ни в одном регистре.

Убеждение 2. Операционная система управляет железом

Голоса вместо команд, вето вместо записи в регистр.

Третий сброс пришёл от питания. На шаге handover мы снимали свой голос за уровень рельсы cx.lvl до нуля, как делает референс. Планшет жил, пока модем был занят, и умирал, когда модем уходил в простой. Рельса vdd_cx питает цифровую логику ^[3] всего SoC, и агрегат по ней держался на голосе модема.

Голос. Питание и такты на Snapdragon раздаёт отдельный процессор AOP (Cortex‑M внутри SoC) по базе команд, которую он же хранит; хост один из голосующих, и загрузчик уже оставил голоса от нашего имени. Копия базы в его message‑RAM закрыта: чтение останавливает процессор. Фикс: пол уровней, cx.lvl не ниже NOM.

Выше AOP стоят ещё двое. Гипервизор Samsung на EL2 владеет SMMU: в дереве устройств у apps_smmu стоит qcom,skip-init, «глобальную конфигурацию не трогай». Когда я записал в регистр S2CR потока Wi‑Fi тип bypass, регистр прочитался обратно с типом fault. Не остался прежним, был переписан на противоположный. Каким механизмом он перехватывает запись из EL1, из EL1 не видно.

TrustZone Qualcomm на EL3 проверяет подписи прошивок и запускает их (PAS), держит XPU‑заборы над регионами памяти, владеет регистрами модема (QDSP6SS из обычного мира читается как bus error) и решает, кому принадлежит какой кусок RAM (assign_mem). Чтение одного байта за его забор равно сбросу из убеждения 1.

Стрелки из вашего блока: просьбы и обслуживание. Стрелки в него: власть. Планшет Galaxy Tab S6, Snapdragon 855.

Стрелки из нашего блока на схеме: просьбы (smc), голоса (RPMh), обслуживание (серверы для модема). Стрелки в него: право перезагрузить, право прочитать память, право не загрузить. Я насчитал у ОС пять глаголов: просить, голосовать, обслуживать, валидировать, запирать то, до чего дотягиваешься. «Запретить» и «проверить их код» в этом списке отсутствуют; так устроен современный SoC, и наша ОС здесь ни при чём.

Стоковый Android живёт в тех же условиях: та же строка в дереве, тот же гипервизор. Разница в том, что его драйверы об этом знают и не пытаются.

Убеждение 3. Wi‑Fi‑чип это периферия

950 строк на макетке против 32 000 на планшете, и куда ушла разница.

На макетке STM32F407 модуль ESP32 висел на одном UART: пишешь AT+CWJAP="ssid","pass", читаешь WIFI GOT IP. Драйвер 950 строк Rust, несколько дней. На планшете «то же самое» заняло 32 000 строк и те десять сбросов. Первое объяснение, «SoC сложнее», неверное; разница ушла на другое.

На Snapdragon 855 чип WCN3990 это радиофронтенд. Вся логика 802.11 (скан, ассоциация ^[4], шифрование, очереди) исполняется в прошивке на Hexagon DSP сотового модема: одна прошивка modem.mbn на 80 МБ, внутри неё WLAN.HL.3.2.0.c3-00910 отдельным protection domain рядом с LTE и GNSS. Отдельной шины (PCIe) к нему нет, он сидит на системном NoC, на той же шине, что и память.

И у этой прошивки есть список требований к хосту. Чтобы Wi‑Fi поднялся, хост обязан поднять для неё четыре сервера: rmtfs (сектора разделов модема на диске), tqftp (файлы прошивок; она пишет туда server_check.txt и без успеха не грузится), pd-mapper (без ответа на kernel/elf_loader WLAN не стартует) и memshare (перевод регионов RAM в её собственность через secure world). Плюс SMEM, GLINK, QRTR, QMI и семь рельс питания.

Куда ходят её DMA? У прошивки 12 copy engines, они пишут в RAM потоком 0x640 через apps_smmu. В стоковом дереве Tab S6 узел qcom,icnss@18800000 помечен qcom,smmu-s1-bypass: адрес, который прошивка кладёт в дескриптор, это физический адрес RAM. Ядро, куча, пароли сетей, токены. Единственные заборы перед ней: stage‑2 гипервизора и XPU TrustZone. Оба чужие, и содержимое их таблиц из EL1 не читается.

Почему Wi‑Fi, а не GPU или камера? В том же дереве GPU и камера стоят за SMMU с трансляцией, которую настраивает ядро; bypass выставлен только у Wi‑Fi. Причина, насколько я понимаю, простота: downstream‑драйвер icnss годами работает так, и наш первый подъём пошёл тем же путём, потому что включение трансляции по дороге ломало инициализацию сбросом. Mainline Linux на HDK SM8150 с той же прошивкой WLAN.HL.3.2.0 трансляцию включает через dma-iommu; в arm-smmu-qcom.c список identity‑клиентов есть, и qcom,wcn3990-wifi в нём отсутствует.

У нас stage‑1 для потока 0x640 пока не включён. Это в плане и помечено «не сделано»; вернусь к этому в списке того, чего я не знаю.

Убеждение 4. Пароль от Wi‑Fi защищает мой трафик

Пароль остаётся на хосте, ключ трафика уезжает в модем. У всех.

Мы написали 802.11i сами: 4‑way handshake WPA2, групповое рукопожатие, SAE для WPA3, крейт без unsafe. Пароль лежит в сторе ядра, из него на хосте считается PMK (PBKDF2‑SHA1, 4096 раундов), из PMK и нонсов PTK. Прошивка видит кадры EAPOL в открытом виде (они и в эфире открытые), но не видит ни пароля, ни PMK, ни KCK/KEK.

А потом хост делает то же, что wpa_supplicant через nl80211 и ath10k_set_key в Linux: отдаёт прошивке командой VDEV_INSTALL_KEY 16 байт TK и групповой ключ. С этого момента каждый кадр сессии шифрует и расшифровывает она (hwcrypto). Исходящие Ethernet‑кадры хост кладёт в окно DMA открытым текстом, входящие получает уже расшифрованными.

Что защищает супликант на хосте? Учётные данные: скомпрометированная прошивка не войдёт в сеть как другое устройство и не откроет чужие сессии на той же сети. Чего он не защищает: трафика этой сессии. Для прошивки он открытый текст по определению, и это не исправляется ни одной строкой в супликанте. У Linux, Android и у нас в столбце «ключ трафика» стоит одно и то же слово: прошивка.

Практический вывод для меня оказался не про Wi‑Fi. Содержимое защищено ровно тем, что зашифровано до попадания в модем: TLS с проверкой сертификата и сквозное шифрование в мессенджере. На трёх своих платах я нашёл HTTPS без проверки сертификата (в ESP‑AT это дефолт, CIPSSLCCONF=0). В IoT это обычная практика; проверьте свои устройства.

VPN здесь тоже стоит поставить на место. Он закрывает трафик от провайдера и от чужого Wi‑Fi. Отпечаток браузера, часовой пояс, вход в аккаунты и собственный uplink модема в сеть оператора (об этом в убеждении 6) он не трогает. Сайты сверяют IP с часовым поясом из Intl.DateTimeFormat, языком и системным временем; расхождение (адрес в Амстердаме, часы в Москве) выдаёт человека надёжнее адреса.

Убеждение 5. Factory reset стирает всё

Разделы модема на вашем диске, 23 миллисекунды и тень вместо диска.

Пятый сброс был не всего SoC, а модема, и он оставил улику: время. Сервер rmtfs ведёт лог по каждому вызывающему. Вот что в нём было (сокращено):

rmtfs  OPEN  /boot/modem_fs1   ok   read hdr: 1 sector @512
rmtfs  OPEN  /boot/modem_fs2   ok   read hdr: 1 sector @512
rmtfs  OPEN  /boot/modem_fsg   ERR  no such partition
smp2p  slave-kernel 6 -> 7                      (+23 ms)
rproc  mss: running -> crashed

Раздела fsg (золотая копия EFS) в GPT этого планшета нет вообще. Мы отвечали отказом, как отвечает rmtfs из утилит qrtr для Linux, и через 23 мс слово SMP2P slave-kernel менялось с 6 («готов») на 7 («fatal»). Каждый раз.

Контроль: если rmtfs не поднимать вовсе, модем живёт около 40 секунд и умирает с efs sync failed. Почему отказ фатален мгновенно, а отсутствие сервера через 40 секунд, я не знаю: код прошивки закрыт, а причины в SMEM (SMEM_SSR_REASON_MSS0) нет, модем умирает раньше, чем стартует его сервис ошибок.

Обход: fsg открывается пустым, тень из нулей размером с modemst1. EFS модема знает состояние «стёртая золотая копия»: читает заголовок, выбирает рабочую копию, идёт дальше. Потом это стало правилом для всех наших серверов. При OPEN раздел один раз читается в RAM, все RW_IOVEC идут в копию, пути записи на диск в коде нет. Модем видит, что записи «легли», диск не меняется. Цена: часть функций сотового модема без персистентного EFS не заработает.

Теперь к убеждению. modemst1, modemst2, fsg, fsc это разделы на вашем UFS. Их не трогает ни factory reset, ни переустановка ОС: EFS должна переживать перезагрузку by design. В Linux и Android серверы rmtfs и rmt_storage делают ровно то, что просит модем: читают и пишут настоящие разделы. Что лежит внутри, я не разбирал и не утверждаю; видел только паттерн доступа.

Что это значит для «сбросил перед продажей»? Раздел userdata сброс стирает (уничтожается ключ шифрования). Разделы модема остаются как были. Данные там модемные, но тот, кто однажды туда записал (с физическим доступом через режим EDL, например), переживёт любой сброс. У самого сброса тоже есть история: в 2015 году в Кембридже показали, что factory reset на Android того времени не стирал пользовательские данные до конца.

Раз речь о хранилищах, до которых хосту не дотянуться: на планшете есть ещё двое таких. SIM‑карта со своей ОС и апплетами (Simjacker в 2019 году отправлял команды через апплет S@T Browser, и карта силами модема отдавала местоположение по SMS у операторов примерно в 30 странах). И контроллер накопителя со своей прошивкой (баг eMMC у Samsung в 2012 году, чипы MAG4FA/VYL00M, превращал обычный wipe в recovery в кирпич).

Убеждение 6. Авиарежим выключает радио

Запрос к модему, а у модема свой uplink и свой GNSS.

Это убеждение я потерял без сброса, просто дочитав список требований прошивки. У модема собственное радио и собственный uplink в сеть оператора. Авиарежим в Android это запрос ОС к модему; модем уходит в low‑power mode силами своей прошивки и сам решает, что делать с запросом. На iOS с 2019 года в авиарежиме Bluetooth и Wi‑Fi намеренно остаются включёнными. Как убедиться, что радио молчит? Только измерить снаружи, прибором, а не индикатором в статус‑баре.

GNSS у Qualcomm тоже в модеме, отдельным protection domain на том же Hexagon. Координаты устройства прошивка знает без запроса к ОС. В 2023 году Nitrokey зафиксировал, что телефоны на Qualcomm без Google‑сервисов ходят на izatcloud.net; Qualcomm ответил, что это сервис XTRA (ассистированный GPS), описанный в его политике конфиденциальности. Не компрометация. Иллюстрация того, что у подсистемы свои отношения с внешним миром.

Есть устройства, где авиарежим сделан рубильником. Librem 5 (около 1 000 долларов) и PinePhone (от 150 долларов, кремний уровня 2016 года) выносят модем на USB, где у него нет DMA в память хоста, а аппаратные переключатели рвут питание радио.

Можно ли собрать телефон вообще без чужого кода? У PinePhone модем Quectel EG25‑G с закрытым baseband и Wi‑Fi Realtek с закрытой прошивкой; у Librem 5 модем на M.2 тоже закрытый. Единственное известное мне устройство, где код весь ваш, это Precursor (SoC на FPGA), и ровно поэтому в нём нет сотового модема. Открытого baseband с сертификацией оператора не существует.

Кого это касается

Пропорции, пять классов атакующих с документированными случаями, группы риска.

Сначала про пропорции, чтобы не получилось ружья на стене. Подавляющее большинство задокументированных целевых атак на телефоны идёт через ОС и мессенджеры (Pegasus через iMessage, Predator через ссылки), а не через baseband. Прошивки модема и Wi‑Fi это слой, до которого патчи доходят последними (для не‑Pixel устройств лаг измеряется месяцами) и который не видит ни MDM, ни антивирус, ни владелец.

Только то, на что есть публичный отчёт. Соседа, взламывающего ваш модем, и массового червя через baseband в списке нет.

Значит ли это, что вас взломают через модем? Скорее всего, нет. Следует другое. Модель «поставил VPN, включил авиарежим, сделал сброс» строится на предположении, что эти действия управляют железом. Они управляют запросами к железу, и разница проявляется ровно тогда, когда от неё что-то зависит. По группам:

• Обычный человек. Реальная угроза только первая строка, сеть оператора. Меры: второй фактор не по SMS, мессенджер со сквозным шифрованием, TLS везде. Стоимость: час. Остальные четыре строки для него теория.

• Журналист, адвокат, админ с ключами от продакшена, любой, у кого телефон могут изъять. Строки со второй по четвёртую применялись против ровно этих групп, отчёты с именами есть. Проверка своего устройства (следующий раздел) стоит десять минут; телефон с модемом за забором стоит денег.

• Компания с парком устройств. Практический риск в лаге патчей baseband и в том, что инвентаризация «какой модем, транслируется ли DMA» обычно не ведётся вообще. Провести её один раз командами ниже.

Чего в списке нет: соседа, взламывающего ваш модем; массового червя через baseband; слежки через камеру силами прошивки Wi‑Fi (у неё нет ни микрофона, ни камеры, путь только через хост). Ничего такого не задокументировано, и я этого не утверждаю. Есть и требование к вендорам, которое ничего не стоит: включить stage‑1 трансляцию SMMU для Wi‑Fi в стоковой прошивке. Это один дефолт в device tree, не закон об открытом коде модема.

Как проверить своё устройство

Десять минут, без разборки. Linux, Android, Windows, iPhone.

Linux (ноутбук или телефон с mainline). Транслируется ли DMA Wi‑Fi‑карты, видно по типу её IOMMU‑группы; кто обслуживает модем, по процессам:

for d in /sys/class/net/*/device; do
  echo "$(basename $(dirname $d)): $(cat $d/iommu_group/type 2>/dev/null || echo 'no IOMMU')"
done
pgrep -a 'rmtfs|tqftpserv|pd-mapper'      # кто обслуживает модем и на что он пишет

Android (нужен adb shell; root не обязателен для первых двух команд на большинстве устройств, но на некоторых by-name закрыт):

adb shell ls -l /dev/block/by-name/ | grep -E 'modemst|fsg|fsc'
adb shell find /proc/device-tree -name 'qcom,smmu-s1-bypass' | grep -iE 'icnss|wifi|wlan'
adb shell ls /proc/device-tree/soc | grep -iE 'icnss|cnss|wifi'   # icnss: на модеме; cnss/PCIe: отдельный чип

Что покажет любой телефон: ничего про радио. Авиарежим это запрос, и проверить, что модем молчит, можно только прибором снаружи.

Не только Snapdragon и не только телефон

Тот же протокол на ноутбуках и в iPhone; та же архитектура у других вендоров.

Протокол, который я обслуживал, у Qualcomm общий для любого хоста. Тот же QMI WLFW и то же требование памяти у FastConnect на Snapdragon 865 и новее (там прошивка исполняется на своём ядре, но REQUEST_MEM_IND просит десятки мегабайт под DMA). Те же серверы у ноутбуков на Snapdragon X Elite.

Тот же модем в iPhone (вся линейка 17 на X80), где перед ним всегда стоит DART. На x86‑ноутбуках с картами QCA (их массово ставят Lenovo, HP, Dell) трансляция DMA под Windows включается, только если драйвер объявил DmaRemappingCompatible.

У Broadcom, MediaTek, Exynos имена другие, архитектура та же: отдельный процессор, подписанная прошивка, DMA, требования к хосту. Никто не делает Wi‑Fi без прошивки на отдельном процессоре: тайминги 802.11 в микросекундах под ОС общего назначения не живут.

Thunderclap в 2019 году показал, что устройство в разъёме Thunderbolt читает память хоста на macOS, Linux и Windows даже при включённом IOMMU, потому что ОС ставила забор слишком широко. На Raspberry Pi первым стартует VideoCore с закрытой прошивкой; он инициализирует память и запускает ARM‑ядра, Linux общается с ним через mailbox.

ESP32 в лампочке другой случай. Блоб Wi‑Fi‑стека (libnet80211, libpp, libphy) линкуется в ваш образ и исполняется на вашем процессоре, с вашими ключами в eFuse. Чужой код есть, периметр ваш: ему негде спрятаться и нечего требовать. Уязвимости в нём тоже находят (CVE‑2019‑12586, BrakTooth), последствие RCE в вашем процессе, где и так весь ваш код, а не в подсистеме с собственным выходом в мир.

Чего я не знаю и не сделал

Список, который считаю частью результата.

• Stage‑1 трансляция для потока 0x640 у нас не включена. План: тот же банк SMMU, SCTLR.M = 1, таблицы только на окно 4 МиБ. Гипервизор может ветировать и это; узнать можно одним прогоном с риском сброса.

• Почему отказ на fsg фатален через 23 мс, а отсутствие сервера через 40 секунд. Код прошивки закрыт; утверждаю только тайминг и воспроизводимость.

• Что в таблицах stage‑2 гипервизора и почему запрещён bypass. EL2 из EL1 не читается.

• Регионы, отданные модему через memshare (MSA, буфер rmtfs), он пишет своим путём, минуя apps_smmu. Stage‑1 их не запирает; там только минимальные гранты и XPU от TrustZone.

• Устройства энтропии на этой плате пока нет: нонсы рукопожатия берутся из предсказуемого источника. Это записано как некриптостойкое и должно быть исправлено до того, как сеть станет чем-то большим, чем тест.

• Код TrustZone, гипервизора и модема я не читал и не смогу: он подписан и закрыт. Граница проведена вокруг, а не внутри.

Просьба к комментаторам

Что мне не хватает, чтобы таблица выше стала шире одного планшета.

Всё выше проверено на одном устройстве. Мне не хватает выводов команд из раздела «Как проверить» с других. Особенно интересно: iommu_group/type для Wi‑Fi на ноутбуках с картами Qualcomm и MediaTek под Linux; есть ли раздел fsg на ваших Snapdragon (на Tab S6 его нет, и я не знаю, исключение это или правило); стоит ли qcom,smmu-s1-bypass у icnss на других 845/855; и как выглядит аналог у Exynos (Shannon) в дереве устройств.

Если у кого-то есть измерение радио в авиарежиме прибором, а не по индикатору в статус‑баре, это закрыло бы единственное убеждение из шести, которое я потерял по чужим данным, а не по своим. Если нашли ошибку в фактах, скажите, поправлю.