Нижний текст

Репортёр: Кто приказал прервать работу Starlink в Украине?
Трамп: Я не знаю, кто это был, но хотел бы узнать.

🟢Подписаться на канал
🟢Подписаться в MAX

Из LoRa-модема Semtech LR2021 сделали SDR на 100-2740 МГц

В ROM чипа Semtech LR2021 нашлась недокументированная команда, которая вместо штатного демодулятора отдаёт сырую промежуточную частоту: 16 бит на I и Q, амплитуда и фаза на месте.

Команда 0x0290 перенаправляет внутренний источник 2 в приёмный FIFO. Патч прошивки не нужен, работает на ROM 1.24. Наружу идёт голый поток пар I/Q, без заголовков, без меток времени, без слова синхронизации.

По документации Semtech приём сделан понижением частоты. Гетеродин ставится на f_RF минус ПЧ, промежуточные частоты набираются от 267 до 2667 кГц и привязаны к полосе канального фильтра. Зеркало приходит снизу от несущей, на f_RF минус 2·ПЧ, и его положение двигают выбором полосы. Цепочка простая: малошумящий усилитель, смеситель, антиалиасирующий фильтр, АЦП, цифровой тракт. Источник 2 - это сигнал на входе демодуляторов, то есть уже после децимации и канальной фильтрации.

Дальше приёмник пишется в софте. Всё считается на плате LilyGO T-Display-P4 с ESP32-P4, радио в ней штатное. P25 Phase 1, POCSAG и аналоговый FM декодируются на самой плате, звук идёт с неё. Библиотека доступа к радио и прошивка захвата лежат тут. Там же инструменты и измерения. Живые декодеры с интерфейсом - в LakeShark.

Замеры сделаны на одной плате и в одном месте, антенны менялись.
⚙️ приём 100-2740 МГц сплошной вместо паспортных 150-960 и 1500-2600 МГц
⚙️ 250 тыс. пар I/Q в секунду без потерь, 500 тыс. уже переполняют FIFO
⚙️ скорость потока вчетверо выше полосы LoRa
⚙️ 391 секунд непрерывной записи на 125 тыс. пар в секунду
⚙️ подавление зеркала около 41 дБ на 433,9 МГц

У SX1262 с той же платы выхода I/Q нет вообще, только уровень сигнала и штатные демодуляторы, а диапазон разорван надвое: 37-1447 и 2624-3494 МГц. Между ними 1448-2622 МГц глухо, BLE на 2,4 ГГц туда не достанешь.

Отдельно о питании, цифры из документации Semtech. Напряжение 1,8-3,7 В. Приём 5,7 мА на низких частотах и 6,4-10,5 мА на 2,4 ГГц, синтезатор 3 мА, сон 0,47 мкА. Для бортовика это пять-десять миллиампер, но ограничение есть: рабочий диапазон от -40 до +85 градусов Цельсия.

Динамический диапазон у приёмника модемный, и это главное ограничение. Точка пересечения по третьему порядку -12 дБм вблизи несущей и -10 дБм вдали, на вход усилителя можно подать максимум +6 дБм. Излучатель мощностью 1 Вт рядом даст продукты третьего порядка на 42 дБ ниже себя, и сядут они в соседнем канале. Зеркало даёт 35 дБ без калибровки и 45 дБ после неё, на 2,4 ГГц 25 и 35 дБ. Измеренные 41 дБ попадают внутрь этих цифр.

Вторая ловушка с чувствительностью. -147 дБм из документации - это параметр LoRa-детектора, к сырому потоку пар I/Q он отношения не имеет: ни этой обработки, ни её выигрыша там нет. Полка шума в отсчётах стоит около -58 дБFS, то есть реально работают 6-7 бит из 16.

Передача сделана тем же способом, командой 0x0293: 8-битные I и Q подряд в передающий FIFO. Ограничения жёсткие, 16 КБ за раз и 900 мс на заход. Шли на нижней ступени, -9 дБм, хотя усилитель чипа на низких частотах выдаёт до +22 дБм, а на 2,4 ГГц до +12 дБм. Есть и штатные режимы проверки передатчика: несущая без прерывания, бесконечная преамбула, запуск передачи по DIO.

Проверяли не самим собой, HackRF снимал эфир, DSD-neo разбирал: два захода по 36 голосовых кадров P25, все 72 совпали с эталоном, тон 1011 Гц на месте. На резком развороте фазы ошибка доходила до 88 градусов, плавный разворот по четырём шагам свёл её к 1,5-3 градусам.

