[Palnich 0]

Считать прошивку с MSP430F135 по BSL, в JTAG пережжен fuse. Есть два одинаковых прибора, один рабочий, у второго сгоревший чип(перенапряжение питания). Чип поставил новый, и теперь черпаю инфу, как сделать дамп флеши рабочего контроллера. В Errata описан баг BSL3, суть которого, если я правильно понял, заключается в том, что если контрольная сумма получаемого BSLом фрейма(блок данных, команда?) равна некоторому адресу адресного пространства флеши, то такая команда может изменить содержание этого некоторого адреса. Если я правильно понял, пароль 32 байта, размещен по адресу от FFE0h до FFFFh, и на него нацелен вышеописанный баг, точнее, на контрольную сумму пароля. Читаю MspFet v1.6.1007, тренируюсь на пустом кристалле, записываю левые прошивки, разлочиваю,это не проблема,когда есть исходник. Но не могу вкурить, как раздобыть вектора эти прерываний. Не программист, а больше радиолюбитель, не хватает знаний. Может кто из форумчан направит на путь истинный по добыванию прошивки? 

[Obam 30]

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

[PDA 0]

Пароль доступа по BSL (32 байта) = адреса прерываний с ffe0 по ffff

[Palnich 0]

Почитал даташит(там в таблице 6-3 есть ошибка-опечатка: адрес прерывания компаратора_А указан 0FFF9h, а должен быть 0FFF6h). Нарисовал себе табличку с адресами, для наглядности так сказать, расставил периферию. Но всё равно не исчезает туманное понимание предмета обсуждения. То, что вектора прерываний и есть пароль, это мне понятно, а вот как использовать уязвимость контроллера для вытаскивания содержимого-пока что смутно. Сам процесс мозгования достаточно интересный, но появилось ощущение топтания на месте. Буду дальше просвящаться, как грицца ученье-свет, а неученье-чуть свет, и на работу.

[k155la3 26]

Ну, чисто ги-по-те...-ски. На Вашем "кролике" проверьте (для этого должно быть непреодолимое желание, подкрепленное ... не знаю уж чем )

взаимозависимость потребления тока контроллером (осцилограф, в реалтайм) при работе с паролями, близкими к истинным. (полное совпадение, несовпадение

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

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

Не помню только, кажется в старших сериях - после нескольких неудачных попыток девайс понимает что идет подбор пароля и трет прошивку.

 

 

[Palnich 0]

         k155la3, за идею промерять потребление тока Вам спасибо, как вариант на будущее буду иметь ввиду, старенький С1-72 хранится в чулане. Кусок работы это приличный, с маловероятным положительным исходом, как мне кажется. Но что-то в этом есть. Спектр эми процессора точно не смогу промониторить, эми проводов в стене квартиры ещё определю, а процессора-нет :). Да, трёт прошивку при неправильном вводе пароля в версиях BSL выше 2.01, здесь можно подбирать, пока не надоест, или пока флеш не рассыпется.

        Теперь о "кролике". Баг в этих контроллерах выражен в следующем: когда контрольная сумма кадра данных (фрейма), получаемого BSL,  равна определённому значению, этот фрейм может повлиять на ячейки памяти(либо ОЗУ, либо регистры периферийных модулей). С помощью COM Port Toolkit подключился к COM-порту в режиме прослушки, и начал посылать подопытному микроконтроллеру эти самые фреймы, с разными контрольными суммами, равными адресам периферии и RAM. И после серии из не менее 20 рандомных фреймов с checksum равной адресам периферии, контроллер внезапно стал отвечать А0, 90. (для справки: ответ А0-приходите завтра, ответ 90-заходите), когда до этого всегда отвечал только А0, а 90 отвечал только при вводе правильного пароля. При этом считать флеш тоже не дал. Журнал не вёл, и какая именно последовательность команд привела к такому результату точно не отследил. Не знаю, что именно это было.

         Возник следующий вопрос: что из периферии или ОЗУ прямо запрещает чтение из флеш? 

        

         

[mcheb 0]

Советую внимательно прочитать SLAU319S–July 2010–Revised April 2018  MSP430™ Flash Device Bootloader (BSL) документ. Многие вопросы и догадки отпадут.

[k155la3 26]

7 hours ago, Palnich said:

(1) k155la3, за идею . . . .

(2) Возник следующий вопрос: что из периферии или ОЗУ прямо запрещает чтение из флеш?         

1. Эт пожалуйста.... этого добра у меня навалом.... если что - "я себе еще напечатаю"   Данный-конкретный метод - типовой. Еще "медвежатники" использовали для механических замков.

2. Из "запретов" доступа к флеш ничего припомнить не могу, соотв-но есть большая вероятность, что чтение никогда не блокируется, разве что на специф. режимах, вроде в моменты записи ячеек флеша. Запрет скорее всего обеспечивается софтово FW BSL, и физически соотв-ет какому-либо биту-байту-слову в RAM. Т.о. если тем или иным образом будет получена возможность доступа к RAM по записи - есть возможность изменить этот флаг и "приболатать" FW на полный доступ.

Один из старинных (тоже типовых) методов - затирание стека. Эффективно, когда стек расположен стандартно. В контроллер передается пакет данных, например запрос на их запись.(то что он их "забракует" - не важно). Важно то, что при приеме он еще "не знает", что это "деза-троян", и начинает принимать эти данные в буфер RAM, который растет "вверх", в сторону стека. Если в FW контроллера есть "дыра", - отсутствие проверки максимального-разрешенного верхнего адреса для записи принимаемых данных - то стек будет затерт байтами из принимаемого пакета. Соотв-но в нужные адреса пакета "трояна" прописываются адреса возврата на его "старт" для работы, и управление передается от FW контроллера на троянское.