za-open-source

Для предотвращения - хотябы иногда подавать питание на эту флешку и проверять целостность данных.

Признак пропажи данных - данные пропали)

Да может.
Предотвратить - делать бэкап в еще 1 место

Может, но для этого нужны очень много предпосылок.
1. Микроконтроллер должен уметь обновлять своё ПО без вмешательства пользователя.
2. Очень желательно, чтобы он умел обновлять ПО кусками, чтобы вирус не включал целую действующую прошивку.
3. Микроконтроллер должен иметь связь с миром через цифровые каналы — да хоть через флэшку.
4. Эти цифровые каналы должны иметь такую уязвимость, чтобы этот микроконтроллер запустил функцию обновления прошивки.
5. Вирус должен быть написан под конкретный микроконтроллер.

Во многих СЛАБЫХ микроконтроллерах есть разделение памяти на программную и данных — даже если уязвимость есть, она не сможет внедрить свой программный код, придётся искать подходящую функцию в имеющейся прошивке.

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

Уязвимые роутеры есть, даже у D-Link’а попадался заражаемый. Но это не универсально, и надо смотреть под каждое устройство по отдельности.

Маловероятно:
1. Вирус должен быть написан под конкретный МК
2. Вирус этот должен как-то включать в себя оригинальную прошивку, чтобы не нарушить видимость корректной работы девайса.
3. Вирус должен как-то обойти защиту девайса. Очень многие производители шифруют прошивку и подписывают её для контроля целостности - просто взять и перепрошить не выйдет, тк левую прошивку загрузчик откажется загружать.
Для перепрошивки загрузчика нужен будет программатор, но есть ещё п4

4. Вирус должен уметь обходить аппаратную защиту девайса.
Опять же к п3 производитель может добавить какой-нибудь второй простой чип рядом с основным МК, который будет требовать подачи определенных сигналов на определённые выводы раз в N времени, иначе - выключение на уровне питания.

Так что лучше бы указать, откуда вообще вопрос родился:
1. Если это академический интерес, то ответ "да" так как МК - это по сути тоже компьютер.

2. Если вопрос относительно конкретного устройства, которое подозревается в заражении - на вопрос можно ответить, только если укажешь, что это за устройство и его модель.

Может ли вирус попасть в микроконтроллер?

Да, но вирус будет для микроконтроллера, и ПО микроконтроллера должно уметь обновлять себя. Это в классическом понимании. Или внешнее окружение должно иметь возможность воздействовать на прошивку микроконтроллера.
Например вирус на PC может модифицировать прошивку контроллера флешки на зараженную.

если прям совсем в лоб ответить - да, может (хотя надо уточнить какой микроконтроллер)

но по факту, это должен быть вирус который специально написан именно для такого микроконтроллера, крайне маловероятно что вы такой встретите в живой среде, если вас специально никто взломать не хочет

Может. Всё, что вы можете себе представить, возможно. Но маловероятно.

Имеется в виду знаменитый WinCIH? Может, есть такие вирусы.

Схема раздела - GPT
Файловая система - FAT
Целевая система - UEFI
современные биосы тупо игнорят носители со старой схемой (MBR/DOS)

Файловую систему выбирай fat, так как ntfs некоторые биосы не умеют

Так же выбирай в биосе EFI режим загрузки
Кстати в этом режиме можно просто вручную отформатировать диск и скопировать содержимое iso установщика любым архиватором

p.s. есть еще универсальный способ, сработает как для efi режима так и для legacy mbr, скопируй iso образ на флешку каким-нибудь посекторным копированием без создания файловой системы (windd или еще чем, обычно программы создания загрузочных дисков такое предлагают), в этом случае файловая система будет cdrom и это прочитает любой биос.

В современных биосах он шьется из самого биоса, даже "DualBios" сделали - для криворучек которые запароли основной кривой прошивкой - там запустится второй и даст прошить основной.

Из операционной системы в целях безопасности нельзя такое делать, а то любой вирус вам бы биос стирал или лок на уровне биоса вешал.

С виду проблем у диска нет. Если вас пугают щелчки, то меняйте на SSD, там нечему щёлкать.
И, в любом случае, регулярно делайте бэкапы.

