Понятие "современный микроконтроллер" мне очень интересно. Что именно Вы подразумеваете под этим? Какие именно защищены и каким образом? На чём основано это утверждение?
В статье речь идёт не о современном микроконтроллере, а о современном ЭБУ. В настоящий момент CPU Renesas и Infineon являются лидерами при разработке блоков управления в автомобильной промышленности. В основном, это RH850 и Tricore Aurix.

mark_ablov Feb 14 at 17:04

Я не особо знаком с нутрянкой ECU (так, немножко ковырял старые ECM'ы), а больше писал про GP микроконтроллеры. К примеру, свежие ревизии esp32 имеют ряд защит против FI, в частности, прошивка валидируется несколько раз в разных местах:

      check_condCOUNTER$5995();
      check_condCOUNTER$5995();
      check_condCOUNTER$5995();
      check_condCOUNTER$5995();
      check_condCOUNTER$5995();
      check_condCOUNTER$5995();
      check_condCOUNTER$5995();
      ets_printf("wait uart download(secure mode)\n");
      memw();
      if ((_DAT_60004038 & 0xf) == 7) {
        uVar4 = uart_baudrate_detect(0);
        uart_div_modify(0,uVar4);
      }
      else {
        detect_uart_usb_spi_boot_mode(uVar4);
      }
      ets_uart_download(0);
      ets_printf(&DAT_3ff1ab19);
      uart_tx_flush(DAT_3fcef14c);
      goto LAB_40043c78;
    }
    check_condCOUNTER$5987();
    check_condCOUNTER$5987();
    check_condCOUNTER$5987();
    check_condCOUNTER$5987();
    check_condCOUNTER$5987();
    check_condCOUNTER$5987();
    check_condCOUNTER$5987();

Чтоб успешно обойти эту проверку, нужно успешно сглитчить несколько раз подряд. Есть так же защита от clock glitch'ей. Некоторые МК имеют на борту блоки детектирующие voltage glitch. Кроме противодействия глитчам ещё и добавляют защиту от CPA (Correlation Power Analysis). Я к тому, что стандартная атака FI через питание/тактирующий сигнал известна уже давно и производители чипов добавляют механизмы, препятствующие её проведению.

ecurep Feb 14 at 21:50

Верно, множественные проверки могут помочь, однако я бы особо не превозносил ESP32, известно много успешных глитчей микросхем этой серии (https://github.com/ggonzalez/ESP32_GLITCHER).
Обращаю также Ваше внимание на то, что данный процессор глитчится по управлению питанием Flash памяти, а не питанием ядра.
Всё что Вы говорите, безусловно, правда и это хорошо, что происходит то, что происходит. Другое дело что в нашем автомобильном деле еще недавно никто процессоры и вовсе не закрывал, и взламывать их просто не было никакой необходимости.

mark_ablov Feb 14 at 22:53

много успешных глитчей микросхем этой серии (https://github.com/ggonzalez/ESP32_GLITCHER).

Это глитчер, базирующийся на esp32, а не глитчер самого esp32 :)

Тем не менее, да, есть известные атаки. Самые актуальные - https://courk.cc/breaking-flash-encryption-of-espressif-parts и https://www.usenix.org/system/files/woot24-delvaux.pdf. Но в обоих случаях речь не идёт о тривиальном voltage glitch (хотя первая атака и включает его).

Обращаю также Ваше внимание на то, что данный процессор глитчится по управлению питанием Flash памяти, а не питанием ядра.

Не так давно на CCC была интересная презентация про глитч через питание OTP - https://media.ccc.de/v/38c3-hacking-the-rp2350

ecurep Feb 14 at 23:23

Да, согласен, перепутал. Но точно что-то проходило. Помню глитч был по вольтажу и по clock. К сожалению ссылка на материал не осталась.

datacompboy Feb 14 at 23:51

https://raelize.com/blog/espressif-systems-esp32-glitching-otp-transfer/ ?
или https://courk.cc/esp32-c3-c6-fault-injection

mark_ablov Feb 18 at 11:23

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

Nick0las Feb 14 at 05:47

Я правильно понял, что glitch атака направлена на загрузчик и ломает исполнение кода в момент старта, когда загрузчик проверяет, залочен блок на чтение, или нет?

ecurep Feb 14 at 16:24

да. так как обесточивается флеш память, она читается с ошибками, вследствие чего изменяется SSR, опеределяющая, закрыт процессор или нет.

Nick0las Feb 14 at 20:06

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

ecurep Feb 14 at 21:52

Как и говорилось в статье, чтение можно оценить по потреблению и воздействовать на участки, которые связаны с этим процессом (или находятся на определённом удалении).
Процессор RH850 проивзводит проверку как раз при получении команды на чтение, но это не мешает его успешно заглитчить...

Crash-100 Feb 14 at 21:53

Есть сомнения, что после замены eeprom можно будет снять CP

ecurep Feb 14 at 21:53

Здесь Вы, безусловно, правы. Но возможно перекинуть защиту компонентов из оригинального EEPROM. Если я буду описывать как это сделать, придётся писать отдельную статью...

Crash-100 Feb 15 at 16:51

Очень бы хотелось услышать как, пусть даже в новой статье!