Отмечу, что иммобилайзер защищает только до запуска двигателя, после запуска - будет только ругаться на отсутствие брелка рядом
И то это мера для комфорта владельца, чтобы не выложить/не потерять ключ при заведенном двигателе, не уехать на другой конец города и не выяснить уже там, что теперь ты ходишь пешком.
Массовое внедрение UWB закроет такие атаки раз и навсегда. Расстояние там измеряется по физическому времени полета сигнала. И там есть свои уязвимости, но это уявимости рода "сделать так, чтобы приемник распознал 10 метров как 1", любая программная ретрансляция сигнала внесет недопустимую и моментально обнаруживаемую задержку.
Сравнение в аналоговом домене не требуется, поскольку никто не запрещает вам делать оверсемплинг при воспроизведении. Речь в статье (и в моем комментарии) идет исключительно о хранении звука в файлах на жестком диске, а не о транспортных форматах и не о семплрейте финального ЦАП. Если у вас есть сигнал на частоте дискретизации 192 кГц, в котором нет частот выше 22 кГц - вы можете сохранить его как 48 кГц, сделать интерполяцию до 192 кГц при воспроизведении и абсолютно ничего не потерять. Независимо от того, как работает ЦАП и какая там аналоговая схемотехника.
Ну так пусть оверсемплят, кто ж им запрещает-то? Можно даже оверсемплить программно при воспроизведении, специальным Hi-Fi оверсемплером, написанным на клавиатуре из бескислородной меди на дубовой подставке и скомпилированным специальной аудиофильской версией gcc в ночь на полнолуние. Но хранить-то звук в 192/24 зачем?
SP-GIST вообще не об этом. Попытаться можно, но итоговая производительность будет очень грустной для реальных задач. Индустрия сдвинулась в сторону ANN (approximate nearest neighbor) не от хорошей жизни, а от того, что точные методы слишком медленные.
Вот pgvector по ссылке выше уже ближе, HNSW работает довольно хорошо.
Типа вот так, но только типичные размерности не 2, а 128-256-512 и выше (т.е. PostGIS сразу мимо), и время поиска должно быть лучше, чем фулл-скан.
Т.е. если взять постгрес и прикрутить ему в качестве индексного движка один из ANN-методов, то он тоже станет вполне себе неплохой векторной базой (а по сравнению с некоторыми - даже отличной векторной базой). Но у постгреса такого индексного движка нет, а у векторных баз есть.
Из вашего парадокса просто следует то, что такой фильтр на практике существовать не может, поскольку нарушает принцип причинности (о чем вы сами и написали). Есть даже термин такой, "non-causal filter", для описания математических конструкций с подобными свойствами.
Раз знает микроконтроллер - знает и производитель микроконтроллера, это довольно очевидно. Но производитель МК видит только ключ, а бинарник не видит (вы его шифруете локально). Завод видит зашифрованный бинарник, но не может восстановить для него ключ.
Впрочем, подобная система строго до первого умельца с микроскопом или с какой-нибудь атакой по энергопотреблению. После этого вся серия МК становится уязвимой.
Ужас, если писать код, не приходя в сознание - машины будут врезаться в деревья.
Если у вас разработчики генерят ТАКОЕ - то нужно не правила про двойной return применять, а эвтаназию вводить. Потому я продолжаю утверждать, что ISO26262 и кровь абсолютно никак не связаны.
Не нужно никакого ISO26262, чтобы понять, что код тойоты плохой. Для этого достаточно наличия глаз (чтобы прочитать код с монитора) и головы (для первичной обработки принятого оптического сигнала). А если вы гениям, сотворившим такое, дадите ISO26262 - там появится еще 20000 строчек, чтобы обойти его запреты и все равно написать говно с глобальными переменными и гонками.
Нельзя делать двойной return? Реализуем ту же логику с одинарным, по пути добавив багов. Нельзя делать глобальные переменные вообще? Передадим указатель на локальную структуру в три задачи одновременно и будем туда писать без синхронизации. По пути засунем некоторые переменные в стек, словив его переполнение (разумеется, никто о нём не узнает, про MPU ничего не написано в ISO26262, оно просто тихо испортит данные). Цикломатическая сложность? Побьем лапшу на бессмысленные функции по 10 строк каждая, подумаешь проблема. С правила про вложенные /* вообще поржал.
А на все претензии будем делать глаза трехмесячного щенка и говорить - да у нас же всё по ISO 12345, ISO 54321, ISO 00000, ISO 666 и ISO 999. Попутно такие же аргументы будут заменять реальный аудит и ревью кода - зачем аудит, всё по стандартам индустрии, оно точно безопасное.
Тут даже Rust не факт, что помог бы, хотя вот там реально сложно случайно сделать небезопасную программу. Хотя двойной return там разрешен.
Правильный ответ не "можно убрать функцию стирания", а "можно ножку WP подтянуть к земле".
Чтобы найти в базе данных отчет модульных тестов для этой конкретной платы.
Интересная и информативная база данных получится - "PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, ...". Те платы, где был другой вердикт, улетели в мусорку (или на доработку).
Микроконтроллер могут и перекинуть
EEPROM тоже могут перекинуть. Могут вообще одну плату из двух собрать, если производитель особо бедный и каждый резистор на счету. Более того, помимо серийника может еще потребоваться сохранить какие-то секреты, доступность которых через I2C шину является крайне нежелательной.
После прекращения использования сторонних файлов cookie рекламодателям предложат перейти на API-интерфейсы Google Privacy Sandbox для демонстрации рекламы на основе интересов пользователей.
Ключевой абзац. Гугл в жизни никогда ничью приватность не нарушал. И уж точно у Гугла нет никакого конфликта интересов.
Как раз в следующей статье можно будет попрактиковаться в восстановлении ключа через атаку по сторонним каналам (времени исполнения функций). Если переписать умножение через таблицу логарифмов, сложение и таблицу экспонент (или просто набор таблиц для всех множителей) - это должно стать сильно труднее (уже придется измерять попадания в кеш).
Более правильный вывод - ISO26262 и кровь абсолютно никак между собою не связаны. Точнее, хорошо, если там не окажется положительной корреляции. Потому что предполагаю, что наличие искусственных ограничений порождает более громоздкие конструкции, которые сложнее анализировать и верифицировать. А примитивность правил напоминает скорее религию и карго-культ, чем реальную попытку увеличить надежность чего-то там.
Ваш код и пример выше этот тезис прекрасно демонстрируют - нет двойных return, все переменные освящены православным священником, зато есть повреждение памяти и потенциальное удаленное исполнение произвольного кода (кто-то настраивает MPU в своих проектах?), если вдруг вход будет злонамеренным.
И бонусом уже отвлеченный вопрос - а вы разрабатываете софт для автомобилей? Если да - то для каких именно?
После использования в коде strcpy (за который даже студентов бьют по рукам) довольно странно рассуждать про вред двойного return. Тут вы его проверили, но раз вы уже посчитали длину - можно было использовать memcpy.
P.S. А, там еще помимо strcpy (который корректный, но в целом считается плохой практикой) есть переполнение temp, которое уже нигде не проверяется. Про тихие "return true" при ошибках вам уже сказали.
Норм, код некорректный, небезопасный, нечитаемый, зато без двойного return.
И то это мера для комфорта владельца, чтобы не выложить/не потерять ключ при заведенном двигателе, не уехать на другой конец города и не выяснить уже там, что теперь ты ходишь пешком.
Массовое внедрение UWB закроет такие атаки раз и навсегда. Расстояние там измеряется по физическому времени полета сигнала. И там есть свои уязвимости, но это уявимости рода "сделать так, чтобы приемник распознал 10 метров как 1", любая программная ретрансляция сигнала внесет недопустимую и моментально обнаруживаемую задержку.
Сравнение в аналоговом домене не требуется, поскольку никто не запрещает вам делать оверсемплинг при воспроизведении. Речь в статье (и в моем комментарии) идет исключительно о хранении звука в файлах на жестком диске, а не о транспортных форматах и не о семплрейте финального ЦАП. Если у вас есть сигнал на частоте дискретизации 192 кГц, в котором нет частот выше 22 кГц - вы можете сохранить его как 48 кГц, сделать интерполяцию до 192 кГц при воспроизведении и абсолютно ничего не потерять. Независимо от того, как работает ЦАП и какая там аналоговая схемотехника.
Ну так пусть оверсемплят, кто ж им запрещает-то? Можно даже оверсемплить программно при воспроизведении, специальным Hi-Fi оверсемплером, написанным на клавиатуре из бескислородной меди на дубовой подставке и скомпилированным специальной аудиофильской версией gcc в ночь на полнолуние. Но хранить-то звук в 192/24 зачем?
SP-GIST вообще не об этом. Попытаться можно, но итоговая производительность будет очень грустной для реальных задач. Индустрия сдвинулась в сторону ANN (approximate nearest neighbor) не от хорошей жизни, а от того, что точные методы слишком медленные.
Вот pgvector по ссылке выше уже ближе, HNSW работает довольно хорошо.
Типа вот так, но только типичные размерности не 2, а 128-256-512 и выше (т.е. PostGIS сразу мимо), и время поиска должно быть лучше, чем фулл-скан.
Т.е. если взять постгрес и прикрутить ему в качестве индексного движка один из ANN-методов, то он тоже станет вполне себе неплохой векторной базой (а по сравнению с некоторыми - даже отличной векторной базой). Но у постгреса такого индексного движка нет, а у векторных баз есть.
Из вашего парадокса просто следует то, что такой фильтр на практике существовать не может, поскольку нарушает принцип причинности (о чем вы сами и написали). Есть даже термин такой, "non-causal filter", для описания математических конструкций с подобными свойствами.
Раз знает микроконтроллер - знает и производитель микроконтроллера, это довольно очевидно. Но производитель МК видит только ключ, а бинарник не видит (вы его шифруете локально). Завод видит зашифрованный бинарник, но не может восстановить для него ключ.
Впрочем, подобная система строго до первого умельца с микроскопом или с какой-нибудь атакой по энергопотреблению. После этого вся серия МК становится уязвимой.
Ужас, если писать код, не приходя в сознание - машины будут врезаться в деревья.
Если у вас разработчики генерят ТАКОЕ - то нужно не правила про двойной return применять, а эвтаназию вводить. Потому я продолжаю утверждать, что ISO26262 и кровь абсолютно никак не связаны.
Не нужно никакого ISO26262, чтобы понять, что код тойоты плохой. Для этого достаточно наличия глаз (чтобы прочитать код с монитора) и головы (для первичной обработки принятого оптического сигнала). А если вы гениям, сотворившим такое, дадите ISO26262 - там появится еще 20000 строчек, чтобы обойти его запреты и все равно написать говно с глобальными переменными и гонками.
Нельзя делать двойной return? Реализуем ту же логику с одинарным, по пути добавив багов. Нельзя делать глобальные переменные вообще? Передадим указатель на локальную структуру в три задачи одновременно и будем туда писать без синхронизации. По пути засунем некоторые переменные в стек, словив его переполнение (разумеется, никто о нём не узнает, про MPU ничего не написано в ISO26262, оно просто тихо испортит данные). Цикломатическая сложность? Побьем лапшу на бессмысленные функции по 10 строк каждая, подумаешь проблема. С правила про вложенные /* вообще поржал.
А на все претензии будем делать глаза трехмесячного щенка и говорить - да у нас же всё по ISO 12345, ISO 54321, ISO 00000, ISO 666 и ISO 999. Попутно такие же аргументы будут заменять реальный аудит и ревью кода - зачем аудит, всё по стандартам индустрии, оно точно безопасное.
Тут даже Rust не факт, что помог бы, хотя вот там реально сложно случайно сделать небезопасную программу. Хотя двойной return там разрешен.
Почему не 4?
Ах, да, там же еще GPU из того же пула жрет, тогда все правильно, "ощущается как 4".
Хорошо, тогда к питанию через резистор. Я почему-то думал, что по аналогии с SPI-флешками пин инверсный.
На момент начальной прошивки закорачивать на землю пого-пином, разрешая запись.
Правильный ответ не "можно убрать функцию стирания", а "можно ножку WP подтянуть к земле".
Интересная и информативная база данных получится - "PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, ...". Те платы, где был другой вердикт, улетели в мусорку (или на доработку).
EEPROM тоже могут перекинуть. Могут вообще одну плату из двух собрать, если производитель особо бедный и каждый резистор на счету. Более того, помимо серийника может еще потребоваться сохранить какие-то секреты, доступность которых через I2C шину является крайне нежелательной.
Ключевой абзац. Гугл в жизни никогда ничью приватность не нарушал. И уж точно у Гугла нет никакого конфликта интересов.
Для этого у многих МК есть OTP flash, которую тоже нельзя стереть после записи. Так что пример реально из пальца высосан.
Как раз в следующей статье можно будет попрактиковаться в восстановлении ключа через атаку по сторонним каналам (времени исполнения функций). Если переписать умножение через таблицу логарифмов, сложение и таблицу экспонент (или просто набор таблиц для всех множителей) - это должно стать сильно труднее (уже придется измерять попадания в кеш).
Более правильный вывод - ISO26262 и кровь абсолютно никак между собою не связаны. Точнее, хорошо, если там не окажется положительной корреляции. Потому что предполагаю, что наличие искусственных ограничений порождает более громоздкие конструкции, которые сложнее анализировать и верифицировать. А примитивность правил напоминает скорее религию и карго-культ, чем реальную попытку увеличить надежность чего-то там.
Ваш код и пример выше этот тезис прекрасно демонстрируют - нет двойных return, все переменные освящены православным священником, зато есть повреждение памяти и потенциальное удаленное исполнение произвольного кода (кто-то настраивает MPU в своих проектах?), если вдруг вход будет злонамеренным.
И бонусом уже отвлеченный вопрос - а вы разрабатываете софт для автомобилей? Если да - то для каких именно?
Сим-карты (и смарт-карты в целом) программируются в основном на Java.
А копипаст кучи идентичных кусков кода вместо адекватной декомпозиции - это тоже требование ISO-26262?
После использования в коде strcpy (за который даже студентов бьют по рукам) довольно странно рассуждать про вред двойного return. Тут вы его проверили, но раз вы уже посчитали длину - можно было использовать memcpy.
P.S. А, там еще помимо strcpy (который корректный, но в целом считается плохой практикой) есть переполнение temp, которое уже нигде не проверяется. Про тихие "return true" при ошибках вам уже сказали.
Норм, код некорректный, небезопасный, нечитаемый, зато без двойного return.
Это тривиально, и представляет проблему только для RSA и только если реализовывать его по википедии - с CRT ключами это тоже тривиально.
Невозможно вычислить приватный из публичного.
HTTPS - это TCP. Маскироваться надо под WebRTC (DTLS + SRTP + STUN).