🚨 Принимаем радиосигнал без антенн
Исследователи доказали, что «безантенные-устройства» могут принимать команды по воздуху
В кибербезопасности есть догма: если устройство физически изолировано от сетей, то оно безопасно.
Air-gapped системы десятилетиями считались защищенными на физическом уровне.
В конце 2025 года эта догма дала трещину.
Исследователи опубликовали работу, в которой показали:
встраиваемые устройства без Wi-Fi, Bluetooth, NFC и даже без антенн могут принимать данные через радио сигналы.
🔍 Начало
Поводом для исследования стали странные наводки в embedded-устройствах:
ADC-входы и GPIO иногда фиксировали «шум», который не объяснялся электрическими помехами.
Команда решила проверить гипотезу:
🧪 Что именно проверяли
Исследователи собрали 14 разных embedded-платформ:
➖ промышленные контроллеры,
➖ платы разработчиков,
➖ аппаратные криптокошельки,
➖ беспилотные системы.
Устройства не имели:
❌ радиомодулей,
❌ микрофонов,
❌ инструментов беспроводной связи.
Только обычные платы, дорожки, GPIO и ADC.
📡 Антенны не нужны
Оказалось, что:
➖ PCB-дорожки ведут себя как непреднамеренные антенны;
➖ ADC-входы способны демодулировать радиосигнал;
➖ диапазон 300-1000 МГц;
всё это работает без модификации железа, только за счёт ПО.
В ряде конфигураций соотношение сигнал/шум превышало 30 дБ.
Другие особенности:
📍 сигнал принимался через стены,
📍 на расстоянии до 20 метров,
📍 со скоростью до ~100 кбит/с.
⚠️ Насколько это опасно?
Нужно понимать, что такой подход не «взлом с нуля». Злоумышленник один раз получает код на устройство, например с помощью:
- supply-chain,
- вредоносную прошивку,
- уязвимость в обновлении,
А дальше открывается целый пласт возможностей:
🔹 передавать команды по радио,
🔹 поддерживать скрытый C2-канал,
🔹 управлять air-gapped устройством без физического доступа.
🛡 Нужно ли предпринимать меры?
Нужно понимать, что air-gap не стратегия, а допущение.
Тем не менее есть база, которую стоит учитывать для критичных систем:
➖ экранирование корпусов,
➖ заземлённые сплошные платы,
➖ анализ RF-поведения устройств,
➖ контроль эфирной обстановки,
➖ пересмотр требований к embedded-безопасности.
🧨 Вывод
🚫 Air-gapped ≠ isolated
📡 Даже «немые» устройства могут слушать эфир
⚠️ Физическая изоляция больше не гарантирует безопасность
Мы вступаем в эпоху, где угрозы рождаются не только в коде, но и непосредственно в железе.
🔗 Источник:
arXiv: Talking to the Airgap: Exploiting Radio-Less Embedded Devices as Radio Receivers
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AirGap #EmbeddedSecurity #HardwareSecurity #RFsecurity #Infosec #CyberSecurity #ICS #OTsecurity #CovertChannels
Исследователи доказали, что «безантенные-устройства» могут принимать команды по воздуху
В кибербезопасности есть догма: если устройство физически изолировано от сетей, то оно безопасно.
Air-gapped системы десятилетиями считались защищенными на физическом уровне.
В конце 2025 года эта догма дала трещину.
Исследователи опубликовали работу, в которой показали:
встраиваемые устройства без Wi-Fi, Bluetooth, NFC и даже без антенн могут принимать данные через радио сигналы.
🔍 Начало
Поводом для исследования стали странные наводки в embedded-устройствах:
ADC-входы и GPIO иногда фиксировали «шум», который не объяснялся электрическими помехами.
Команда решила проверить гипотезу:
а что если устройство не просто ловит шум, а реально принимает радиосигнал?
🧪 Что именно проверяли
Исследователи собрали 14 разных embedded-платформ:
Устройства не имели:
❌ радиомодулей,
❌ микрофонов,
❌ инструментов беспроводной связи.
Только обычные платы, дорожки, GPIO и ADC.
📡 Антенны не нужны
Оказалось, что:
всё это работает без модификации железа, только за счёт ПО.
В ряде конфигураций соотношение сигнал/шум превышало 30 дБ.
Другие особенности:
📍 сигнал принимался через стены,
📍 на расстоянии до 20 метров,
📍 со скоростью до ~100 кбит/с.
⚠️ Насколько это опасно?
Нужно понимать, что такой подход не «взлом с нуля». Злоумышленник один раз получает код на устройство, например с помощью:
- supply-chain,
- вредоносную прошивку,
- уязвимость в обновлении,
А дальше открывается целый пласт возможностей:
🔹 передавать команды по радио,
🔹 поддерживать скрытый C2-канал,
🔹 управлять air-gapped устройством без физического доступа.
🛡 Нужно ли предпринимать меры?
Нужно понимать, что air-gap не стратегия, а допущение.
Тем не менее есть база, которую стоит учитывать для критичных систем:
🧨 Вывод
🚫 Air-gapped ≠ isolated
📡 Даже «немые» устройства могут слушать эфир
⚠️ Физическая изоляция больше не гарантирует безопасность
Мы вступаем в эпоху, где угрозы рождаются не только в коде, но и непосредственно в железе.
🔗 Источник:
arXiv: Talking to the Airgap: Exploiting Radio-Less Embedded Devices as Radio Receivers
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #AirGap #EmbeddedSecurity #HardwareSecurity #RFsecurity #Infosec #CyberSecurity #ICS #OTsecurity #CovertChannels
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🔍 Федеративный RCA без доступа к данным: как найти источник сбоя в распределённой промышленной системе
Вышел интересный препринт на arXiv “Learning Unknown Interdependencies for Decentralized Root Cause Analysis in Nonlinear Dynamical Systems” (arXiv:2602.21928v1).
Исследователи предлагают способ находить первопричину инцидента в распределённой промышленной системе… не имея доступа к сырым данным.
Звучит как невозможное?
Разберёмся. 👇
🏭 В чём суть проблемы
Представьте несколько заводских установок, которые связаны между собой. Если одна «ломается», сбой может распространиться на остальные. ⚡
Но как понять, где настоящая причина, а где просто следствие?
Сложность в том, что:
🚫 данные нельзя собирать в один центр,
🔒 модели часто закрытые (от OEM),
📡 у каждого узла свои датчики и логика работы.
Классические методы анализа причин здесь не работают: им нужен полный доступ к данным.
🧠 Что придумали авторы
Они построили федеративную систему, где:
🏢 каждый клиент оставляет свою модель как есть,
➕ к ней добавляется небольшая ML-надстройка,
🌐 центральный сервер учится понимать связи между узлами,
🚫📂 но сырые данные никуда не передаются.
Передаются:
📊 состояния моделей,
🚨 во время инцидента - бинарные флаги «есть аномалия / нет аномалии».
Дополнительно применяется differential privacy, т.е. данные и градиенты зашумляются. 🔐
🚨 Как определяется источник сбоя
У каждого клиента есть два индикатора:
🔎 аномалия в базовой модели,
🌍 аномалия в расширенной модели (которая учитывает влияние других).
Если обе сигналят, то это кандидат в источник. 🎯
Если только базовая, то скорее всего это «эхо» чужой проблемы. 🔁
Сервер смотрит на картину в целом и определяет root cause без сырых данных.
🧪 Проверка на практике
Метод протестировали:
🧩 на синтетических системах,
🏭 и на индустриальном датасете HAI (Hardware-In-the-Loop ICS).
Качество близко к централизованной модели, у которой есть полный доступ ко всем данным. 📈
📎 Ссылка: https://arxiv.org/abs/2602.21928v1
Start secure and read SecureTechTalks 📚
#кибербезопасность #ICS #OTSecurity #RootCauseAnalysis #FederatedLearning #IndustrialSecurity #CriticalInfrastructure #AIinSecurity #DataPrivacy #SecureTechTalks
Вышел интересный препринт на arXiv “Learning Unknown Interdependencies for Decentralized Root Cause Analysis in Nonlinear Dynamical Systems” (arXiv:2602.21928v1).
Исследователи предлагают способ находить первопричину инцидента в распределённой промышленной системе… не имея доступа к сырым данным.
Звучит как невозможное?
Разберёмся. 👇
🏭 В чём суть проблемы
Представьте несколько заводских установок, которые связаны между собой. Если одна «ломается», сбой может распространиться на остальные. ⚡
Но как понять, где настоящая причина, а где просто следствие?
Сложность в том, что:
🚫 данные нельзя собирать в один центр,
🔒 модели часто закрытые (от OEM),
📡 у каждого узла свои датчики и логика работы.
Классические методы анализа причин здесь не работают: им нужен полный доступ к данным.
🧠 Что придумали авторы
Они построили федеративную систему, где:
🏢 каждый клиент оставляет свою модель как есть,
➕ к ней добавляется небольшая ML-надстройка,
🌐 центральный сервер учится понимать связи между узлами,
🚫📂 но сырые данные никуда не передаются.
Передаются:
📊 состояния моделей,
🚨 во время инцидента - бинарные флаги «есть аномалия / нет аномалии».
Дополнительно применяется differential privacy, т.е. данные и градиенты зашумляются. 🔐
🚨 Как определяется источник сбоя
У каждого клиента есть два индикатора:
🔎 аномалия в базовой модели,
🌍 аномалия в расширенной модели (которая учитывает влияние других).
Если обе сигналят, то это кандидат в источник. 🎯
Если только базовая, то скорее всего это «эхо» чужой проблемы. 🔁
Сервер смотрит на картину в целом и определяет root cause без сырых данных.
🧪 Проверка на практике
Метод протестировали:
🧩 на синтетических системах,
🏭 и на индустриальном датасете HAI (Hardware-In-the-Loop ICS).
Качество близко к централизованной модели, у которой есть полный доступ ко всем данным. 📈
📎 Ссылка: https://arxiv.org/abs/2602.21928v1
Start secure and read SecureTechTalks 📚
#кибербезопасность #ICS #OTSecurity #RootCauseAnalysis #FederatedLearning #IndustrialSecurity #CriticalInfrastructure #AIinSecurity #DataPrivacy #SecureTechTalks
👍1