Соглашусь, пожалуй, но это еще более редкий источник, чем Нибелунги. К тому же, чтобы связать племена богини Дану с толкиновскими эльфами нужно почитать и про то и про другое, а художник Толкина явно не читал.
Если я правильно помню, то до Толкина «стандартные» фентезийные эльфы были разве что в Песни о Нибелунгах; собственно, «стандартное» фентези и «стандартный сеттинг» (люди-орки-гномы-эльфы) с Толкина и началось.
Поэтому неудивительно, что художник о них не знал (не читать же ему книгу, в конце-то концов).
Вот еще такой сценарий пришел в голову. Если пин-код довольно короткий, то его можно перебирать брутфорсом.
Если введен неправильный пин-код — будут вылезать неправильные пароли. Пароли слить пачкой нельзя, только по-одному с задержкой в секунду на каждый. То есть перебор можно делать очень, очень долго.
Дополнительно можно включить внутренний счетчик, который через энное число неверных вводов тихо сменит внутренний ключ, и перебор станет вообще бесполезным.
Окей, вы сделаете программную защиту от слишком частого ввода — но что мне помешает подпаятся к ножке reset или к питанию и сбрасывать девайс после каждого неудачного ввода?
Конечно, можно сохранять количество неудачных попыток во flash или в eeprom, но такую проверку можно попытаться обойти с помощью глитчинга, который при открытых исходниках прошивки становится проще.
Если баг подтвердится, туда несложно поставить разъем под смарт-карту, сертифицированную по всем современным стандартам безопасности. Место на плате есть.
На мой взгляд, это наилучший выход.
Еще очень интересно насколько хардварная криптография у STM уязвима к side-аттакам. Я особо этот вопрос не копал, но сходу находится вот эта презентация, где сами STM рекомендуют использовать микруху STSAFE.
Я к сожалению сам не знаю, как эти проблемы хорошо решить, но подозреваю, что нужно искать более надежный контроллер, специально предназначенный для хранения ключей (типа как в симках и банковских картах). У stm32 с этим не очень хорошо (да и не позиционируются контроллеры f-серий как особо защищенные), к тому же, на вопросы о выявленных проблемах они предпочитают просто отмалчиваться.
Т.е. пароли сами по себе храниться в устройстве не будут? Просто в статье вроде написано немного не так:
Что в итоге будет в бета-версии устройства?
Хранение персональных данных (контакты, ключи шифрования)
Окей, допустим пароли не хранятся.
Но пин-код-то будет храниться в устройстве? Что мне помешает разобрать коробочку, подпаяться к SWD, слить прошивку и найти там пин-код?
Расскажите, пожалуйста, а как вы пароли храните и генерируете? Что будет, если у меня сопрут такое устройство — можно ли будет из него пароли вытащить?
Даа, грустно! Ведь mbedOS вроде как юзает asan clang'овский, на гитхабе хостятся и всякие другие модные слова употребляют. И на С++ пишут, а не на С.
Но нет, все равно malloc, а не new хотя бы, никаких умных контейнеров, и опять memset вместо std::fill. Фу.
Единственное, что из статьи не ясно — в чем же именно заключается поддержка GNU Arm Embedded? Я несколько лет назад проверял, что PVS-Studio сходу умеет работать с arm gcc — в конце концов, это ведь просто gcc.
Видимо, теперь учитывается какая-то специфика, но как раз про это в статье не написано.
Конечно, обработка ошибок — это не цель. Основная цель — чтобы все работало.
Но внутри этой цели есть всякие мелкие подзадачи, например, чтобы код было легко поддерживать, легко читать и приятно писать. Этому и посвящена упомянутая статья.
А насчет разыменования нулевого указателя… в микроконтроллерах, например, это может быть просто совершенно обычное поведение, есть ячейка памяти с адресом ноль и в нее можно писать (и читать) вполне штатно.
Реальная проблема в том, что это не должно быть UB. Это неудобно, надежную программу так не напишешь.
Все UB все равно не уберешь из программы, как ни старайся. UB — это то, что происходит, когда вы нарушаете некое обещание.
Например, ожидает функция на вход нуль-терминированную строку, а вы нуль-терминатор забыли. И что делать бедной функции? Она не может проверить, что в строке нет терминатора, если его нет. Окей, представим, что может — она должна это делать каждый раз?
Окей, ладно, со строкой слишком просто. Представим, что у вас есть функция поиска по ациклическому графу. Предполагается, что граф ациклический — но что будет, если вы передадите туда граф с циклом?
У всего UB логика та же самая — предполагается, что программист уже сделал все нужные проверки и соблюдает некий контракт. Компилятор считает, что контракт соблюдается, и на основе этого может оптимизировать программу.
Вот, к примеру, godbolt.org/z/9Qa0hc — тот факт, что переполнение знаковых целых это UB (а значит, этого никогда не происходит) позволяет компилятору вообще убрать сравнение.
Я правильно понял, что под этим понимается шифрование файла с прошивкой на SD-карте, а не шифрование прошивки в устройстве?
Ммда, ну, поживем-увидим.
Слава богу, решили выпилить этот восклицательный знак, фуф.
Конкатенация строк в названиях переменных?
Поэтому неудивительно, что художник о них не знал (не читать же ему книгу, в конце-то концов).
GOD MODE UNLOCKED — Hardware Backdoors in x86 CPUs
Окей, вы сделаете программную защиту от слишком частого ввода — но что мне помешает подпаятся к ножке reset или к питанию и сбрасывать девайс после каждого неудачного ввода?
Конечно, можно сохранять количество неудачных попыток во flash или в eeprom, но такую проверку можно попытаться обойти с помощью глитчинга, который при открытых исходниках прошивки становится проще.
На мой взгляд, это наилучший выход.
Еще очень интересно насколько хардварная криптография у STM уязвима к side-аттакам. Я особо этот вопрос не копал, но сходу находится вот эта презентация, где сами STM рекомендуют использовать микруху STSAFE.
Да, это ссылки про f103, но все же.
Я к сожалению сам не знаю, как эти проблемы хорошо решить, но подозреваю, что нужно искать более надежный контроллер, специально предназначенный для хранения ключей (типа как в симках и банковских картах). У stm32 с этим не очень хорошо (да и не позиционируются контроллеры f-серий как особо защищенные), к тому же, на вопросы о выявленных проблемах они предпочитают просто отмалчиваться.
Окей, допустим пароли не хранятся.
Но пин-код-то будет храниться в устройстве? Что мне помешает разобрать коробочку, подпаяться к SWD, слить прошивку и найти там пин-код?
Непонятно только зачем у них там С вообще. Но это к ним вопрос, не к вам :)
А вот тут хотелось бы поподробнее!
Но нет, все равно malloc, а не new хотя бы, никаких умных контейнеров, и опять memset вместо std::fill. Фу.
Единственное, что из статьи не ясно — в чем же именно заключается поддержка GNU Arm Embedded? Я несколько лет назад проверял, что PVS-Studio сходу умеет работать с arm gcc — в конце концов, это ведь просто gcc.
Видимо, теперь учитывается какая-то специфика, но как раз про это в статье не написано.
Но внутри этой цели есть всякие мелкие подзадачи, например, чтобы код было легко поддерживать, легко читать и приятно писать. Этому и посвящена упомянутая статья.
А насчет разыменования нулевого указателя… в микроконтроллерах, например, это может быть просто совершенно обычное поведение, есть ячейка памяти с адресом ноль и в нее можно писать (и читать) вполне штатно.
Все UB все равно не уберешь из программы, как ни старайся. UB — это то, что происходит, когда вы нарушаете некое обещание.
Например, ожидает функция на вход нуль-терминированную строку, а вы нуль-терминатор забыли. И что делать бедной функции? Она не может проверить, что в строке нет терминатора, если его нет. Окей, представим, что может — она должна это делать каждый раз?
Окей, ладно, со строкой слишком просто. Представим, что у вас есть функция поиска по ациклическому графу. Предполагается, что граф ациклический — но что будет, если вы передадите туда граф с циклом?
У всего UB логика та же самая — предполагается, что программист уже сделал все нужные проверки и соблюдает некий контракт. Компилятор считает, что контракт соблюдается, и на основе этого может оптимизировать программу.
Вот, к примеру, godbolt.org/z/9Qa0hc — тот факт, что переполнение знаковых целых это UB (а значит, этого никогда не происходит) позволяет компилятору вообще убрать сравнение.