Осталось неподтверждённым. Поток на 250 тыс. пар в секунду долго не гоняли, фаза 2 P25 не подтверждена, излучаемая мощность не измерена. Спектральной маски и побочных излучений в самой документации тоже нет, их отдали на ETSI и FCC.

🟢Подписаться на канал
🟢Подписаться в MAX

Роутер OpenWrt One переделали в SDR-приёмник с полосой 40 МГц

На GitHub вышел проект openwrt-one-sdr. Из роутера OpenWrt One на MediaTek MT7981B с радиотрактом MT7976 сделали широкополосный SDR-приёмник: сырые I/Q по 14 бит, 40 млн отсчётов в секунду из диапазонов 2,4 и 5 ГГц. Двухъядерный Cortex-A53 гонит поток по 2,5 GbE на компьютер в формате VITA 49, там спектр и водопад в браузере.

По данным репозитория:
⚙️ приём 2,4 и 5 ГГц, полоса канала 40 МГц, частота дискретизации 40 млн отсчётов/с, 14 бит на пару I/Q
⚙️ перестройка идёт по центрам блоков HE40, а не по основному каналу: 2422-2462 МГц с шагом 5 МГц на 2,4 ГГц и 5190 или 5230 МГц на 5 ГГц
⚙️ 5 ГГц ограничен U-NII-1, 5170-5260 МГц
⚙️ перестройка или смена диапазона занимает около 25 с, это перезагрузка радиомодуля Wi-Fi
⚙️ только приём: во время захвата MAC заблокирован на передачу, а при загрузке и после остановки штатный стек Wi-Fi передавать может

Подход здесь другой, чем в w1700k-sdr. Там прошивку MediaTek выкинули и написали свою целиком, здесь её оставили штатной и управляют ей из Linux. Всё, что нужно, - производитель на ассемблере nds32 размером 1660 байт, впаянный в диспетчер команд прошивки Wi-Fi-модуля. Он идёт по указателю записи блока захвата ICAP и выкладывает отсчёты в кольцо DMA, дальше их забирает драйвер mt76. Кросс-компилятор не обязателен: в репозитории лежит собранный кусок, apply-producer.py вносит те же правки в стоковую прошивку с самой платы и проверяет контрольную сумму. Патч на закрытую прошивку MediaTek не тиражируют, каждый собирает под свою плату.

Регистровую часть удалось унаследовать. MT7981 стоит на той же A-дие MT7976, что и MT7996, и блок захвата у них по одним и тем же адресам шины с теми же значениями сброса. Расшифровку радиотракта брали с MT7996. Формат 14 бит: I в битах 29:16, Q в 13:0, без знакового расширения. На 2,4 ГГц берётся каждый второй упакованный отсчёт, на 5 ГГц все, из-за чего шаг отсчёта разный, 8 байт против 4.

С пропускной способностью вышло впритык. 40 млн отсчётов в секунду по 16 бит на I и на Q дают 1,28 ГБ/с, это чуть больше половины 2,5 GbE. Пакеты собирает ядро: Ethernet, IPv4 и UDP лепятся прямо в ядре и уходят мимо пользовательской программы, промежуточной пересылки нет. В каждом UDP-пакете 1448 байт, это 360 пар I/Q. Контекстный пакет VITA 49 с несущей, частотой дискретизации и форматом данных идёт раз на 128 пакетов с отсчётами, приёмник сначала ждёт его.

Восемьдесят мегаотсчётов в секунду проверяли, но результат автор трактует осторожно. В 16 бит такое не влезает, нужно 2,56 ГБ/с. В 8 бит один ограниченный прогон отдал 819,2 млн слов отсчётов за 10,24 с, но внутри были повторы. То есть это не 80 МГц полосы и не 80 млн независимых отсчётов в секунду. Упаковка 14 бит в 28 бит на пару уменьшила бы поток ещё на 12 процентов, но пакет под это на плате так и не сделан.

С драйвером пришлось повозиться. Периодический опрос статистики по MCU отваливается по таймауту, и штатная проверка состояния чипа после этого перезагружает прошивку и рвёт поток примерно на 4-й секунде. Обновление состояния точек доступа блокирует путь приёма событий от модуля, и без обхода буфер захвата переполняется раз в 150-200 с. В обоих случаях обход сделали в mt76: опрос отключается, а таймаут возвращает ошибку вместо перезагрузки.

🟢Подписаться на канал
🟢Подписаться в MAX

