LTE был. Связи не было. Как один бит в прошивке модема вернул робота в российскую сеть

Вставляешь рабочую SIM-карту в китайского робота-официанта. Модем видит SIM. Видит российских операторов. Видит даже LTE. Но зарегистрироваться в сети не может.

Проверяешь активацию, меняешь APN, пробуешь другого оператора, перезапускаешь радио. Всё выглядит так, будто до связи осталось одно правильное поле в настройках. В нашем случае это поле оказалось сравнением внутри закрытой радиопрошивки.

Расскажу, как мы прошли от «наверное, китайский APN» до разбора кода Qualcomm Hexagon, почему полезная инструкция пряталась в сжатом сегменте и при чём здесь публичный тестовый сертификат. В конце будут результаты настоящих запросов через LTE: одной надписи «зарегистрирован» нам было недостаточно.

Пациент: робот, внутри которого ещё несколько компьютеров

Наш пациент — робот-официант одного известного китайского производителя. Название и модель оставим за рамками: главный герой этой истории — установленный внутри Quectel EG25-GC.

Так выглядит модуль семейства EG25-G в исполнении Mini PCIe. Официальное изображение Quectel: на нём показана ревизия GB, а в нашем устройстве исследовалась GC. Это иллюстрация форм-фактора, не снимок нашего экземпляра.

У робота несколько вычислительных узлов. За Android, интерфейс и экраны отвечает плата на Rockchip RK3568. По данным device tree она определяется как RK3568 KXB LP4 V10 Board, система — Android 11. У шасси отдельный компьютер на Raspberry Pi CM4. Сотовый модем подключён по USB к Android-плате.

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

Упрощённая схема нашего стенда. Служебный ADB к модему включался временно; сетевой путь показан для проверенного сотового подключения.

Сведения, которые мы зафиксировали перед разбором:

Полная строка версии здесь важнее короткого названия «EG25-G». Мы исследовали конкретную GC-сборку. USB-идентификатор сам по себе её не определяет, а похожее имя соседней аппаратной версии не делает чужую прошивку подходящей.

Сначала мы честно подозревали SIM и настройки

Начали с обычной диагностики. SIM точно установлена? Активирована? Работает в телефоне с выключенным Wi-Fi? Требует PIN? Какой профиль данных выбрал Android?

Первая карта была Т‑Мобайла. После активации в телефоне она читалась в роботе: Android показывал LOADED, модем — CPIN: READY. В настройках действительно обнаружился китайский APN CMIOTCZBJC.JS. Для нашей карты он выглядел вполне убедительным подозреваемым.

Мы согласовали профиль Android и контекст передачи данных модема с APN tt, перезапустили модем и снова проверили состояние. Регистрации не появилось.

Затем поставили заведомо рабочую SIM Мегафона. У неё был свой профиль internet. Результат повторился: SIM прочитана, сети вокруг видны, присоединения к пакетной сети нет.

В ответе регистрации запись 2,2 — это режим выдачи информации и статус поиска сети. Её нельзя читать как «две ошибки» или как подтверждённый оператором отказ. Она описывает наблюдаемое состояние, но ещё не объясняет причину.

Особенно полезным оказался поиск сетей. Модем видел Tele2 в LTE, Мегафон в 2G/3G, другие сети тоже попадали в список. Значит, он мог принимать эфир и распознавать операторов. Из этого не следовало, что антенна и все диапазоны идеальны, но версия «модем вообще ничего не слышит» уже не соответствовала данным.

Здесь мы стали разделять четыре события, которые в разговоре обычно называют одним словом «связь»: обнаружение сети, регистрацию, присоединение к передаче данных и успешный прикладной запрос. Между ними достаточно места для совершенно разных неисправностей. Продолжать бесконечно перебирать APN, когда устройство не регистрируется с двумя рабочими картами, было слабой стратегией.

Побочный сюжет: почему мы перестали перезагружать всё подряд

Во время диагностики обычная перезагрузка Android вывела наружу отдельную проблему: Rockchip ушёл в цикл загрузки. При этом recovery оставался стабильным, а компьютер шасси продолжал работать.

