Pull to refresh

Comments 39

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

Кстати, номера весьма известные, для тех, кто смотрел сериал Lost
lostpedia.fandom.com/ru/wiki/Числа

Числа 4 8 15 16 23 42 — номера кандидатов замены Джейкоба в качестве «защитника острова».

После ввода чисел таймер становится в положение «108:00», указывающее на необходимость вновь ввести числа через 108 минут (4 + 8 + 15 + 16 + 23 + 42 = 108).

108=0х6с

Создатели железок любят всякую нумерологию :)
Я например встречал число Пи, в качестве ключа в одной из железок
Если бы производитель сделал проверки ключа не байтами с вываливанием у случае первого неуспеха, а проверки всех 7 в цикле, с выставление флага и последующей проверкой флага, то наверное бы не вышло так.
Тоже опасно. Время исполнения кода с очень большой вероятностью будет различным для итераций цикла с различным результатом проверки. Особенно если это будет написано на С и потом оптимизировано компилятором. Компилятор наверняка выпилит строчку кода, когда флаг не нужно менять. Т.е. будет просто немного сложнее, разница во времени будет говорить о том, что один из 7 байтов оказался угадан верно/неверно. Если по уму, то надо пропускать n-раз через криптографически стойкую хэш-функцию как минимум и уже потом сравнивать.
Т.е. будет просто немного сложнее, разница во времени будет говорить о том, что один из 7 байтов оказался угадан верно/неверно.

bool weGood=true;
for (int i=0;i++;i<7)
{
   if (key[i]!=input[i]) weGood=false;
}
if (!weGood) killIt();


как вы здесь определите какой байт верный?
по количеству присваиваний переменной weGood?
это вообще будет заметно на анализаторе?
как вы здесь определите какой байт верный?
Да, в общем-то почти точно так же как в статье. Берём какой-нибудь пароль, замеряем его время. Перебираем первый байт, замеряя время и сравнивая с предыдущим показанием. И так по всем байтам.
по количеству присваиваний переменной weGood?
Именно так. Разница будет в длительность исполнения инструкции присваивания weGood.
это вообще будет заметно на анализаторе?
От анализатора зависит. Salea logic со своими несчастными 24МГц может и не увидит (хотя частоту атакуемого процессора можно и уменьшить). А вот осциллограф на 4Gsa/s очень даже увидит. Если использовать FPGA, то ещё и дешевле выйдет. Так или иначе цена подобного взлома достаточно низка для практического применения.
Так и с этим можно побороться — добавить в цикл for случайную задержку. Для начальной инициализации генератора случайных чисел использовать, например, шумы АЦП.

Есть безопасная реализация memcmp, где введенные байты xor'ятся с образцом, а результаты orr'ятся между собой.

Так слишком просто и не интересно — потенциальный взломщик обломится сразу. А со случайной задержкой он еще помучается, а при достаточно сильной мотивации — помучается долго. Впрочем, Вы правы — при этом тоже не помешает использовать безопасные функции сравнения для пущей гарантии безуспешности мучений взломщика.
в борьбе со случайной задержкой статистика помогает)
Статистика помогает выявить закономерность на фоне случайного шума, а если закономерности нет, то и выявлять нечего, кроме характеристик генератора случайных чисел. Естественно, для этого надо учесть вполне справедливое замечание 15432 выше.
Чтобы взломщики не забывали заземлять вход АЦП перед началом работы? )
АЦП может иметь и внутренние входы — например, датчик температуры.
пароль проходит только при -15С :)
тогда уж добавлять случайную задержку, но когда данная техника разрабатывалась, такие атаки не афишировались. статья великолепна хотя бы тем, что не стоит бояться сложных задач, автор и опубликовал, за что жирный плюс
Я бы просто добавил рандомную задержку перед ответом. Причём достаточно большую, десятки или сотни миллисекунд.

Отличное завершение детектива!

По поводу чисел: каюсь, моя небольшая отсылка. Я исправил ключ в памяти контроллера, чтобы не светить настоящий. Это мои тараканы — «Если ты параноик, то это не значит, что за тобой не следят». Для статьи ключ не важен, поэтому я решил отвязаться от чужой интеллектуальной собственности. Ну а т.к. ключик 7 байт — то последовательность почему-то и всплыла в голове.
По поводу защиты: производитель и не заявлял, стойкость к взлому. А также он предоставил возможность заменить загрузчик на свой, если это необходимо. Здесь все справедливо, как по мне.
А вот в плане перебора: любое ветвление в коде потенциально выдает по времени ветку, которая выполняется. Предположим, что мы даем ответ вообще по аппаратному таймеру, т.е. заведомо позже завершения алгоритма и всегда с одной задержкой. Тогда всего лишь отпадает атака по времени отклика, но мы начинаем измерять шум переключений вентилей и анализировать все это дело на FPGA и опять же, не достаточно стойкий алгоритм выдаст себя с потрохами. Т.е. стойкость к взлому и сам взлом — это такая гонка вооружений, которая никогда не кончится. Производители контроллеров также применяют различные трюки, к примеру можно посмотреть на МК DS5002 от Dallas (ныне Maxim)…
По поводу чисел: каюсь, моя небольшая отсылка. Я исправил ключ в памяти контроллера, чтобы не светить настоящий.