Ограничения автор перечисляет сам. Плоская характеристика в полосе, отклик на краях и подавление зеркал не измерены, уровни приходят в dBFS после АРУ приёмника, а не в откалиброванных dBm. Счётчик пакетов в VITA 49 четырёхбитный, потеря ровно 16 пакетов остаётся незамеченной, так что подтвердить работу без пропусков средствами VITA 49 нельзя. Надолго работать не проверяли. Полная совместимость с VITA 49.2 не заявлена, реализовано подмножество команд, а ответ об ошибке не сделан, при неудаче контроллер получает таймаут. Команды на перестройку проверены через SoapyVITA49, драйвер для SoapySDR, который автор ведёт параллельно.

И главное ограничение для работы по эфиру. 25 секунд на смену частоты - это перезагрузка радиомодуля Wi-Fi, а не перескок по ходу потока. Переключиться с 2437 на 5190 МГц и обратно можно, но это около минуты на круг. То есть это станция наблюдения с ручной перестройкой, а не сканер. На 2,4 ГГц доступны девять центров с шагом 5 МГц, и тройка окон по 40 МГц перекрывает весь рабочий диапазон 2,4 ГГц. На 5 ГГц доступен только U-NII-1, то есть диапазон аналогового FPV-видео 5,65-5,95 ГГц сюда не попадает.

Отдельно стоит глянуть vrtgen. Это генератор классов C++ для пакетов VITA 49.2 по описанию на YAML, openwrt-one-sdr идёт другим путём и пишет свой отвечающий модуль руками на C. Форк devnulling отличается от geontech/vrtgen одним патчем, добавлена сборка на macOS и Windows. Зато в истории исходника лежит поучительный баг. Восемь полей спектра в контекстном пакете уходили в провод без перестановки байт, и на машине с младшим байтом первым приёмник получал вместо чисел мусор. Нашли его разбором пакета в Wireshark, а не тестами.

🟢Подписаться на канал
🟢Подписаться в MAX

Эфир мужества

Воины-связисты держат в руках управление всем фронтом в зоне спецоперации, доказывая свой профессионализм в самые критические моменты.

Работа в условиях радиоэлектронной борьбы требует от связистов мгновенных решений и колоссального мужества. Каждая удержанная ими частота и вовремя переданные координаты — это спасенные жизни штурмовиков, точный ответ нашей артиллерии и полный контроль над боевой обстановкой.

▫️ Быть на связи – побеждать!

🔹 Канал Минобороны России в MAКС – только для своих!

ANT увеличила дальность разведывательного Mercury

Вражеская Aviation New Technologies доработала разведывательный Mercury типа VTOL, о котором мы писали ранее: тут и тут. Масса борта выросла с 13 до 19 кг, рабочая высота - до 4000 м, крейсерская скорость - до 90 км/ч (максимальная 126 км/ч). Продолжительность полёта увеличили с 2,5 до 4 часов, при эксплуатации заявляют до 5 часов. Максимальный пройденный путь - 250 км, в практических условиях до 300 км.

Связь двухканальная: 5,8 ГГц и резервные 433 МГц с ППРЧ. При помехах ГНСС предусмотрены ИНС и возврат по радиомаякам, полёт возможен в режиме радиомолчания. При этом дальность видеосвязи осталась до 70 км, а автономного полёта с записью на борт - до 150 км. Заявленные 300 км относятся к суммарному пути, а не к радиусу управления.

🟢Подписаться на канал
🟢Подписаться в MAX

Вернёмся в 24-й год. Но всё ещё актуально для..

Tesla Model 3 взломали через систему контроля давления в шинах

На время отойдём от военной тематики. Безопасность личного состава касается и гражданских машин, на которых люди ездят(также, данная публикация рассчитана для трёхбуквенных). На Hexacon 2024 Давид Берар и Томас Имбер из Synacktiv рассказали о выполнении чужого кода в электронике Tesla Model 3 через беспроводную систему контроля давления в шинах. Без действий водителя.

В исследованной машине датчики давления TPMS общаются по Bluetooth Low Energy с блоком VCSEC. Этот же блок отвечает за доступ в автомобиль и разрешение на начало движения. Ошибку нашли в обработчике сертификата датчика: неверный расчёт границ памяти давал записать входящие данные за пределами отведённого участка. В итоге блок начинал выполнять код исследователей. Это и называют удалённым выполнением кода, RCE; «0-click» означает, что владельцу не нужно ничего нажимать.