По аварийным журналам причиной оказался kernel panic в Incremental FS: система пыталась работать с двумя остатками незавершённой установки APK, у которых отсутствовал backing store. Проблемные каталоги сохранили переименованием; сброс данных и переустановка системы не потребовались. Android вернулся к нормальной загрузке и выдержал контрольную перезагрузку.

Это неприятное ответвление важно для всей истории. Последовательность «спросили модем — перезагрузили Android — получили bootloop» легко принять за причинную связь. Но журналы показали другой механизм. После этого мы ещё строже различали перезапуск модема и перезагрузку основной платы.

Дальнейшее изменение радиопрошивки и проверка LTE прошли без перезагрузки Android. Это проверялось по неизменному идентификатору его загрузки.

Подозрение на региональное ограничение

Следующая версия появилась после чтения полной версии прошивки и поиска похожих случаев. На официальном форуме Quectel нашлась история про ту же ветку EG25GGCR07A02M1G: модуль распознавал российские SIM, сканировал сети, но оставался без обслуживания. Тема на форуме Quectel.

Более существенным источником оказался документ самого производителя — PCN 2022113001 от 30 ноября 2022 года. В нём описано обновление с ограничением сетевого подключения и позиционирования в России и Иране. Среди механизмов указаны MCC оператора и географические ограничения; семейство EG25-G есть в перечне. Планируемое начало поставок изменённых изделий — 1 февраля 2023 года. Отдельно сказано, что переход на новую версию не предполагает поддерживаемого отката. Уведомление Quectel, PDF.

Этого хватало, чтобы сменить направление поиска. Но недостаточно, чтобы объявить любую свежую прошивку Quectel заблокированной. Точный список затронутых OC и версий вынесен в отдельное приложение, которого у нас не было. Форумный случай и дата сборки — хорошие ориентиры, но доказательство для нашего экземпляра нужно было искать в его собственном коде.

Первой идеей был откат на старую совместимую прошивку. Подтверждение существования более ранней GC-ветки нашлось, а проверенного подходящего пакета — нет. Подставлять доступный образ с похожим названием мы не стали. Вместо этого сохранили то, что уже работает на устройстве, и начали разбирать текущую сборку.

Внутри модема оказался ещё один Linux

У этого модема есть ARM-часть с Linux и отдельная радиопрошивка для Hexagon. Наличие shell на ARM даёт возможность исследовать файлы и окружение, но само по себе не объясняет решения сотового стека.

В этом месте очень помогли опубликованные исследования EG25-G для PinePhone. В них уже разобраны архитектура устройства и служебный доступ к Linux модема. В частности, существует публичная утилита для challenge-response механизма QADBKEY. Мы использовали известный подход, а не открывали его заново. Исследование Megi на xnux.eu.

На нашем экземпляре служебный доступ заработал, после чего появилась root shell самого модема. Это была отдельная система mdm9607, а не Android на Rockchip.

Путь доступа получился с дополнительным звеном. USB-хостом для модема выступал Rockchip, поэтому временный ADB-клиент запускался на нём. Для его сервера выделили отдельный порт и пробросили его на рабочий компьютер. Это позволило исследовать внутренний USB-модем, не подменяя основной сеанс управления Android.

Один практический нюанс едва не запутал картину: такой сервер способен обнаружить несколько ADB-устройств, включая сам Android по TCP. Мы выбирали модем по фактическому USB transport, а не по случайному номеру из предыдущего вывода. После переподключения номер меняется.

Похожее правило действовало для AT-порта. У нас /dev/ttyUSB2 был занят Android-процессом rild. Свободным оказался /dev/ttyUSB3. Мы не отбирали порт у RIL: проверяли владельца, сохраняли настройки терминала и возвращали их после запросов. Для другого устройства это наблюдение придётся устанавливать заново — номер порта не является свойством модели на все случаи жизни.

Копия файлов — ещё не спасательный круг

Перед изменениями сохранили обычные файлы прошивки, системные исполняемые файлы и библиотеки. Получился архив примерно на 65 МиБ; для файлов и контейнера зафиксировали SHA-256. Радиосегменты лежали в /firmware/image.

