Хакатон по безопасности GPRS — отчёт

Кратко — до результата мы ещё не добрались, так что если ждёте готовых результатов, то можете дальше не читать.

Как и предполагалось, ни в понедельник, ни во вторник мы до результата дойти не успели. Что успели сделать и выяснить:

  1. Половина времени в понедельник и часть времени по вторник ушла на то, чтобы скомпилировать весь нужный софт, разобраться, как его запускать и подогнать параметры под наше железо. Так как софт совсем не продакшн и построен по принципу лоскутного одеяла, то это было не очень быстро.
  2. Долго выясняли, какой какой ARFCN (Absolute radio-frequency channel number, номер физического канала) нам записывать. Так как Airprobe не поддерживает EDGE, то нам нужны были телефоны с GPRS, но без EDGE. Таких телефонов у нас всего два — Siemens C60 и Benq-Siemens C72, и ни в одном (пока) нет разлоченного NetMonitor'а. Как выяснилось с помощью NetMonitor на других телефонах, все телефоны МТС в хакспейсе висят на одной и той же соте (ARFCN 753, GSM1800), и мы стали записывать эту частоту в надежде, что наш тестовый телефон тоже будет использовать именно её. Параллельно с записью стучались с Siemens C60 на ya.ru.
  3. После долгого рассматривания записанных данных в Wireshark, стало понятно, что можно было вообще не напрягаться с тестовым телефоном (но это было уже в середине дня вторника): (1) все управляющие сообщения используют стандартную систему кодирования/модуляции GSM, а не EDGE, (2) вокруг достаточно телефонов, постоянно генерирующих трафик, и (3) всё, что видно на основной частоте соты (у нас ARFCN 753) — это перевод дальнейшего общения про GPRS/EDGE (Immediate Assignment) на другую частоту (у нас ARFCN 52, GSM900). Выдержки из декодированных Immediate Assignment: короткая, длинная. К GPRS относятся Immediate Assignment с упоминанием Packet Channel Description, а не Channel Description.
  4. Записали ARFCN 52. Его Airprobe не декодирует, но про это ниже.
  5. Сейчас Airprobe всегда подразумевает, что в записанном канале есть FCCH (канал синхронизации частоты) и SCH (канал синхронизации логических часов TDMA). При чтении записи Airprobe сначала ищет в записи FCCH, а затем декодирует идущий сразу за ним SCH, и только после этого может начать декодировать данные. Важно, что FCCH и SCH вещаются только на основной частоте соты, и отсутствуют на остальных частотах, на которых вещает сота. Обычный телефон, прыгая с одной частоты на другую, сохраняет синхронизацию как по частоте, так и по времени. В нашем же случае, необходимо синхронизировать записи на основной частоте и на частоте GPRS-канала, чтобы после получения синхронизации на основной частоте перескочить на запись GPRS-канала без потери синхронизации.
  6. Положительная новость — если не используется PDCCH, управляющий канал GPRS фиксирован на одной частоте (у нас ARFCN 52, GSM900) и одном тайм-слоте (у нас TS7), т.е. по крайней мере на этом этапе у нас не будет проблем с прыжками по частоте (hoping channels).
  7. На этом в данный момент всё. Дальше будем разбираться, как с помощью USRP записывать два канала одновременно (см пример rx_multi_samples к UHD), модифицировать Airprobe для работы с несколькими частотными каналами и модифицировать Airprobe для записи всех таймслотов без исключения в файл в формате, пригодном для gprsdecode.

Спаисбо всем, кто пришёл в понедельник, чтобы совместно решить задачу. Вместе всегда веселее. Отдельное спасибо Sylvain Munaut за консультации в реальном времени.

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

Оставить комментарий

Почта (не публикуется) Обязательные поля помечены *

Вы можете использовать эти HTML теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>