Взлом автомобильной сигнализации с помощью MacBook

Среди программного обеспечения для исследования радиосигнала стандартом де-факто является GNU Radio. Этот комплекс дает очень крутой набор инструментов, начиная от фильтров и простых математических преобразований сигнала и заканчивая интерфейсами для трансляции данных в сеть и написания своих собственных модулей. Его и будем использовать.

УСТАНОВКА

Установку будем проводить на OS X. Если у тебя нет Xcode, то нужно его установить, так как вместе с ним поставляется компилятор, который нам потребуется. Берем из App Store. Поскольку мы будем использовать GNU Radio, понадобится графическая система X11 (скачать можно тут. Теперь установим основные библиотеки (MacPorts, если вдруг нет, берем c macports.org):

Код:

sudo port install bladeRF +tecla

Потом нужно дописать в файл конфигурации командной оболочки .bashrc (при отсутствии) следующее:

export DISPLAY=:0.0
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
export MANPATH=/opt/local/share/man:$MANPATH
export PYTHONPATH=/opt/local/Library/Frameworks/Python.framework/
   Versions/2.7/lib/python2.7/site-packages:/opt/local/lib/
   python2.7/site-packages:${PYTHONPATH}

Если все прошло успешно, на следующую команду должен быть примерно такой ответ:

bladeRF-cli -p
   Backend:        libusb
   Serial:         d1ece1003730a1a27f9beeba1f511413
   USB Bus:        4
   USB Address:    8

Полную же информацию можно посмотреть, перейдя в интерактивный режим:

bladeRF-cli -i

И напечатав info и version:

Здесь обратим внимание на строчки:

FPGA size: 40 KLE
FPGA version: Unknown (FPGA not loaded)

Важный момент: для работы в наше устройство нужно подгружать образ FPGA, который требуется отдельно скачать, например отсюда. В зависимости от размера FPGA (у нас 40 KLE) выбираем соответствующий файл, в нашем случае hostedx40-latest.rbf. Скачиваем и подгружаем командой

bladeRF-cli -l hostedx40-latest.rbf

На устройстве должны замигать огоньки — теперь оно готово к работе. Остается установить GNU Radio, что можно сделать командой.

sudo port install gnuradio +grc +swig +wxgui +qtgui +python27

Вдогонку нужно добавить в GNU Radio поддержку самого bladeRF с помощью модуля gr-osmosdr:

Код:

sudo port install gr-osmosdr

Теперь можно запустить программу и приступить к сути:

gnuradio-companion

ТЮНЕР ДЛЯ ПОИСКА РАБОЧЕГО СИГНАЛА

Сначала сделаем сканер эфира с визуализацией частотного спектра, он поможет нам отыскать сигнал от автобрелока для исследования. Для этого в правом окне GNU Radio выбираем osmocom Sink — это модель самого устройства, перетягиваем блок на рабочую область и в свойствах блока указываем используемое устройство (у меня bladeRF, и в графе Device Arguments будет bladerf=0), частоту (Ch0: Frequency) и ширину диапазона, который будет видеть сканер. Остальные настройки можно пока оставить по умолчанию.

[ad name=»Responbl»]

Управление значениями частоизменяемых переменных обычно выносится на рабочую область: делаются слайдеры или просто блоки с прописанными значениями. Поскольку у нас сканер, сделаем слайдер, которым в процессе работы можно будет изменять рабочую частоту: просто перетягиваем блок WX GUI Slider и устанавливаем границы его действия, значение по умолчанию и айдишник — например, freq. В osmocom Sink в поле частоты прямо так и пишем — freq. Добавим блок WX GUI Waterfall Sink, отвечающий за графическое отображение сигнала, и соединим линией с osmocom Sink. Чтобы не анализировать каждый раз сигнал вживую, обычно делается его запись в файл, а затем она воспроизводится на стадии анализа.

Для этого добавим блок File Sink с указанием имени файла, в который будут писаться данные в сыром виде, сделаем связь, и сканер готов! Остается запустить, после чего, двигая ползунком, найти рабочую частоту и сделать запись сигнала. Сохраним полученную схему как tuner.grc, она должна выглядеть примерно как на первой картинке. Вид тюнера в работе можно посмотреть на второй картинке.

АНАЛИЗ ПОЛУЧЕННОГО СИГНАЛА

Создадим новую схему (например, под именем radioaudi-reversing.grc), где сигнал будет браться уже не с bladeRF, а из записанного файла. Для этого используем блок File Source, которому просто передадим имя файла. Теперь начинается самое интересное. При переводе полученной на предыдущем этапе (второе изображение) в зависимость уровня сигнала от времени его значение берется как сумма всех амплитуд по всем охватываемым частотам спектра для каждого момента времени, поэтому исследуемый сигнал требуется отделить от шума. Для этого можно применить модуль Low Pass Filter, но он отрезает частоты, оставляя коридор вокруг нулевой частоты, то есть ровно по центру (0 МГц).

У нас в любом случае в центре оказывается сигнал от постоянного тока в электрической схеме устройства, и изменением параметра freq проблему не решить. Но весь спектр можно сдвинуть, домножая поступающий из osmocom Sink сигнал на другой, с частотой, равной требуемому сдвигу (это математика). Для этого добавим блок Multiply и Signal Source, на вход первого подадим сигнал второго вместе с выходом File Source. Выход Multiply, в свою очередь, прокинем на Low Pass Filter. Здесь я выбрал частоту среза 10 кГц (значение 10e3) и ширину перехода 1 кГц (значение 1e3, этот параметр отвечает за то, как резко фильтр обрезает сигнал, то есть насколько размыты края граничной области).

Другой важный параметр — частота Signal Source — то значение, на которое как раз будет сдвигаться имеющийся сигнал. Имеет смысл вынести его на рабочую область со слайдером, так же как freq, под именем, например, freq_0. Выход Low Pass Filter теперь просто направляем на WX GUI Waterfall Sink — полезный сигнал должен попадать ровнопосередине, на условной частоте в 0 МГц.

[ad name=»Responbl»]

Ура! На этом этапе мы уже можем вплотную подобраться к анализу сигнала. Перетащим на рабочую область WX GUI Scope Sink и соединим его с выходом Multiply через блок Complex to Mag, который служит, как ты догадываешься, для перевода значений сигнала из комплексной области в область более удобных для оперирования вещественных значений. На изображении можно посмотреть, как это должно выглядеть.

К счастью, данные у нас передаются с использованием амплитудной модуляции и есть только два уровня, поэтому мы можем сразу перейти к бинарному представлению. Для этого направим выход Complex to Mag на блок Binary Slicer, который преобразует последовательность амплитуд сигнала в последовательность нулей и единиц в зависимости от того, больше нуля значение или нет. Так как у нас все значения амплитуд сигнала больше нуля, с помощью простого арифметического блока Add const со значением примерно -170m опустим график, чтобы Binary Slicer было что различать. Выход последнего направим в файл через уже знакомый нам блок File Sink.

Заметим, что подобная схема на практике усложняется такими модулями, как Rational Resampler и Throttle. Первый позволяет снизить частоту дискретизации сигнала для того, чтобы не оперировать в дальнейшем избыточными данными, второй по сути работает так же и используется для снижения нагрузки на процессор в случаях, когда не требуется обрабатывать весь поток данных целиком без пропуска значений (например, достаточно только выводить данные на экран, как у нас). Также стоит отметить, что для сдвига частоты считается более корректным использовать блок Frequency Xlating FIR Filter, но ради наглядности мыиспользуем для этого Multiply.

На экране Waterfall Plot на нулевой секунде можно заметить полезный сигнал. На графике Scope Plot он отображается как зависимость амплитуды от времени.

ИНТЕРПРЕТАЦИЯ ПОЛУЧЕННЫХ ДАННЫХ

Итак, мы получили файл с последовательностью байтов, отражающих сигнал в бинарной форме. 0x01 — единица, 0x00 — ноль. Для чтения составим на Питоне простенький скрипт, который будет последовательность единиц и нулей свыше определенного порога интерпретировать как 1 или 0, а также разделять различные сигналы между собой.

При представлении полученных данных в шестнадцатеричном виде получаем последовательности:

2e23a99426bd8018

2e23a929426b805e

2e23a91f29428039

2e23a9031f298058

2e23a9cf031f809e

2e23a932cf0380b3

2e23a90132cf80b1

2e23a9ab013280f6

2e23a9fab0138040

2e23a90fab0180c8

2e23a9a0fab080fc

2e23a94a0fab80a7

2e23a9234a0f802b

2e23a9a234a08022

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

ЗАКЛЮЧЕНИЕ

Как видим, автосигнализация имеет достаточно неплохую защиту, поскольку существует 25*8 ~ триллион возможных вариантов для перебора. Насколько быстро их можно было бы перебрать? Число измерений 0 и 1 для одной последовательности сигнала равняется примерно 45 тысячам, что вместе с частотой семплирования 400 кГц (после децимации исходных 2 МГц Ration Resampler’ом на 5) дает нам 45 000 * (1/400 000) = 0,1125 с.

[ad name=»Responbl»]

Полное время перебора при условии, что генерируемые сигналы будут идти друг за другом, составляет 0,1125 * 1012 ~ 1,12511 с ~ 3500 лет. В текущем виде копать следует в сторону уменьшения числа вариантов брутфорса или ускорения процедуры. Найдут ли что-то независимые исследователи? Время покажет.