Да, это называется коллизия.
Идея хэш суммы в том, что она с пренебрежимо малой вероятностью повторится для похожих (sic!) входных строк.
Т.е. Если у тебя есть exe-шник и ты вычислил его хэш сумму - ты можешь подобрать другой файл с такой же хэш суммой. Но будет исчезающе малый шанс, что это тоже будет рабочий exe шник или вообще что-то распознаваемое, а не просто набор бинарного мусора.

Следует различать коллизии первого рода (у двух разных файлов сошлась хэшсумма) и коллизии второго рода (злоумышленик подобрал другой файл под заданную хэшсумму).

Хеши бывают разной длины. От 8 бит до 512 бит. И в зависимости от сложности самой функции
и от разрядности возможны такие ситуации что для разных файлов вдруг хеш совпадает.

В криптографии отдельно изучают парадокс дней рождений (когда группа случайных людей порядка
20 человек вдруг имеет 50% вероятность нахождения пары людей с одинаковой датой рождения
вида MM/DD). Вобщем этот парадокс для криптунов - шибко важный и они носятся с ним везде
и любят обсуждать применительно к атакам на шифры и ЭЦП.

Кажется Брюс Шнайер предлагал свою метрику для ожидания коллизий в зависимости от длины
ключа.

В Java существовала атака на хеш-мап основанная на том что хеш-функция несовершеннаа
и может давать коллизии.

Для латиницы

public static int hashCode(byte[] value) {
        int h = 0;
        byte[] var2 = value;
        int var3 = value.length;
        for(int var4 = 0; var4 < var3; ++var4) {
            byte v = var2[var4];
            h = 31 * h + (v & 255);
        }
        return h;
    }

Насколько я понимаю ни к чему страшному атака не приводила. Просто хеш-мапа вырождалась
в список и некоторые тайм-критичные системы (Tomcat/Jetty) могли тормозить на отдаче хедеров.
Фиксилось это просто заменой бакетов хеш-табли на деревья при определенном условии. ТАм
было что-то вроде - если длина цепочки в бакете больше чем константа - то генерировать дерево.

Вобщем некоторые кибер-задроты не поленились и нашли такие строки которые дают одинаковые хеши.

Некоторые хеш-функции (CRC-32) обладают интересными свойствами. На диапазоне целых до 4 млрд
эта функция вообще дает 0 коллизий и точно отображает ключ в бакет. Кажется это свойства
тех полиномов на базе которых CRC вообще строятся. (Насчет CRC я точно не уверен. Мой приятель
этот факт проверял на С++).

Я честно говоря считал что в хешах уже все известно но периодически их придумывают новые с разными
свойствами. Вот для нужд биг-даты в 2008 был придуман Mur-mur https://en.wikipedia.org/wiki/MurmurHash

И еще примерно 9 лет назад один чел создал хеш-функцию xxhash которая якобы супер-быстрая
https://github.com/Cyan4973/xxHash но я не мерял. Такая себе функция-шустрик.

Вобщем из свойств раздличают криптографические (SHA) (трудно создать коллизию) и вот эти вот шустрики
которые летают как CPU и годятся для хешей но при этом ЭЦП на них строить не рекомендуется.

Может. Называется - коллизия хэша.

Между телефоном и вышкой вроде какое-то шифрование есть.
+ на транспортном уровне в проводах вполне может быть шифрование.

Остальное уже вне ответственности оператора

Очевидно из названия, что фонд свободного ПО занимается исключительно программным обеспечением, а не аппаратным.
=> По определению не может существовать процессора, который был бы одобрен фондом свободного ПО.

Ну и кроме микрокода в процессорах есть ещё куча всего закрытого - такая уж это индустрия.

100% свободный процессор

Свободный от кого? Если процессор можно будет изготовить только на линиях конкретной фабрики - считается ли он свободным?

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

Если у процессора полностью закрытая топология, но заявляется, что никакого изменяемого микрокода нет - это свободный процессор?

Если топология открытая, но при этом все сторонние IP-блоки закрытые. Это свободный процессор?

А так есть ARM архитектура, на которую можно купить лицензию (на архитектуру или даже на готовую реализацию ядер).

Есть ещё совсем открытый RISC-V

существует ли 100% свободный процессор

Существует несколько открытых реализаций risc-v: https://en.wikipedia.org/wiki/RISC-V#Open_source наверняка среди них есть и свободные.