Была и неудачная попытка получить более низкоуровневую копию. Чтение одного сырого MTD-раздела зависло, вслед за ним перестали нормально завершаться файловые ADB-запросы. AT-команды ещё отвечали, но программный перезапуск модема не восстановил систему полностью. Потребовалось отдельно снять и вернуть питание модема через проверенную цепь управления на нашей плате.

Причину зависания внутри драйвера мы не доказали. Делать из этого универсальный рецепт чтения NAND было бы неправильно. Сырые разделы повторно не читали и дальше работали с обычными файлами.

Поэтому граница резервирования у этого эксперимента вполне конкретная: исходные радиофайлы сохранены, полного проверенного EFS/QCN/NAND-образа и универсального способа восстановления нет. При живом Linux их можно вернуть. Если откажет сам путь доступа, ситуация сложнее. Это существенно отличает исследование одного экземпляра от готового способа массового обновления.

Улика нашлась быстро. Код — не сразу

В одном из сегментов прошивки обнаружились диагностические строки с почти исчерпывающим содержанием:

reg_sim.c:quectel_check_current_plmn_is_need_forbidden MCC =%d%d%d
reg_sim.c:Current PLMN is Russian PLMN ,Forbidden

Рядом были сообщения про запрещённую российскую PLMN в разных режимах выбора сети. PLMN — идентификатор мобильной сети, содержащий код страны MCC и код оператора MNC.

На этом легко было бы закончить расследование эффектным скриншотом. Однако строка в бинарнике доказывает только наличие строки. Она могла остаться от старой функции, неиспользуемой конфигурации или отключённого диагностического пути.

Строки находились в modem.b24, а ссылки на них — в диагностических структурах modem.b14. Прямой переход от этих данных к исполняемой проверке долго не получался. Мы даже рассматривали версию, что соответствующий код удалён оптимизацией, а сообщения остались.

Разобраться помог формат образа. Радиопрошивка была разбита на modem.b00, modem.b01 и другие сегменты. Их номера соответствуют записям в таблице program headers ELF. Чтобы восстановить расположение данных для анализа, нужны смещения и размеры из этой таблицы: простое склеивание файлов по порядку не воспроизводит исходную адресацию.

Ключевой сегмент modem.b21 занимал около 9,6 МиБ и был помечен как доступный для чтения, без флага исполнения. Но внутри него находился сжатый исполняемый код. Флаги описывали хранилище, а не свойства будущего распакованного содержимого.

В служебных таблицах нашлась привязка этого сегмента к виртуальному диапазону, начинающемуся с 0xd0000000. Она и вывела нас к q6zip — формату сжатия кода Qualcomm Hexagon.

Как мы добрались до исполняемой проверки

Для распаковки использовали открытый проект qualcomm-q6zip Willem Hengeveld. Важно было установить параметры именно нашей сборки: структура и служебные префиксы могут отличаться. Исходный проект.

В нашем сегменте оказалось 4174 страницы, два словаря на 1024 и 16384 слова, lookback-параметр 8. Первые 3715 сжатых блоков имели дополнительный восьмибайтовый префикс. После корректной распаковки получили около 16,3 МиБ кода и данных в ожидаемом виртуальном диапазоне.

Эти цифры не подбирались под желаемый результат. Мы сверяли заголовок, таблицу указателей, границу блоков с префиксом и размеры выходных страниц. Без этого дизассемблер может показать правдоподобные инструкции из неправильно интерпретированных байтов.

Распакованный код смотрели в Rizin с архитектурой Hexagon и правильной виртуальной базой. Здесь понадобилась ещё одна поправка к привычкам после ARM и x86: инструкции Hexagon исполняются пакетами. Соседние строки дизассемблера нельзя автоматически читать как обычную последовательность отдельных операций. Подготовка аргументов, например, может относиться к тому же пакету, что и вызов.

В итоге по адресу 0xd0239f38 нашлась небольшая функция, которая извлекала три цифры MCC из полубайтов аргумента. Её смысл после разбора оказался очень простым: вернуть признак запрета, если код страны равен 250 или 432.

Это Россия и Иран. Следующий вызывающий код использовал результат проверки на пути к диагностике запрета PLMN. Теперь у нас были не только слова в сегменте данных, но и действующее условие, которое с ними связывалось.

