Возможность заглянуть «под капот» и узнать, как работает тот или иной компонент программы, позволяет не только находить и исправлять всевозможные ошибки, но и убедиться в отсутствии так называемых «закладок» в коде.
Ни для кого не секрет, что в уже привычных для большинства из нас смартфонах кроме основного процессора существует отдельный модуль связи, благодаря которому смартфон все еще остается телефоном. Вне зависимости от основной операционной системы, будь то Android или iOS, данный модуль чаще всего работает под управлением проприетарной операционной системы с закрытым исходным кодом, и берет на себя всю работу, связанную с голосовыми вызовами, SMS-сообщениями и мобильным Интернетом.
В отличие от проприетарного программного обеспечения проекты с открытым исходным кодом всегда получают больше внимания со стороны исследователей безопасности. Возможность заглянуть «под капот» и узнать, как работает тот или иной компонент программы, позволяет не только находить и исправлять всевозможные ошибки, но и убедиться в отсутствии так называемых «закладок» в коде. Кроме того, открытый исходный код позволяет начинающим разработчикам учиться на примере более опытных, используя результаты их работы в качестве опоры.
Введение в проект OsmocomBB
Именно поэтому в уже далеком 2008 году начал зарождаться проект Osmocom — Open Source Mobile Communications. Изначально все внимание разработчиков было сфокусировано на единственном дочернем проекте OpenBSC, который позволял запускать свою сотовую связь на многокилограммовых коммерческих базовых станциях и впервые был представлен в 2008 году на ежегодной конференции Chaos Communication Congress.
Со временем Osmocom вышел за рамки одного проекта, и сегодня объединяет десятки дочерних проектов, одним из которых является OsmocomBB — свободная реализация стека GSM для мобильных телефонов с открытым исходным кодом. В отличие от своих предшественников, таких как TSM30, MADos для Nokia 33XX и Airprobe, рассматриваемый нами проект получил гораздо больше внимания со стороны исследователей и разработчиков, и, более того, продолжает развиваться сейчас.
Изначально основной задачей OsmocomBB являлось создание полноценной прошивки для сотовых телефонов с открытым исходным кодом, включая графический интерфейс и другие специфичные для них компоненты, и упором на альтернативную реализацию стека протоколов GSM. Однако данная идея не встретила бурной реакции со стороны потенциальных пользователей, поэтому сегодня OsmocomBB — это незаменимый набор инструментов для исследований и одновременно неплохая база знаний для новичков в GSM.
С помощью OsmocomBB можно оценить безопасность той или иной сети стандарта GSM, а также на практике изучать, как работает радиоинтерфейс (Um-интерфейс) в сотовых сетях. Какое шифрование используется и используется ли оно вообще? Как часто изменяются ключи шифрования и временные идентификаторы абонентов? Какова вероятность того, что голосовой вызов или SMS-сообщение будут перехвачены или, например, подделаны злоумышленником? На все эти вопросы и многие другие можно довольно быстро найти ответ с помощью OsmocomBB, и это только один пример из возможных способов его применения. Из нетипичных примеров можно выделить: запуск небольшой базовой станции GSM, исследование безопасности SIM-карт и сниффинг трафика.
Основной аппаратной платформой OsmocomBB, по аналогии с проектом Aircrack-ng и сетевыми картами, являются мобильные телефоны на базе чипсета Calypso, преимущественно Motorola C1XX. Решение использовать именно телефоны было принято на начальном этапе разработки проекта, преимущественно в пользу скорости реализации, поскольку процесс проектирования и производства нового оборудования мог затянуться надолго. К тому же, тогда в свободном доступе уже были «утекшие» части исходного кода и спецификации чипсета Calypso, что способствовало реверс-инжинирингу прошивки и всей дальнейшей разработке.
Однако у данного решения есть своя цена. Телефоны на базе описанного выше чипсета больше не производятся, что вынуждает искать бывшие в употреблении модели. Более того, текущая реализация физического уровня стека GSM в основном опирается на DSP (Digital Signaling Processor) — сигнальный процессор, который по-прежнему исполняет неизученный до конца проприетарный код. Оба перечисленных фактора негативно влияют на развитие проекта, ограничивая его потенциальные возможности и усложняя порог вхождения как сторонних разработчиков, так и пользователей проекта в целом. Например, реализация поддержки GPRS невозможна без изменения прошивки DSP.
Ветер перемен — новая аппаратная платформа
Программная часть проекта состоит из множества отдельных приложений, у каждого из которых свое конкретное предназначение. Часть приложений работает непосредственно на компьютере, в любой UNIX-подобной среде. Другая часть представлена в виде прошивок, загружаемых в телефон. А взаимосвязь между ними осуществляется через последовательный порт телефона, который совмещен с разъемом подключения гарнитуры. Иными словами, ничем непримечательный TRS-разъем (micro-jack, 2,5 мм) может использоваться не только для передачи звука, но и данных! Похожая технология используется и в современных смартфонах, позволяя подключать наушники с кнопками, монопод для селфи и прочие аксессуары.
Отсутствие других интерфейсов, таких как USB, и необходимость использования последовательного порта так же накладывают определенные ограничения, наиболее значимым из которых является скорость передачи данных. Например, частично возможности сниффинга и запуска базовой станции ограничены именно из-за низкой пропускной способности интерфейса. Более того, готовый кабель для подключения телефона к USB найти довольно сложно, и в большинстве случаев его приходится делать самостоятельно, что к тому же усложняет порог вхождения пользователей.
Совокупность этих факторов в определенный момент породила идею перехода на другую аппаратную платформу, которая не ограничивала бы проект ни программно и не аппаратно, а также была бы доступна для всех, как в плане производства, так и в плане цены. И технология SDR (Software Defined Radio), в связи с бурным ростом своей популярности и доступности, как раз соответствует данным требованиям.
Концепция SDR заключается в разработке радиооборудования общего назначения, т.е. не привязанного к конкретному стандарту связи. Благодаря этому технология получила большое распространение как среди радиолюбителей, так и среди производителей коммерческого оборудования. Уже сегодня SDR активно используется в сотовой связи, а именно для развертывания сетей стандартов GSM, UMTS и LTE.
Сама идея разработки и запуска мобильного телефона GSM, реализуемого проектом OsmocomBB, на базе SDR не нова. Данное направление когда-то развивалось разработчиками Osmocom, но было заброшено. Кроме того, известно об аналогичной исследовательской работе Швейцарской лаборатории, которая, к сожалению, остановилась на уровне Proof-of-Concept. Но мы все-таки решили возобновить работу над данным направлением, поставив перед собой задачу реализации поддержки новой аппаратной платформы для OsmocomBB на базе SDR, идентичной чипсету Calypso с точки зрения обратной совместимости, и более открытой к модификациям одновременно.
В дальнейшей части данной статьи будет вкратце описан процесс разработки новой платформы, а также проблемы, с которыми мы столкнулись, и способы их решения. В качестве заключения, будут предоставлены результаты, которых удалось достичь, ограничения текущей реализации, идеи для дальнейшей разработки, а также небольшая подсказка, описывающая порядок действий для запуска OsmocomBB на SDR.
История проекта
Как уже говорилось ранее, OsmocomBB предоставляет два типа приложений: одни работают на стороне компьютера, другие загружаются в телефон в составе альтернативной прошивки. А взаимодействие между ними реализуется небольшой программой osmocon (от слова connection), которая обеспечивает их взаимное соединение через последовательный порт. Само взаимодействие осуществляется посредством простого бинарного протокола L1CTL (GSM Layer 1 Control), где существует всего три типа сообщений: запрос (REQ), ответ (CONF) и уведомление (IND).
Идею такого посредничества было решено сохранить, как и сам протокол, чтобы обеспечить «прозрачную» совместимость с имеющимися приложениями. В результате чего, было реализовано новое приложение — trxcon, которое, словно мост, работает между высокоуровневыми приложениями (такими как mobile и ccch_scan) и трансивером — отдельным приложением, управляющим SDR. Отсюда и происходит название trxcon (transceiver connection).
Трансивер является отдельной программой, которая выполняет низкоуровневые задачи физического уровня GSM, такие как частотно-временная синхронизация с сетью, обнаружение и демодуляция сигнала, модуляция и передача исходящего сигнала. Из готовых решений, существует два подходящих проекта: OsmoTRX и GR-GSM. Первый является улучшенной модификацией трансивера из проекта OpenBTS, и сейчас используется проектами Osmocom для запуска базовой станции; второй предоставляет набор блоков GNU Radio для приема и декодирования сигналов GSM.
Несмотря на полноту реализации и поддержку передачи сигнала «из коробки», OsmoTRX вряд ли может порадовать разработчика чистотой и читабельностью исходного кода — гремучая смесь Си и С++! Например, изменение сравнительно небольшого участка кода может потребовать изучения всей иерархии классов, в то время как GR-GSM предоставляет несравнимую с OsmoTRX модульность и свободу модификаций. Тем не менее, OsmoTRX все равно имеет ряд преимуществ, наиболее важными из которых являются производительность, низкие требования к ресурсам системы и сравнительно меньший размер исполняемого кода, а также его зависимостей. Все это делает проект достаточно дружелюбным к встраиванию в системы с ограниченными ресурсами, на фоне чего GNU Radio выглядит огромным и прожорливым монстром. Изначально вся разработка была ориентирована именно на OsmoTRX, однако итоговый выбор был сделан в пользу использования второго проекта в качестве трансивера.
Для обеспечения обратной совместимости, в связывающем приложении trxcon был реализован интерфейс TRX, который так же используется в проектах OsmoTRX, OsmoBTS и OpenBTS. Данный интерфейс для каждого соединения подразумевает использование трех UDP-сокетов, у каждого из которых своя специфичная задача. Одним из них является интерфейс CTRL, который позволяет управлять трансивером (настройка частоты, усиления, и т.д.). Другой называется DATA, и согласно названию обеспечивает обмен информацией, которую нужно передать (Uplink) или которая уже была принята (Downlink). Последний, CLCK, используется для передачи временных меток от трансивера.
Для GR-GSM было реализовано новое приложение grgsm_trx, задачей которого является инициализация базового набора блоков (flow-graph), а также предоставление TRX-интерфейса для внешнего управляющего приложения, в нашем случае – trxcon. Сам flow-graph изначально состоял только из блоков для приема, т.е. обнаружения и демодуляции, наименьших порций информации физического интерфейса GSM — bursts. Каждый burst на выходе демодулятора представляет собой битовую последовательность, состоящую в основном из полезной нагрузки и мидамбулы, которая позволяет приемнику синхронизироваться с передатчиком, но в отличие от преамбулы находится в середине.
На данном этапе разработки проекта высокоуровневые приложения, такие как ccch_scan, уже могли настроить SDR на определенную частоту, запустить процесс синхронизации с базовой станцией и демодуляцию принимаемого сигнала. Однако вместе с первыми успехами появились и первые трудности. Поскольку большая часть реализации физического уровня в OsmocomBB ранее «опиралась» на DSP телефона, кодирование и декодирование пакетов согласно спецификации GSM 05.03 отдельно реализовано не было – его выполнял проприетарный код.
В итоге, только что реализованный трансивер передает верхним слоям реализации битовые порции информации, т.е. bursts, а текущая реализация верхних слоев ждет от физического уровня байтовые LAPDm-пакеты (в основном, по 23 байта каждый). Более того, работа трансивера подразумевает точную временную синхронизацию (TDMA – Time Division Multiple Access) с базовой станцией, в то время как высокоуровневые приложения об этом даже и не “подозревают” и передают исходящие пакеты тогда, когда им это необходимо.
Для устранения получившегося «провала» в реализации был реализован TDMA-планировщик, который принимает LAPDm-пакеты от высокоуровневых приложений, кодирует их в bursts и передает трансиверу, определяя время их передачи с помощью номеров фрейма и таймслота, а также собирает воедино bursts, приходящие от трансивера, декодирует их и отправляет верхним слоям. Под кодированием и декодированием согласно GSM 05.03 подразумевается создание помехоустойчивых битовых последовательностей (путем добавления избыточной информации), а также восстановление LAPDm-пакетов из принятых зашумленных последовательностей с помощью алгоритма Витерби соответственно.
После этого, прием все-таки заработал! Но самой главной возможности, которая просто необходима для работы мобильного телефона, по-прежнему не хватало — возможности передавать данные. Проблема в том, что изначально в GR-GSM отсутствовали блоки, которые позволили бы модулировать и передавать сигнал. И к счастью автор проекта, Piotr Krysik, поддержал идею их реализации, в результате чего дальнейшая работа над проектом продолжалась совместно с ним.
Чтобы зря не терять время, пока возможность передачи данных отсутствовала и шла работа над ее реализацией, было разработано временное, но, как оказалось позже, очень полезное решение — набор инструментов для эмуляции трансивера, т.е. виртуальный Um-интерфейс. Поскольку OsmocomBB, как и OsmoBTS, теперь поддерживает TRX-интерфейс, оба проекта можно легко соединить между собой: каждый Downlink burst со стороны OsmoBTS передавать приложению trxcon, а каждый Uplink burst со стороны OsmocomBB передавать OsmoBTS. Простое приложение, написанное на языке Python и получившее название FakeTRX, позволило запускать виртуальную GSM-сеть без какого-либо оборудования!
Однако решение данной проблемы все же было найдено, и заключается оно в использовании аппаратного времени (hardware clock) SDR-девайсов, таких как USRP, на основе которого каждый принимаемый burst получает «штамп» текущего аппаратного времени. Сопоставив эти штампы и текущий номер фрейма, декодированный из SCH burst, можно выполнять коррекцию и назначить точный момент передачи исходящих порций информации. Проблема только в том, что стандартные блоки GNU Radio, предназначенные для взаимодействия с SDR, не поддерживают временные штампы, поэтому их пришлось заменить на UHD Source и Sink, ограничившись поддержкой устройств семейства USRP.
В итоге когда трансивер был готов к работе, пришло время выходить за рамки виртуального Um-интерфейса. Но, как говорится, первый блин комом, поэтому первая попытка «собрать все воедино» и запустить проект на реальном оборудовании конечно же не удалась. Из виду была упущена особенность технологии временного разделения в GSM: отсчет времени для передаваемого телефоном сигнала, т.е. Uplink, специально замедлен относительно принимаемого, т.е. Downlink, на три таймслота, что дает телефонам с полудуплексным модулем связи необходимый запас времени на перестройку частоты. После небольшой коррекции проект все-таки заработал! Впервые с помощью OsmocomBB и SDR удалось передать SMS-сообщение и выполнить первый голосовой звонок.
Результаты
В результате проделанной работы удалось создать своего рода мост между OsmocomBB и SDR-трансиверами, работающими через драйвер UHD (Universal Hardware Driver). Были реализованы основные компоненты физического уровня GSM, необходимые для работы высокоуровневых приложений, таких как ccch_scan, cbch_scan и mobile. Все наработки проекта были опубликованы в открытом доступе в составе основного репозитория OsmocomBB.
Теперь, используя SDR в качестве аппаратной платформы для OsmocomBB, становится возможным запуск полностью «прозрачного» стека протоколов GSM, без проприетарных компонентов с закрытым исходным кодом, таких как DSP телефонов на базе чипсета Calypso, и одновременно с возможностью отладки и модификации каждого конкретного элемента реализации «на лету». К тому же, перед разработчиками и исследователями открываются новые горизонты, например:
- запуск сети и телефона в других диапазонах частот (например, 2.4 Ггц);
- интеграция альтернативных звуковых кодеков (например, Speex или Opus);
- реализация стека GPRS / EGPRS.
Упомянутый выше инструментарий для создания виртуального Um-интерфейса тоже опубликован в репозитории проекта и может пригодиться как опытным разработчикам, например, для симуляции необходимых уровней нагрузки на различные компоненты инфраструктуры сотовой сети и тестирования их стабильности, так и начинающим пользователям, которые могут начать изучение GSM на практике без необходимости искать и приобретать различное оборудование для этого.
Однако текущая реализация новой аппаратной платформы для OsmocomBB все же не лишена определенных ограничений, большая часть из которых исходят от самой технологии SDR. Например, большинство доступных SDR-плат, таких как USRP, UmTRX, LimeSDR, и т.д., имеют относительно малую мощность передаваемого сигнала, если сравнивать ее с максимальной мощностью передачи обычных телефонов. Еще одним «пробелом» в реализации является отсутствие поддержки технологии Frequency Hopping, которая предполагает использование абонентом сразу нескольких базовых станций на разных частотах, что позволяет уменьшить уровень интерференции и усложнить перехват сигнала. Ее можно встретить в сетях большинства современных операторов, к тому же, спецификации GSM описывают поддержку данной технологии как обязательной для каждого телефона. И если проблему с мощностью сигнала можно решить с помощью усилителей или ограничившись использованием лабораторной базовой станции, то реализация поддержки Frequency Hopping требует гораздо больших усилий.
Среди планов дальнейшего развития проекта:
- реализация поддержки физических (не виртуальных) SIM-карт;
- расширение списка поддерживаемых SDR-девайсов;
- реализация поддержки CSD (Circuit Switched Data);
- реализация встраиваемого трансивера на базе OsmoTRX;
- реализация поддержки GPRS / EDGE.
Вместо заключения
И напоследок несколько советов о том, как запустить результаты проделанной работы на своем SDR. Для начала предлагаем поэкспериментировать с виртуальным Um-интерфейсом с помощью разработанного нами TRX Toolkit.
Для этого понадобится не только OsmocomBB, но и весь набор компонентов центральной инфраструктуры сети от Osmocom: либо OsmoNiTB (Network in The Box), либо все компоненты по отдельности, включая BTS, BSC, MSC, MGW, HLR, и т.д. Инструкции по сборке исходных кодов можно найти на сайте проекта или воспользоваться готовыми пакетами для дистрибутивов Debian, Ubuntu или OpenSUSE.
Для тестирования реализации с собственной сети, подойдет любая доступная реализация сетевого стека GSM, например, Osmocom, OpenBTS или YateBTS. Запуск своей сети требует наличия отдельного SDR-девайса, или коммерческой базовой станции, например, nanoBTS. Тестировать проект в реальных сетях операторов настоятельно не рекомендуется, ввиду описанных выше ограничений и возможных недоработок.
Для сборки трансивера потребуется установка GNU Radio и сборка отдельной ветки проекта GR-GSM из исходных кодов.
Первоисточник:
