Форум РадиоКот

Друзья, прошу совета у знающих людей! Обрисую ситуацию: Работаю в фирме по обслуживанию домофонов. Злой супостат портит панели. Где то шокером долбанут, где то еще каким способом. И вот скопилась у нас кучка вызывных панелек с убитыми процами АТ8515. Решил попробовать себя в востановлении. Заменить проц не проблема, проблема прошить! На плате есть ISP разъем, Прикупил я под это дело програматор (OLIMEX AVR-ISP-MK2) установил AVRstudio 5.1 подключился и скачал прошивку с рабочей панели.
Вот фьюзы:

Спойлер

S8515C = [ ]
WDTON = [ ]
SPIEN = [X]
EESAVE = [ ]
BOOTSZ = 1024W_0C00
BOOTRST = [ ]
CKOPT = [X]
BODLEVEL = 4V0
BODEN = [X]
SUT_CKSEL = EXTHIFXTALRES_16KCK_64MS

HIGH = 0xC9 (valid)
LOW = 0x3F (valid)

Вот Лок биты:

Спойлер

LB = PROG_VER_DISABLED
BLB0 = NO_LOCK
BLB1 = NO_LOCK

LOCKBIT = 0xFC (valid)

И так вопросы...

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

У меня была глюкнутая панель (не сохранялись ключи в памяти и изменения в настройках(память 24с64)) я решил на этой панельке экспиримент и провести. Стер процессор, загрузил фьюзы и флеш, епром и все... панель потухла. Я сегодня в програмировании вообше первый раз себя попробовал, поэтому надеюсь вы поможете мне советом.

Думаю, по тексту дизассемблера прошивка всё таки лоченая. И запрограммированные LOCK BIT 0xFC говорят о том же...

Я не понял, а зачем вам ДИЗАССЕМБЛЕР? Если прошивка не залочена,
Считывается HEX (или BIN) с процессора, считываются фьюзы, потом в чистый процессор записываюется HEX (или BIN), записываются фьюзы- и всё..
Если процессор в DIP-е, на панельке- то вообще с собой можно таскать несколько рабочих МК, и просто их перетыкать.

akl писал(а):Думаю, по тексту дизассемблера прошивка всё таки лоченая. И запрограммированные LOCK BIT 0xFC говорят о том же...

Спасибо за пояснение... Халява не прокатила. Я так понимаю с моим скудным знанием вопроса сделать ничего не выйдет?

АлександрЛ писал(а):Я не понял, а зачем вам ДИЗАССЕМБЛЕР? Если прошивка не залочена,
Считывается HEX (или BIN) с процессора, считываются фьюзы, потом в чистый процессор записываюется HEX (или BIN), записываются фьюзы- и всё..
Если процессор в DIP-е, на панельке- то вообще с собой можно таскать несколько рабочих МК, и просто их перетыкать.

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

Dexx писал(а):Прочитал на просторах,что если прошивка залочена,то она не дизасембелируется,

Если прошивка залочена, то считанный HEX или BIN будет "FF"
Зы.. Если уж НАЧИНАЮЩИЙ, то не надо в такие дебри лезть, достаточно PonyProg или Uniprof - считываете фьюзы и содержимое памяти (и, если это что- то нормальное на вид) - то же самое записываете в новый МК.

АлександрЛ писал(а):Если прошивка залочена, то считанный HEX или BIN будет "FF"
Зы.. Если уж НАЧИНАЮЩИЙ, то не надо в такие дебри лезть, достаточно PonyProg или Uniprof - считываете фьюзы и содержимое памяти (и, если это что- то нормальное на вид) - то же самое записываете в новый МК.

Да я б с радостью не лез. Только вот програмер не работает с этими програмами. Он я так понимаю не через СОМ работает. А "что-то нормальное на вид" это как? Можно в двух словах,на что внимание обращать? И еще вопрос- Если у меня прошивка не "FF" Значит все в порядке и она не залочена, и я просто не так что то делаю при записи?

Dexx писал(а):. А "что-то нормальное на вид" это как?

Это когда вся запись состоит не из одних нулей или FF.

А у этого программатора СВОЯ какая- то программная оболочка есть? - вот что- то типа тех, которые я называл?

зы.. Вроде как есть.. Тогда считайте содержимое памяти МК, и посмотрите, как оно выглядит.

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

При беглом взгляде на текст видно, что это не код, а пьяный бред сивой кобылы. Не факт, что залоченный МК при считке дает FF . Стертый - да, а залоченный может давать что угодно, кроме фактического кода. Мой склероз за давностью лет ручаться не может, но вроде бы получал какую-то регулярную последовательность. Бредовую, само собой.

НАПАЛМ : эта прога называется дизасемблер. Можно найти в сети. Но и без него тоже можно: загружаем хекс в Студию - и видим листинг кода. Только нужно разбирать его с понятием: дизасму пофиг, натуральный код там, текст для ЖКИ или массив констант.

АлександрЛ писал(а):

Dexx писал(а):Прочитал на просторах,что если прошивка залочена,то она не дизасембелируется,

Если прошивка залочена, то считанный HEX или BIN будет "FF"
Зы.. Если уж НАЧИНАЮЩИЙ, то не надо в такие дебри лезть, достаточно PonyProg или Uniprof - считываете фьюзы и содержимое памяти (и, если это что- то нормальное на вид) - то же самое записываете в новый МК.

залоченная прошивка читается как 00 01 02 03 04 05 06 и т.д. по порядку

ARV писал(а):залоченная прошивка читается как 00 01 02 03 04

Ну, возможно, и так..

я бы хотел подчеркнуть, что "не возможно", а именно так.
залоченный МК не обрабатывает принятый адрес ячейки по SPI, поэтому он остается во внутреннем регистре сдвига и выдается при следующем обращении. в итоге вместо данных из ячейки всегда возвращается младший байт адреса ячейки, которую пытались считать. так как считывание обычно идет последовательно, мы и будем получать последовательный набор байтов от 0х00 до 0xFF.

ARV писал(а):я бы хотел подчеркнуть, что "не возможно", а именно так.

Ну ARV конечно виднее, но простой эксперимент показывает другое. Контроллер ATmega256rfr2, lock bits 0xFC. Прошивка полностью читается как 0xFF.

и вы хотите сказать, что этот результат получен вами при SPI-считывании прошивки?! уверены, что не JTAG-ом пользовались?

ARV писал(а):уверены, что не JTAG-ом пользовались?

им самым. тогда вопрос с целью повышения образованности: а в чем разница? Считывание самого flash разве не одинаково организано?

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

как работает JTAG - не знаю, но думаю, что в нем регистр входящих данных и регистр выходящих данных не объединены, поэтому при общем принципе (отсутствия обновления информации в регистре) JTAG просто выдает то, что в этом самом "выходном" регистре было. я не исключаю, что может читаться и не 0xFF, если в "предыдущий" раз JTAG выдавал что-то иное... но это мои домыслы, а вот про SPI я уверен.

я так понимаю, залоченный МК к flash вообще не обращается, вся работа гаснет на этапе интерфейса с программатором...