Ну то есть любой ретранслятор-усилитель это уже устройство для угона авто?
Не любой, а специально сконструированный. Там приходится решать весьма нетривиальную задачу — брелок намеренно вещает сигнал с очень маленькой мощностью, и этот сигнал надо ловить оттуда, откуда по задумке ловиться он не должен чисто физически. Результат - огромные рамочные антенны диаметром в метр-полтора, с которыми взломщикам приходится плясать вокруг дома жертвы, пока сигнал не пройдет.
Я клоню к тому, что такие устройства не являются "устройствами двойного назначения", назначение у них исключительно одно.
Потому что это не replay, а просто "удлиннение" канала. Раньше ключ был вне зоны действия, а ретранслятор эту зону расширил, передавая сообщения в обе стороны как есть, без модификации. Никакие nonce не помогут (и в целом, никакая криптография, сообщения не меняются), нужно физическое измерение расстояния по времени отклика.
На практике совместимость такого устроства будет плохой, не все системы умеют пакеты более 64 байт.
Писать HS HID прошивку и не пришлось, поскольку так уж получилось, что HS HID устройство само в руки приплыло. Elgato Stream Deck, панелька с экраном и настраиваемыми кнопочками.
Прекрасно работает, использует пакеты по 1024 байт для передачи картинки. И думаю (учитывая, что это серийный продукт для не-технической аудитории), что никаких особых проблем совместимости не испытывает.
На практике совместимость такого устроства будет плохой, не все системы умеют пакеты более 64 байт.
Сильное утверждение, учитывая, что стандарт USB прямо требует поддержки и, соответственно, все комплаенс-сертификации это проверяют. Собирать ради этого HS HID прошивку я, конечно, не буду, но смотрю на это (особенно на оценку "плохой", предполагающую огромную несовместимость) с большим скепсисом.
Как минимум чтение/запись карты памяти. Там надо лихо жонглировать DMA-запросами, для чего надо переписать весь стек, текущий на такое не расчитан. С отдачей контента чисто из памяти проблем как раз нет...
Т.е. 12 мегабит скопировать из памяти в USB без DMA можно и вы сами говорите, что никаких проблем нет, а 12 мегабит скопировать из SDIO/SPI в память без очень аккуратного обращения с DMA нельзя?
STM32U5 (не вся серия, только некоторые камни) имеют встроенный HS PHY. Например, можно купить вот такую девборду за 100 баксов и поиграться. Другие серии (например, F4) умеют в HS, но только с внешним PHY (из микроконтроллера торчит не сам USB, а ULPI интерфейс ко внешней микросхеме).
USB 3.0 встречается, но либо на специализированных микросхемах типа Cypress FX3 (но это не МК в классическом смысле, а скорее конвертер интерфейса), либо на полноценных процессорах типа STM32MP2. Микроконтроллерам такой поток осмысленно обработать будет сложно.
У HID максимальная скорость 64кбайт/сек, 1000 опросов по 64 байта на пакет в секунду. Дальше вроде никак.
Неправда. Если устройство high speed - максимум 1024 байта на пакет и до трех пакетов в каждом микро-кадре (т.е. 24 пакета в одном кадре, поскольку кадр делится на 8 микро-кадров).
Вон, господа, клепавшие пастильду, писали тут про разгон MSD - даже до предела FS не догнали, увы, на текущих либах камень не вывозит. Если с нуля написать весь стек, может и вывезет, но времени уйдет на это... Страшно подумать, игра не стоит свеч.
Не знакомился подробно с их работой, но выводы странные. При эмуляции UART я прекрасно выжирал всю FS полосу без особых проблем (и без DMA), процессор при этом почти простаивал. Это была STM32G4 на 160 мегагерцах, т.е. м.б. на чуть меньшем контроллере нагрузка будет выше, но 12 мегабит (сырых, реальных меньше) — это явно не то, от чего микроконтроллеры умирают. Возможно, нагрузку давал другой компонент (к чему-то же этот MSD был подключен).
Я бы коснулся в том аспекте, что если USB-C разъем на плате таки стоит (а что еще ставить в портативных устройствах, не micro USB же) — то нужно обе CC линии прижать к земле через два резистора по 5.1 килоом. Без них устройство будет работать только через кабели Type A - Type C.
Есть у меня робкая гипотеза о том, что цель — не (только) запретить звонки сами по себе, а еще и подготовиться к блокировке SRTP/WebRTC на уровне протокола.
Слишком уж удобно в него все заворачивать — и конференции могут висеть часами, и UDP вместо TCP, и шифрованный, и видеопоток дает постоянные мегабиты трафика. При правильном применении очень много всего можно завернуть так, что никакой сигнатурный анализ не поможет.
Проблема не в том, что он сложный (он в целом относительно простой), а в том, что для его использования необходим дополнительный физический CC провод — Type A разъемы в пролете. Все эти QuickCharge, DASH и прочий зоопарк могут работать через Type A по линиям данных.
Если используется правильная криптография - то этап преобразования пароля в ключ специально делают очень ресурсоемким как раз против этого. Причём не только по вычислениям, а еще и по объему требуемой памяти. Условно, расшифровка самого текста может занимать миллисекунду, а восстановление ключа для неё из пароля - секунду и требовать 128 мегабайт быстрой памяти. Примеры - scrypt, argon2.
У меня есть проект по модульному тестированию физического уровня USB-стека похожим способом (внешней FPGA с ULPI-трансивером), и по мере наличия свободного времени я его делаю. Как доделаю — обязательно выложу на хабр, только, боюсь, займет это куда больше, чем щедро выделенные вами три недели.
Похожая ситуация, кстати, возникала на STM32 и с I2C во внутреннем проекте. Если не дождаться полного завершения передачи и освобождения модуля (там есть несколько разных флагов на этот счет, взводящихся в разное время) и сразу начать новую — I2C модуль встает в странной ситуации, когда считает, что шина занята, но никаких действий не предпринимает. Причем ваши "модульные тесты" это бы не словили, потому что было нужно, чтобы сразу после записи быстро шло чтение.
Но этот I2C драйвер реализован примерно как и ваш — только те части, что реально нужны для реального устройства, потому о нем статьи на хабре я не пишу и не называю их "Конечный Автомат Аппаратного I2C Трансивера" с претензией на всеобъемность и академичность. Конечный автомат трансивера в STM32 не факт, что сами инженеры из ST нарисовать способны с доступом к исходникам. Он уж точно намного сложнее, чем ваш сферический конь в вакууме — там есть разные режимы передач, разные настройки аппаратных реакций на события, разные режимы адресации (7b/10b), автоматический отсчет переданных байт (с аппаратной реакцией на конец сообщения) и т.п. Как раз в аппаратных реакциях проблема и была — модуль рапортовал завершение передачи данных, но у него еще был аппаратный стоп, который сигнализировался другим флагом.
Потому раз уж пишите статьи — пишите их по делу, а не вводите людей в заблуждение, наваливая кучу теории, рассказывая про зависшие устройства, делая исторический экскурс вплоть до истории открытия электрона и завершая их фразой "я передал один байт и я молодец".
Тут вся статья - один большой арт-объект об оверинжиниринге, но её финализация (после перечисления всех возможных состояний, переходов и т.п.) заявлением об успехе на основании трех тривиальных тестов одной конкретной микросхемы - это вишенка.
Такой тип тестов называется интеграционными, а не модульными. Проверяется работа нескольких абсолютно разных блоков: сам драйвер, микросхема, её состояние (например, возможно, она дает разные ответы в зависимости от внешней среды). Причем, что важно, проверяется не корректность фунционального блока в его полной теоретической формальной постановке, а выполнение системой заранее заданных практических сценариев.
Модульными они были бы, если бы вы вместо реального устройства подключили бы туда, например, FPGA и проэмулировали на ней все случаи из формальной спецификации - ACK, NACK, старт, рестарт, висящая шина, clock stretching, передача длинного буфера, NACK посередине буфера, взаимодействие этого всего с DMA (и/или RTOS) и т.п.
Тогда от статьи действительно был бы какой-то смысл — ведь в интернете и без неё полно баганного кода, способного прочитать один байт из EEPROM в бесконечном цикле без какого-либо намека на таймауты или DMA.
Вполне могут иметь, это называется clock stretching. Используется, если устройство медленное и хочет притормозить трафик на шине, который не успевает обрабатывать.
Зависит от архитектуры всей системы. Такой подход вполне может использоваться на уровне приложения, если нужно одни и те же события синхронизировать в разные гетерогенные системы. Например, сайт, CRM и какая-нибудь аналитика, которая вообще что-то экзотическое и noSQL.
Но даже если нет и там реально одна база, куда идет весь трафик - все же имеет смысл при ответе описать механизм детально, хоть это и дословное описание логической репликации, которая и так есть в СУБД.
Всё происходящее (выдача посылки, прием посылки, оплата, ...) представляется как большой поток событий.
Этот поток событий можно эффективно бекапить хоть в реальном времени, пересылая его бекап-серверу, хоть по таймеру, зная, что последний раз ты видел событие номер N, а значит, в следующий раз надо выбирать все, что с номером больше N.
Этот же поток получает "рабочая" СУБД, которая применяет все запрошенные изменения, и записывает, какое последнее событие она видела. Эта СУБД бекапится по таймеру, например, раз в день.
В экстренной ситуации достается бекап СУБД, и достается часть потока, которая еще не была к ней применена.
Tesla считает, что работа бета-версии системы помощи водителю FSD полностью безопасна при выполнении всех рекомендаций компании: руки на руле и внимательно смотреть на дорожную обстановку. В компании уточнили, что ответственность за использование FSD остаётся за водителем, который должен всегда быть внимательным и быть готовым взять на себя управление.
TL,DR: Бета-версия системы FSD полностью безопасна если водитель успевает отреагировать в ситуациях, когда она небезопасна. Если в итоге получилась небезопасная ситуация - то всегда виноват безалаберный водитель, поскольку система полностью безопасна.
Отмечу, что иммобилайзер защищает только до запуска двигателя, после запуска - будет только ругаться на отсутствие брелка рядом
И то это мера для комфорта владельца, чтобы не выложить/не потерять ключ при заведенном двигателе, не уехать на другой конец города и не выяснить уже там, что теперь ты ходишь пешком.
Массовое внедрение UWB закроет такие атаки раз и навсегда. Расстояние там измеряется по физическому времени полета сигнала. И там есть свои уязвимости, но это уявимости рода "сделать так, чтобы приемник распознал 10 метров как 1", любая программная ретрансляция сигнала внесет недопустимую и моментально обнаруживаемую задержку.
Сравнение в аналоговом домене не требуется, поскольку никто не запрещает вам делать оверсемплинг при воспроизведении. Речь в статье (и в моем комментарии) идет исключительно о хранении звука в файлах на жестком диске, а не о транспортных форматах и не о семплрейте финального ЦАП. Если у вас есть сигнал на частоте дискретизации 192 кГц, в котором нет частот выше 22 кГц - вы можете сохранить его как 48 кГц, сделать интерполяцию до 192 кГц при воспроизведении и абсолютно ничего не потерять. Независимо от того, как работает ЦАП и какая там аналоговая схемотехника.
Ну так пусть оверсемплят, кто ж им запрещает-то? Можно даже оверсемплить программно при воспроизведении, специальным Hi-Fi оверсемплером, написанным на клавиатуре из бескислородной меди на дубовой подставке и скомпилированным специальной аудиофильской версией gcc в ночь на полнолуние. Но хранить-то звук в 192/24 зачем?
Не любой, а специально сконструированный. Там приходится решать весьма нетривиальную задачу — брелок намеренно вещает сигнал с очень маленькой мощностью, и этот сигнал надо ловить оттуда, откуда по задумке ловиться он не должен чисто физически. Результат - огромные рамочные антенны диаметром в метр-полтора, с которыми взломщикам приходится плясать вокруг дома жертвы, пока сигнал не пройдет.
Я клоню к тому, что такие устройства не являются "устройствами двойного назначения", назначение у них исключительно одно.
Потому что это не replay, а просто "удлиннение" канала. Раньше ключ был вне зоны действия, а ретранслятор эту зону расширил, передавая сообщения в обе стороны как есть, без модификации. Никакие nonce не помогут (и в целом, никакая криптография, сообщения не меняются), нужно физическое измерение расстояния по времени отклика.
Это с огромной вероятностью не будет работать, если подключить прибор к PD источнику через TypeC-TypeC кабель.
Писать HS HID прошивку и не пришлось, поскольку так уж получилось, что HS HID устройство само в руки приплыло. Elgato Stream Deck, панелька с экраном и настраиваемыми кнопочками.
Прекрасно работает, использует пакеты по 1024 байт для передачи картинки. И думаю (учитывая, что это серийный продукт для не-технической аудитории), что никаких особых проблем совместимости не испытывает.
Сильное утверждение, учитывая, что стандарт USB прямо требует поддержки и, соответственно, все комплаенс-сертификации это проверяют. Собирать ради этого HS HID прошивку я, конечно, не буду, но смотрю на это (особенно на оценку "плохой", предполагающую огромную несовместимость) с большим скепсисом.
Т.е. 12 мегабит скопировать из памяти в USB без DMA можно и вы сами говорите, что никаких проблем нет, а 12 мегабит скопировать из SDIO/SPI в память без очень аккуратного обращения с DMA нельзя?
STM32U5 (не вся серия, только некоторые камни) имеют встроенный HS PHY. Например, можно купить вот такую девборду за 100 баксов и поиграться. Другие серии (например, F4) умеют в HS, но только с внешним PHY (из микроконтроллера торчит не сам USB, а ULPI интерфейс ко внешней микросхеме).
USB 3.0 встречается, но либо на специализированных микросхемах типа Cypress FX3 (но это не МК в классическом смысле, а скорее конвертер интерфейса), либо на полноценных процессорах типа STM32MP2. Микроконтроллерам такой поток осмысленно обработать будет сложно.
Неправда. Если устройство high speed - максимум 1024 байта на пакет и до трех пакетов в каждом микро-кадре (т.е. 24 пакета в одном кадре, поскольку кадр делится на 8 микро-кадров).
Не знакомился подробно с их работой, но выводы странные. При эмуляции UART я прекрасно выжирал всю FS полосу без особых проблем (и без DMA), процессор при этом почти простаивал. Это была STM32G4 на 160 мегагерцах, т.е. м.б. на чуть меньшем контроллере нагрузка будет выше, но 12 мегабит (сырых, реальных меньше) — это явно не то, от чего микроконтроллеры умирают. Возможно, нагрузку давал другой компонент (к чему-то же этот MSD был подключен).
Я бы коснулся в том аспекте, что если USB-C разъем на плате таки стоит (а что еще ставить в портативных устройствах, не micro USB же) — то нужно обе CC линии прижать к земле через два резистора по 5.1 килоом. Без них устройство будет работать только через кабели Type A - Type C.
Есть у меня робкая гипотеза о том, что цель — не (только) запретить звонки сами по себе, а еще и подготовиться к блокировке SRTP/WebRTC на уровне протокола.
Слишком уж удобно в него все заворачивать — и конференции могут висеть часами, и UDP вместо TCP, и шифрованный, и видеопоток дает постоянные мегабиты трафика. При правильном применении очень много всего можно завернуть так, что никакой сигнатурный анализ не поможет.
Проблема не в том, что он сложный (он в целом относительно простой), а в том, что для его использования необходим дополнительный физический CC провод — Type A разъемы в пролете. Все эти QuickCharge, DASH и прочий зоопарк могут работать через Type A по линиям данных.
Если используется правильная криптография - то этап преобразования пароля в ключ специально делают очень ресурсоемким как раз против этого. Причём не только по вычислениям, а еще и по объему требуемой памяти. Условно, расшифровка самого текста может занимать миллисекунду, а восстановление ключа для неё из пароля - секунду и требовать 128 мегабайт быстрой памяти. Примеры - scrypt, argon2.
У меня есть проект по модульному тестированию физического уровня USB-стека похожим способом (внешней FPGA с ULPI-трансивером), и по мере наличия свободного времени я его делаю. Как доделаю — обязательно выложу на хабр, только, боюсь, займет это куда больше, чем щедро выделенные вами три недели.
Похожая ситуация, кстати, возникала на STM32 и с I2C во внутреннем проекте. Если не дождаться полного завершения передачи и освобождения модуля (там есть несколько разных флагов на этот счет, взводящихся в разное время) и сразу начать новую — I2C модуль встает в странной ситуации, когда считает, что шина занята, но никаких действий не предпринимает. Причем ваши "модульные тесты" это бы не словили, потому что было нужно, чтобы сразу после записи быстро шло чтение.
Но этот I2C драйвер реализован примерно как и ваш — только те части, что реально нужны для реального устройства, потому о нем статьи на хабре я не пишу и не называю их "Конечный Автомат Аппаратного I2C Трансивера" с претензией на всеобъемность и академичность. Конечный автомат трансивера в STM32 не факт, что сами инженеры из ST нарисовать способны с доступом к исходникам. Он уж точно намного сложнее, чем ваш сферический конь в вакууме — там есть разные режимы передач, разные настройки аппаратных реакций на события, разные режимы адресации (7b/10b), автоматический отсчет переданных байт (с аппаратной реакцией на конец сообщения) и т.п. Как раз в аппаратных реакциях проблема и была — модуль рапортовал завершение передачи данных, но у него еще был аппаратный стоп, который сигнализировался другим флагом.
Потому раз уж пишите статьи — пишите их по делу, а не вводите людей в заблуждение, наваливая кучу теории, рассказывая про зависшие устройства, делая исторический экскурс вплоть до истории открытия электрона и завершая их фразой "я передал один байт и я молодец".
Тут вся статья - один большой арт-объект об оверинжиниринге, но её финализация (после перечисления всех возможных состояний, переходов и т.п.) заявлением об успехе на основании трех тривиальных тестов одной конкретной микросхемы - это вишенка.
Такой тип тестов называется интеграционными, а не модульными. Проверяется работа нескольких абсолютно разных блоков: сам драйвер, микросхема, её состояние (например, возможно, она дает разные ответы в зависимости от внешней среды). Причем, что важно, проверяется не корректность фунционального блока в его полной теоретической формальной постановке, а выполнение системой заранее заданных практических сценариев.
Модульными они были бы, если бы вы вместо реального устройства подключили бы туда, например, FPGA и проэмулировали на ней все случаи из формальной спецификации - ACK, NACK, старт, рестарт, висящая шина, clock stretching, передача длинного буфера, NACK посередине буфера, взаимодействие этого всего с DMA (и/или RTOS) и т.п.
Тогда от статьи действительно был бы какой-то смысл — ведь в интернете и без неё полно баганного кода, способного прочитать один байт из EEPROM в бесконечном цикле без какого-либо намека на таймауты или DMA.
Вполне могут иметь, это называется clock stretching. Используется, если устройство медленное и хочет притормозить трафик на шине, который не успевает обрабатывать.
Зависит от архитектуры всей системы. Такой подход вполне может использоваться на уровне приложения, если нужно одни и те же события синхронизировать в разные гетерогенные системы. Например, сайт, CRM и какая-нибудь аналитика, которая вообще что-то экзотическое и noSQL.
Но даже если нет и там реально одна база, куда идет весь трафик - все же имеет смысл при ответе описать механизм детально, хоть это и дословное описание логической репликации, которая и так есть в СУБД.
Всё происходящее (выдача посылки, прием посылки, оплата, ...) представляется как большой поток событий.
Этот поток событий можно эффективно бекапить хоть в реальном времени, пересылая его бекап-серверу, хоть по таймеру, зная, что последний раз ты видел событие номер N, а значит, в следующий раз надо выбирать все, что с номером больше N.
Этот же поток получает "рабочая" СУБД, которая применяет все запрошенные изменения, и записывает, какое последнее событие она видела. Эта СУБД бекапится по таймеру, например, раз в день.
В экстренной ситуации достается бекап СУБД, и достается часть потока, которая еще не была к ней применена.
TL,DR: Бета-версия системы FSD полностью безопасна если водитель успевает отреагировать в ситуациях, когда она небезопасна. Если в итоге получилась небезопасная ситуация - то всегда виноват безалаберный водитель, поскольку система полностью безопасна.
И то это мера для комфорта владельца, чтобы не выложить/не потерять ключ при заведенном двигателе, не уехать на другой конец города и не выяснить уже там, что теперь ты ходишь пешком.
Массовое внедрение UWB закроет такие атаки раз и навсегда. Расстояние там измеряется по физическому времени полета сигнала. И там есть свои уязвимости, но это уявимости рода "сделать так, чтобы приемник распознал 10 метров как 1", любая программная ретрансляция сигнала внесет недопустимую и моментально обнаруживаемую задержку.
Сравнение в аналоговом домене не требуется, поскольку никто не запрещает вам делать оверсемплинг при воспроизведении. Речь в статье (и в моем комментарии) идет исключительно о хранении звука в файлах на жестком диске, а не о транспортных форматах и не о семплрейте финального ЦАП. Если у вас есть сигнал на частоте дискретизации 192 кГц, в котором нет частот выше 22 кГц - вы можете сохранить его как 48 кГц, сделать интерполяцию до 192 кГц при воспроизведении и абсолютно ничего не потерять. Независимо от того, как работает ЦАП и какая там аналоговая схемотехника.
Ну так пусть оверсемплят, кто ж им запрещает-то? Можно даже оверсемплить программно при воспроизведении, специальным Hi-Fi оверсемплером, написанным на клавиатуре из бескислородной меди на дубовой подставке и скомпилированным специальной аудиофильской версией gcc в ночь на полнолуние. Но хранить-то звук в 192/24 зачем?