Кратко — до результата мы ещё не добрались, так что если ждёте готовых результатов, то можете дальше не читать.
Как и предполагалось, ни в понедельник, ни во вторник мы до результата дойти не успели. Что успели сделать и выяснить:
- Половина времени в понедельник и часть времени по вторник ушла на то, чтобы скомпилировать весь нужный софт, разобраться, как его запускать и подогнать параметры под наше железо. Так как софт совсем не продакшн и построен по принципу лоскутного одеяла, то это было не очень быстро.
- Долго выясняли, какой какой ARFCN (Absolute radio-frequency channel number, номер физического канала) нам записывать. Так как Airprobe не поддерживает EDGE, то нам нужны были телефоны с GPRS, но без EDGE. Таких телефонов у нас всего два — Siemens C60 и Benq-Siemens C72, и ни в одном (пока) нет разлоченного NetMonitor'а. Как выяснилось с помощью NetMonitor на других телефонах, все телефоны МТС в хакспейсе висят на одной и той же соте (ARFCN 753, GSM1800), и мы стали записывать эту частоту в надежде, что наш тестовый телефон тоже будет использовать именно её. Параллельно с записью стучались с Siemens C60 на ya.ru.
- После долгого рассматривания записанных данных в 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.
- Записали ARFCN 52. Его Airprobe не декодирует, но про это ниже.
- Сейчас Airprobe всегда подразумевает, что в записанном канале есть FCCH (канал синхронизации частоты) и SCH (канал синхронизации логических часов TDMA). При чтении записи Airprobe сначала ищет в записи FCCH, а затем декодирует идущий сразу за ним SCH, и только после этого может начать декодировать данные. Важно, что FCCH и SCH вещаются только на основной частоте соты, и отсутствуют на остальных частотах, на которых вещает сота. Обычный телефон, прыгая с одной частоты на другую, сохраняет синхронизацию как по частоте, так и по времени. В нашем же случае, необходимо синхронизировать записи на основной частоте и на частоте GPRS-канала, чтобы после получения синхронизации на основной частоте перескочить на запись GPRS-канала без потери синхронизации.
- Положительная новость — если не используется PDCCH, управляющий канал GPRS фиксирован на одной частоте (у нас ARFCN 52, GSM900) и одном тайм-слоте (у нас TS7), т.е. по крайней мере на этом этапе у нас не будет проблем с прыжками по частоте (hoping channels).
- На этом в данный момент всё. Дальше будем разбираться, как с помощью USRP записывать два канала одновременно (см пример rx_multi_samples к UHD), модифицировать Airprobe для работы с несколькими частотными каналами и модифицировать Airprobe для записи всех таймслотов без исключения в файл в формате, пригодном для gprsdecode.
Спаисбо всем, кто пришёл в понедельник, чтобы совместно решить задачу. Вместе всегда веселее. Отдельное спасибо Sylvain Munaut за консультации в реальном времени.
Полагаю, что мы продолжим практику таких хакатонов, когда я вернусь из очередной поездки в конце сентября.