Цепочка доказательств: документ объясняет возможную политику, а строка, ссылки и исполняемая проверка устанавливают её присутствие в нашей сборке.

Откуда в заголовке один бит

Мы выбрали минимальное изменение в найденном условии. Вместо средней цифры 5 в сравнении с MCC 250 стали проверять 7. Таким образом, эта ветка стала соответствовать MCC 270, то есть Люксембургу. Проверка 432 осталась прежней.

Это точное описание эффекта: конкретная запись в проверке была перенесена с одного MCC на другой. Мы не переписывали идентификаторы SIM, не меняли передаваемый сетью код страны и не делали модем «устройством из другой страны». Не исследованные нами региональные механизмы от этого автоматически не исчезают.

Любопытная часть оказалась в машинном представлении. Для нужной инструкции замена константы 5 на 7 затрагивала один бит. Но инструкция лежала в сжатом коде, а значит, изменить бит в распакованном файле было только половиной задачи.

У q6zip есть словари, ссылки на предыдущие слова и непосредственные значения. Если нужная инструкция берётся из общего словаря, изменение записи может повлиять на другие места. Пересжатие всего сегмента, в свою очередь, добавило бы большой набор изменений с новым размещением блоков.

Мы проследили декодирование нужной страницы до конкретного слова. Оно оказалось отдельно записанным 32-битным литералом, а не ссылкой на общий словарь. Поэтому удалось изменить его представление непосредственно в исходном сжатом потоке.

После этого повторно распаковали изменённую страницу и побайтно сравнили результат. Поменялось ровно ожидаемое сравнение. Размер сегмента, словари, указатели страниц и служебные данные остались прежними. В сжатом modem.b21 различался действительно один бит.

Изменение минимально по объёму радиокода. Его смысл — MCC 250 → 270 в одной найденной ветке; это не универсальное отключение всех региональных ограничений.

Диагностический текст при этом остался прежним, как и часть аргументов логирования. Это сознательно ограничивало объём правки, но ещё раз напоминало: текст сообщения и фактическая логика — разные вещи.

Один бит в коде — три изменённых файла

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

В modem.b01 находились MBN-заголовок, таблица SHA-256 для ELF-сегментов, RSA-подпись и цепочка сертификатов. Таблица содержала 26 позиций; реальные непустые сегменты, которые она защищала, были проверены по исходным файлам. В modem.mdt дублировались заголовки и содержимое hash-сегмента: для этой сборки он в точности равнялся объединению modem.b00 и modem.b01.

Замена одного бита меняет SHA-256 сегмента. Значит, нужно обновить соответствующую запись таблицы, её копию в MDT и подпись над защищаемыми данными. Иначе минимальное изменение кода оставляет несогласованный комплект файлов.

Схема нашей сборки: изменяется полезная нагрузка, за ней — хеш, подпись и копия метаданных. «Один бит» не означает один изменённый бит во всём комплекте файлов.

Отдельно выяснили, что подпись образа использовала схему QPSA. В ней хеш MBN-заголовка и таблицы сегментов дополнительно обрабатывается с идентификаторами программного обеспечения и аппаратной платформы. Для нашего образа это SW_ID 2 и HW_ID 0. Полученный 32-байтовый результат подписывается RSA-2048 с PKCS#1 v1.5; обычная команда «подписать файл как SHA-256» не обязана воспроизвести этот формат.

Правильность трактовки проверили на исходном образе: восстановили подписанное значение через открытый ключ и сравнили с вычисленным самостоятельно. Только после совпадения имело смысл собирать изменённые метаданные.

В сертификатах нашлась неожиданная деталь. Цепочка содержала QPSA F4 TEST CA и QPSA F4 TEST ROOT. Одного слова TEST было бы мало. Мы извлекли открытый ключ промежуточного CA и побайтно сопоставили его с ключом из публичных тестовых материалов SecImage. Они совпали. Публичные тестовые материалы SecImage.

Это позволило выпустить новый конечный сертификат с собственным новым ключом, сохранив существенные атрибуты исходного сертификата и исходные CA/root, а затем сформировать согласованную подпись изменённого образа. В проверках участвовали и подпись сертификата, и специфическая подпись радиопрошивки. Сам формат QPSA можно сверить с открытой реализацией инструмента.

