С появлением в широком доступе таких устройств, как bladeRF, HackRF, RTL-SDR, а также программных комплексов вроде GNU Radio реверс-инжиниринг данных радиоэфира становится очень простым и увлекательным. Об этом и поговорим сегодня.
ПРОВОДИМ ТЕСТОВЫЙ ВЗЛОМ АВТОМОБИЛЬНОЙ СИГНАЛИЗАЦИИ
При помощи bladeRF, HackRF (в меньшей степени RTL-SDR) оказывается возможным полноценное наблюдение за радиоэфиром, а также взаимодействие с ним. Энтузиасты уже написали софт, который позволяет интерпретировать сигналы GPS, поднимает на компьютере стек Bluetooth, Wi-Fi и дает возможность создать свою собственную базовую станцию GSM, а один парень даже перехватил сигналы с метеоспутника и расшифровал передаваемые фотоснимки — примеров много.
Среди программного обеспечения для исследования радиосигнала стандартом де-факто является 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, она должна выглядеть примерно как на рис. 1. Вид тюнера в работе можно посмотреть на рис. 2.
АНАЛИЗ ПОЛУЧЕННОГО СИГНАЛА
Создадим новую схему (например, под именем radioaudi-reversing.grc), где сигнал будет браться уже не с bladeRF, а из записанного файла. Для этого используем блок File Source, которому просто передадим имя файла. Теперь начинается самое интересное. При переводе полученной на предыдущем этапе «картины» (рис. 2) в зависимость уровня сигнала от времени его значение берется как сумма всех амплитуд по всем охватываемым частотам спектра для каждого момента времени, поэтому исследуемый сигнал требуется отделить от шума. Для этого можно применить модуль Low Pass Filter, но он отрезает частоты, оставляя коридор вокруг нулевой частоты, то есть ровно по центру (0 МГц).
[ad name=»Responbl»]
У нас в любом случае в центре оказывается сигнал от постоянного тока в электрической схеме устройства, и изменением параметра 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 МГц.
Ура! На этом этапе мы уже можем вплотную подобраться к анализу сигнала. Перетащим на рабочую область WX GUI Scope Sink и соединим его с выходом Multiply через блок Complex to Mag, который служит, как ты догадываешься, для перевода значений сигнала из комплексной области в область более удобных для оперирования вещественных значений. На рис. 3 можно посмотреть, как это должно выглядеть.
[ad name=»Responbl»]
К счастью, данные у нас передаются с использованием амплитудной модуляции и есть только два уровня, поэтому мы можем сразу перейти к бинарному представлению. Для этого направим выход 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 с. Полное время перебора при условии, что генерируемые сигналы будут идти друг за другом, составляет 0,1125 * 1012 ~ 1,12511 с ~ 3500 лет. В текущем виде копать следует в сторону уменьшения числа вариантов брутфорса или ускорения процедуры. Найдут ли что-то независимые исследователи? Время покажет.
Удачи и успехов в ресерчах!
2 comments On Взлом автомобильной сигнализации на простых примерах.
Pingback: CANToolz — фреймворк для анализа CAN-шины автомобиля - Cryptoworld ()
Стать очень познавательная, но у меня вопрос. Я правильно поняла, данным способом взломать систему можно, но на это уйдет приблизительно 3500 лет??? Есть ли другие способы?