ну все равно пасхалка :)
было интересно

Вот так совпадение. Спасибо! Я сегодня тоже неожиданно обнаружил в блоке климата мазда cx5 защиту на r5f2138, в моде 3 контроллер не завелся, а в моде 2 отозвался но 0xff не принимает. Пойду почитаю даташит, может и у меня этот busy есть...

Очень крутое расследование-исследование. Интересно, как Vag защищает свои блоки.

По вагу, касательно дизельгейта, есть очень хороший обзор. Вот где действительно высший пилотаж… Видео, правда на английском.
youtu.be/7t4paclIwuU
Там не высший пилотаж. Этому человеку «помогли» с инфой которую он бы никогда не получил из открытых источников сам… Дальше он проделал достаточно тривиальную работу зная что сам «эффект» воспроизводится в этом ПО…
Огромное спасибо за статью!
У меня тоже возникла проблема с прошивкой контроллера R5F6416 в ресивере Yamaha, без знания ключа даже нет возможности стереть прошивку.
Тоже была мысль, что нужно использовать атаку по времени, но до реальных экспериментов дело у меня не дошло.
Большое спасибо за статью. Очень занимательно. Подскажите пожалуйста, каким kjubxtcrbv анализатором сигнала вы пользуетесь и ПО соответственно? Не предполагал, что перезаливкой загрузчика можно сбросить лок биты. Вероятно это справедливо только к подобным МК, но не для ATMEGA…
Логический анализатор виден на главном фото в верхнем правом углу: китайский клон Saleae Logic.
По поводу защиты: механизмы в МК из статьи и ATMega совершенно различны.
У меня есть история как удалось сломать протокол обмена с некой железякой потому что нам в руки попала сервисная программа. Жаль только её тут рассказать нельзя.
Работая с китайцами — об этом можно сериалы снимать. Мы, например, у одной железки декомпилировали сервисную программу и исправили баги сначала в ней (например, она падала если у вас нет D:\Temp), потом в драйвере — а потом написали новую прошивку и отправили им чтобы на заводе прошивали… А у другой — выбросили драйвер вообще, так как он только скрывал команды, посылаемые устройству через последовательный интерфейс, за заумным API. Причем тамошние гуру системного программирования почему-то решили что 64-битные указатели можно конвертировать в 32-битные int и обратно…
Не, это были не китайцы. Они очень старались не давать никому свой протокол, но кто-то забыл программу на объекте и… Syser Kernel Debugger, всё такое. Обычными отладчиками не получилось.
Вспомнилось что-то сколько ошибок исправили раздебажив U.S.Robotics модем — полуряный в своё время и даже дописали особостойкую к помехам «русскую» версию протокола на 21600 :)

Попробуйте вместо Saleae Logic использовать программу PulseView от Sigrok — она гораздо удобнее.


Статья и подход к решению проблемы понравились. Только не проще ли было заменить этот МК на что-то более распространенное и написать свою прошивку для него? Вряд-ли ведь в отопителе используются какие-то сложные алгоритмы.

Спасибо, программку обязательно попробую.
А по поводу замены МК — в некоторых товарищ в итоге так и сделал, т.к. они шли с управлением по CAN-шине, а у него был спрос на переделку для включения по логическому сигналу, вот он стал PIC16 туда ставить…
PulseView от Sigrok — она гораздо удобнее.
Но жрет память как не в себя. Хотя может это конкретный плагин (i2c)

Алгоритм давно реализован прибором Martech. И работает он на нескольких версиях загрузчика, к сожалению не на всех.
Я пошел другими путями, но в итоге пароль вытащен, параллельный режим у его брата M306NBF закрыт. Чтобы не быть голословным WxxxWxx :).
Уязвимость — дело тонкое.

В чём отличие этой статьи и готового прибора? В том, что готовая железка стоит каких-то 1к евро. И информацию о том, как именно она работает, авторы железки никому не сольют…
Ну это как с теми же моторолами, которые кучей программаторов ломаются: кто постоянно на потоке занимается, тот купил уже, еще и не один. А когда разово, да еще и не к спеху, то можно и поразвлекаться.
А другой путь это какой? Так же из контроллера тащилось, или откуда-то из дампа прошивки?
У моторолы тот же принцип атаки? Как раз неспешно надо вычитать одну и покупать ничего не хочется :)
У моторолы точно не скажу, из того, что бегло слышал — атака через глич по тактовому входу. Но это не точно.
Это было актуально 3 года тому, пароль есть в загрузчике, а где взять загрузчик это совсем другое дело. Сейчас новые печки на закрытых V850E2, вот там попробуйте дернуть пароль :).
Понятно, что не актуально, интереса ради и спрашиваю :)
А вот из uPD70F..., у которых в загрузчике нет функции чтения, прошивки выковыриваются?

если бюджет позволяет - можно спилить MCU :-)

Sign up to leave a comment.

Articles