Мы не извлекали секретный производственный ключ из устройства и не ломали RSA. Здесь использовался уже публичный тестовый ключ, который совпал с CA в нашей цепочке. Из этого не следует, что другой модем с другим корнем доверия примет такую же процедуру.

Запрос состояния Secure Boot на нашем экземпляре также возвращал ноль. Но мы не стали делать из одного AT-ответа вывод, что проверки подписей отсутствуют во всех загрузочных слоях. Согласованный образ и проверка его реальной загрузки дали более определённый результат.

Между красивым файлом на компьютере и работающим модемом

Перед записью повторно сравнили исходные файлы непосредственно на модеме с сохранёнными копиями. Подготовленный комплект прошёл обратную распаковку, проверку сегментных хешей, цепочки сертификатов и подписи образа.

Нашлось и вполне приземлённое ограничение: на корневой файловой системе модема было около 8,6 МБ свободного места, а modem.b21 занимал больше 10 МБ. Полный временный файл с последующим переименованием туда не помещался.

Поэтому полезную нагрузку изменили на месте в обычном файле, а небольшие метаданные заменили через временные файлы и переименование. Исходные метаданные и исходное значение изменяемого байта сохранили на модеме, полную исходную нагрузку — на компьютере. До и после записи сверялись хеши; при ошибке предусматривался возврат исходных данных. Затем выполнили синхронизацию и вернули корневую систему в read-only.

Эта последовательность уменьшала риск, но не делала обновление атомарным. Три взаимосвязанных файла не заменяются одной транзакцией. Исчезновение питания посередине оставалось реальной проблемой — ещё одна причина не выдавать эксперимент за готовый механизм обновления устройств.

Загрузчики, сырые MTD-разделы, NV и IMEI при записи не менялись. После успешной проверки всего комплекта перезапустили только модем. Он заново появился на USB, вернул root shell и поднял DSP. Android продолжал работать с прежним boot ID.

Сначала появился Мегафон. Но ещё не LTE

Первая победа была скромнее заголовка. С SIM Мегафона появилась регистрация в домашней сети, присоединение к пакетной сети и адрес на интерфейсе модема. Android поднял usb0. Радиотехнология — HSDPA/WCDMA 900.

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

Но выдавать 3G за проверенный LTE было бы нечестно. При временном ограничении поиска только LTE модем оставался без обслуживания. Мы вернули автоматический выбор технологии. В исходном поиске Мегафон в этой точке вообще был виден только в 2G/3G, тогда как Tele2 был виден в LTE. Поэтому этот результат не доказывал наличие ещё одной программной блокировки.

Полноценный веб-доступ на карте Мегафона мы тоже не подтвердили: соответствующие запросы завершались тайм-аутами. Регистрация, IP-адрес и открывшийся сайт — разные результаты, и в журнале они так и остались разными.

Возвращаем Т‑Мобайл и проверяем именно интернет

Для LTE вернули активированную SIM Т‑Мобайла. После физической замены сначала появилось состояние CARD_IO_ERROR. Один перезапуск модема восстановил чтение карты. Перезапускать весь Android не понадобилось.

Дальше система справилась сама: RIL вернул контекст передачи данных с internet на tt, соответствующий уже выбранному Android-профилю. Наш дополнительный сценарий настройки увидел, что ожидаемого старого состояния уже нет, и завершился до записи. Это маленький, но полезный результат: условие перед изменением уберегло от ненужного повторного вмешательства.

SIM имела код оператора 25062, а обслуживающая сеть определилась как Tele2 25020. Для этого подключения такое различие оказалось нормальным: название поставщика услуги и идентификатор радиосети не обязаны совпадать.

Фактическое состояние было таким:

Важнее всего здесь две последние строки. Wi-Fi у робота продолжал работать, поэтому обычный запрос с Android мог бы успешно уйти через него и создать ложное ощущение победы.

Мы проверили сначала сам модем: HTTP и HTTPS к example.com с явной привязкой к сотовому интерфейсу rmnet_data0. Затем — Android. На нём не оказалось подходящего curl, поэтому запустили временную DEX-пробу отдельным процессом. Она создала один сокет с SO_BINDTODEVICE=usb0 и выполнила HTTP-запрос.