Практический результат: исследователи отправили из захваченного VCSEC свои сообщения в CAN, внутреннюю сеть автомобильных блоков. В слайдах нет демонстрации управления рулём или тормозами. Зато затронут блок, который распоряжается доступом к машине. Для радиочасти демонстрации хватило двух небольших плат ESP32; атака зависела от связи по BLE и условий автоматического подключения датчиков. Подробности и ограничения есть в слайдах 27-30 и 41-43.

Чарли Миллер обратил внимание на отсутствие защит. На слайде 24 ровно этот список: нет CFI, проверяющей допустимость переходов программы; нет ASLR, перемешивающей адреса кода и данных. Защита памяти MMU/MPU не настроена, всё RWX: память доступна для чтения, записи и исполнения. При таких условиях ошибку записи в память проще превратить в выполнение чужого кода. Речь о конкретном VCSEC и исследованной прошивке.

В обсуждении вспомнили secure boot и OTP eFuse. Проверка подлинности прошивки при загрузке и однократно программируемое хранение настроек и ключей полезны. Но подлинная прошивка тоже может ошибаться при разборе входящих данных. Защита во время работы нужна отдельно от проверки при запуске.

Насколько это сложно: авторы назвали эту работу заметно проще трёх своих предыдущих взломов Tesla. И всё же около половины времени исследования ушло на рабочий стенд. Пришлось разбираться в прошивке и аппаратных ревизиях; найденная ошибка присутствовала не во всех вариантах. Дешёвые платы в финальной демонстрации ничего не говорят о стоимости её подготовки.

С LLM часть этой работы ускоряется: модели уже находят ошибки в коде и готовят примеры, подтверждающие сбой. Такие результаты, с проверкой специалистами, опубликовала Anthropic. По нашей оценке, для атакующих это сокращает объём ручной работы. Но из этих данных нельзя вывести, сколько займёт взлом конкретного автомобильного блока: остаются получение прошивки, совместимость железа и проверка на стенде.

Саму ошибку Tesla оперативно исправила, о чём авторы сообщили ещё в 2024 году. Для владельца практический шаг - проверить обновления автомобиля. Хотя данный вектор атаки применим и не только к теслам.

🟢Подписаться на канал
🟢Подписаться в MAX

Signal мог продолжать передавать звук после отбоя

20 октября опубликована CVE-2026-113380 в RingRTC, библиотеке голосовых и видеозвонков Signal. Злонамеренный собеседник мог перегрузить внутреннюю очередь событий и помешать завершению звонка на вашей стороне. Под угрозой передача звука после нажатия «отбой»; в описании CVE допускается и сохранение видеопотока. Оценка в записи CVE - 9,3 по CVSS 4.0.

Внутри звонком управляет конечный автомат (FSM): программа отслеживает состояние соединения и обрабатывает события из очереди. Туда попадают служебные события от собеседника и команды завершения. В исследованном коде очереди автомата звонка и автомата соединения вмещают по 256 событий.

При заполнении очереди попытка добавить событие возвращает ошибку. В старом коде такая ошибка могла прервать процедуру завершения раньше, чем она доходила до закрытия соединения WebRTC, через которое идут звук и видео. Отдельно существовало ожидание остановки автомата без ограничения времени. Поэтому объяснение «отбой бесконечно ждёт за кучей сообщений» неточно: команда могла вообще не попасть в очередь, а обработка ошибки оставляла соединение незакрытым. Это видно в коде до исправления.

Есть и неприятная деталь: библиотека могла уведомить приложение о завершении звонка ещё до фактического закрытия соединения. Конкретное поведение экрана зависит от клиента, но само уведомление об окончании разговора не доказывало, что передача уже остановлена.

Для описанного сценария атакующий участвует в звонке. Его задача - помешать вашей стороне закрыть уже существующее соединение. Собеседник и так получает расшифрованный звук, поэтому стойкость шифрования эту проблему не устраняет.

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

Опубликованный Python PoC - учебная модель без связи с Signal. Он показывает обработку очереди за ограниченное число шагов, но не воспроизводит ошибку RingRTC. Описанные в нём приоритетная очередь и ограничение частоты сообщений также не соответствуют этому патчу.

Исправление вошло в RingRTC 2.72.0. Это номер библиотеки: пользователям нужно обновить само приложение Signal на телефоне и связанных компьютерах.

Риск вполне прикладной: разговор рядом с устройством после отбоя мог оставаться слышен прежнему собеседнику.

🟢Подписаться на канал
🟢Подписаться в MAX