Ответ содержал статус 200 и ожидаемую страницу Example Domain. Системные маршруты, firewall и состояние Wi-Fi ради этой проверки не менялись. Разрешение DNS-имени в Android отдельно не изолировали по интерфейсу; привязка подтверждала путь самого TCP/HTTP-запроса.

До веб-запросов мы последовательно проверили чтение SIM, регистрацию, пакетное присоединение и сетевой интерфейс. Автоматическое переключение приложений с Wi-Fi на LTE — отдельный тест.

Кстати, ping до 1.1.1.1 ответа не дал. Если бы мы остановились на ICMP, могли бы записать рабочий веб-доступ в неудачу. В этом кейсе HTTP/HTTPS оказались лучшим критерием, чем один молчащий адрес.

Радиоусловия тоже не были образцовыми: один снимок показывал RSRP −114 дБм, RSRQ −18 дБ и SINR −6 дБ. Поэтому мы не делаем из успешного запроса вывод о скорости или долгосрочной устойчивости связи.

Закончили не на зелёной надписи

После проверки вернули исходный состав USB-интерфейсов модема и выключили временный внутренний ADB. Остановили отдельный сервер, убрали свой проброс порта и удалили HTTP-пробу. Автоматический выбор радиотехнологии и параметры терминала восстановили.

После изменения USB-конфигурации ещё раз проверили регистрацию, передачу данных и HTTP с Android через usb0: результат сохранился. Исходные радиофайлы и материалы для отката остались в резервной копии.

Итог для нашего экземпляра: EG25-GC с этой сборкой зарегистрировался в российской LTE-сети и передал реальный трафик после изменения найденного условия MCC. Дополнительно была подтверждена регистрация Мегафона в 3G.

GNSS после изменения мы не исследовали. Автоматический переход приложений между Wi-Fi и LTE не проверяли. Не измеряли скорость и не проводили длительный нагрузочный тест. Совместимость с другими аппаратными ревизиями, сборками и конфигурациями доверенной загрузки из этого опыта не следует.

Что в этом подходе полезнее самого бита

Для нас самым ценным оказался способ сужать задачу. Сначала разделить уровни: читается ли SIM, слышен ли эфир, проходит ли регистрация, появляется ли пакетная сессия, доходит ли запрос. Потом на каждом уровне искать наблюдение, способное изменить текущую версию.

Рабочая SIM в телефоне исключала часть бытовых причин. Вторая карта уменьшала вероятность ошибки одного профиля. Поиск сетей отделял полный отказ приёмника от проблемы регистрации. Документ производителя объяснял возможную политику, но собственная прошивка ещё требовала проверки. Строки указывали направление; распакованный код показал условие; запуск и запросы через нужный интерфейс подтвердили практический эффект.

Не менее полезно было вовремя разделять соседние проблемы. Android-bootloop оказался дефектом Incremental FS. Отсутствие LTE у одной SIM нельзя было автоматически записывать на счёт прошивки. Зависшее сырое чтение не превращало имеющуюся копию файлов в полный резервный образ. И даже корректная RSA-подпись на компьютере не заменяла проверку загрузки на устройстве.

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

Источники и инструменты

Основные наблюдения в статье относятся к нашему экземпляру и сохранённым журналам его исследования. Публичные материалы, которые помогли интерпретировать результаты:

• PCN Quectel 2022113001 — описание изменения региональной политики производителя.

• Случай с той же веткой GC на официальном форуме — похожие симптомы, а не доказательство для нашего устройства.

• Megi: Modem on PinePhone — архитектура EG25-G и ранее исследованный служебный доступ.

• Willem Hengeveld: qualcomm-q6zip — декодирование сжатого Hexagon-кода.

• Rizin 0.9.1 — дизассемблирование Hexagon.

• Публичные материалы SecImage / QPSA — сравнение тестового CA и разбор формата подписи.

Иллюстрации со схемами перерисованы по результатам нашего исследования. Готовая модифицированная прошивка и установочный патч к статье не прилагаются.