Как правильно пользоваться IDA

[Wladimir_TS]

Есть задача - дизассемблировать прошивку для Microchip PIC16C65

Исходник в Intel HEX. Корректный прошивается, работает. Но утратили исходник. Писано точно на ассемблере ибо это где-то 2001 год.

Применял PicDisH - но он не знает PIC16C65 - сделал PIC16F877 - некорректно - обратно идентично не компилируется.

Пробую IDA - но выдает пока фигню какую-то - разобраться сложно - наворочено зело. Пока в сети внятных русскоязычных "хелпов" именно по микроконтроллерам не нашел, только Win приложения причем описан этап отладки, а не корректного дизассемблирования и настройки IDA.

Далее тут буду писать об "творческих и не очень УзбЭках". В соседней теме удалю.

Ладно вопрос по существу - поставил IDA 6.8.15.... Пробую дизассемблировать - а выдает такое :

; Reset Vector
CODE:0000
CODE:0000                 ; public RESET
CODE:0000 RESET:
CODE:0000
CODE:0000 ; FUNCTION CHUNK AT CODE:0080 SIZE 00000054 BYTES
CODE:0000
CODE:0000                 bsf     BANK0:PCLATH, 3
CODE:0001 ; assume pclath = 8
CODE:0001                 call    sub_CODE_FC0
CODE:0002                 bcf     BANK0:PCLATH, 3
CODE:0003 ; assume pclath = 0
CODE:0003                 b       loc_CODE_80
CODE:0003 ; End of function RESET
CODE:0003
CODE:0004
CODE:0004 ; =============== S U B R O U T I N E =======================================
CODE:0004
CODE:0004 ; Interrupt Vector
CODE:0004
CODE:0004                 ; public ISR
CODE:0004 ISR:
CODE:0004                 movwf   byte_DATA_20
CODE:0005                 swapf   BANK0:STATUS, w
CODE:0006                 bsf     BANK0:STATUS, RP0
CODE:0007 ; assume bank = 1
CODE:0007                 movwf   byte_DATA_A1
CODE:0008                 bcf     byte_DATA_A2, 0
CODE:0009                 btfsc   BANK1:PCLATH, 3
CODE:000A                  bsf     byte_DATA_A2, 0
CODE:000B                 bcf     BANK1:STATUS, RP0
CODE:000C ; assume bank = 0
CODE:000C                 movlw   6F ; *o*
CODE:000D                 movwf   BANK0:TMR1L
CODE:000E                 movlw   0FB ; *v*
CODE:000F                 movwf   BANK0:TMR1H
CODE:0010                 bcf     BANK0:PIR1, TMR1IF
CODE:0011                 bcf     BANK0:PCLATH, 3
CODE:0012                 btfsc   byte_DATA_6E, 6
CODE:0013                  b       loc_CODE_4F
CODE:0014                 btfss   BANK0:PORTB, RB6
CODE:0015                  b       loc_CODE_18
CODE:0016                 bcf     BANK0:PORTB, RB6
CODE:0017                 b       loc_CODE_4F

Что за оператор "b" ???

Как понял это оператор goto - безусловного перехода - то есть получается дизассемблер тип процессора некорректно понял ? Хотя в "шапке" корректно написано 16С65...

Еще выдает такое - хотя ему дается intel HEX файл, но он типа видит его как бинарный :

Вложение 441407

Кто хорошо разбирается - поясните, что тут я не так делаю ?

[Openreel]

Еще выдает такое - хотя ему дается intel HEX файл, но он типа видит его как бинарный

https://hex-rays.com/blog/igors-tip-...x-dump-loader/

Вначале стоит книжку почитать известного автора
https://rutracker.org/forum/viewtopic.php?t=5644560
она хоть и старая, но может мозги в плавильное направление поставить.

Есть и свежей книги, конечно на инглише.

[Wladimir_TS]

Intel HEX и Motorolla S-record я различаю. Именно IntelHEX - все программаторы его корректно едет и корректно прошивают, это у IDA что-то не так настроено.

К тому-же код более-менее корректный - вот только "b" вместо "goto" - это явно что-то с настройками.

"рутрекер" оперативно скачать не смогу - тут все блокируется (и как обойти не знаю - но uTorrent не видит "сидов" вообще) - надо обращаться к знакомому, у которого другой провайдер - а это на следующей , теперь, неделе.

:100000008A15C0278A118028A000030E8316A1003C
:1000100022108A19221483126F308E00FB308F0059
:100020000C108A116E1B4F28061F182806134F2824
:1000300006178316F30B1E281230F30013307302D9

[Openreel]

https://disk.yandex.ru/d/3ED6fdqbHxj2JQ

[Wladimir_TS]

Спасибо ! Оно конечно на импортном языке, что непросто, но думаю что-то сыщу полезное.

Все-ж по первой ссылке русская обещается.

Попробовал пока некий "PICDisasm" - как-то по перспективнее, всего 1 какой-то регистр ВВ некорректен.

Теперь фаза 2 - ассемблирование. Использую MPLAB X-IDE V3.3 (так покладено)

Вроде поправил имена регистров, но тут почему-то не подключается INC файл

Вписал #include <P16C65A.INC>

В каталоге имеется. Но на каждое именное поименование регистра выдает ошибку : 152 : Executable code and data must be defined in an appropriate section

Если вписать в начале программы PROG CODE, а в конце END, а <> с имени INC файла убрать - то имеем в части начальной проверки.

Error - section *PROG* can not fit the section. Section *PROG* length=0x0.......

Я победилЪ этот ассемблер...!!!

Run -> Set Project Configuration -> mpasm (Globak Option) -> поставить "галку" Bild in absolute mode

Видимо неправильно рассчитывал память считая что ячейка = 1 байт, а не 2 байта (14 бит)...

Только сейчас заметил что программа занимает 4094 слова, свободно 2 ячейки памяти - не поправить не добавить

[Alex]

Писано точно на ассемблере ибо это где-то 2001 год.

Не факт, первые Си-компиляторы для ПИКов, которыми уже можно было пользоваться (от Hi-Tech) появились чуть раьнше. где-то в 98-99. Во всяком случае, в 2000-м мы уже полностью перестали писать для пиков на асме.

[Serge_L]

Хай-Тек годный компилятор, весьма.
И там не 13 бит разве? Длина слова
Или меня глючит уже?))) И это ширина каунтера?
Понятно, что рояли это не играет)))

---------- Сообщение добавлено 18:28 ---------- Предыдущее сообщение было 18:26 ----------

Поглядел: да, глючит!)))
Ну, оставим в назидание!))

[Alex]

И там не 13 бит разве? Длина слова

14.

P.S. Это у С65 уже 14, у предыдущих серий было 12, и команд чуть меньше, все-же базовая модель - 1975г.

[JazMan]

Свежие IDA имеют переводить ассемблер в псевдо-С.
По мере присвоения осмысленных имен функциям и переменным, становится вполне понятным.

Но IDA все же плохо поддерживает всякие AVR/PIC (определения портов, битов и т.п.).
Можно еще попробовать Ghidra.

[Wladimir_TS]

Не факт, первые Си-компиляторы для ПИКов, которыми уже можно было пользоваться (от Hi-Tech) появились чуть раьнше. где-то в 98-99. Во всяком случае, в 2000-м мы уже полностью перестали писать для пиков на асме.

Там точно ассемблер - очень на то похоже. Просто из-за долбанутой системы адресации понаставило лишних меток и теперь понимай какое состояние у регистра старших бит адреса состояние. Дизассеблер программ на некоторых языках высокого уровня (фиг знает на каких, но было под AVR - тоже причесывал, особо не вникая) все-ж как-то по другому выглядит, не столь убористо и много явно лишних ячеек памяти -переменных.

14 бит 0-13 дес., как я понял. Но для переходов и вызова подпрограмм используется только 11 бит адреса (нииивлезло), а старший бит изволь в отдельный регистр загнать. (всего 4096 слов). А вы говорите советские поделия были кривы.....

Но IDA все же плохо поддерживает всякие AVR/PIC (определения портов, битов и т.п.).
Можно еще попробовать Ghidra.

Что-то с первого подхода корректно оно не отработало. Сейчас живой asm файл готов, но надо корректно расставить метки, а так как для каждого перехода или вызова есть 2 адреса - надо как-то понять, какой именно используется. Так и для наборов регистров ВВ есть 2 адреса и пишем мы в порт или в регистр направления порта понятно только из контекста. Бред, если честно...

[Openreel]

Wladimir_TS, Процесс дизассемблирования обычно идет за много проходов и интерактивно, если нужен результат. Даже 30 лет назад уже было так. А если хотим мозги не включать и чтоб оно само - ну, мечтаем дальше.

[Wladimir_TS]

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

Естественно тут надо немало подумать и проверять в каком состоянии биты в регистре PCLATH.... (точнее бит 3 при счете с 0) потому как создатель программы не перед каждым вызовом переключал регистр - а всего несколько раз за программу, потому как памяти программ не хватало - в программе всего 2 слова свободных остаются. И переделать корректно не выйдет - не добавить ничего в программу - сразу в память не влезает.

Ладно тут вылезла новая проблема - Mplab X IDE 3.3 не приемлет русского языка в комментариях. А программу-то надо комментировать. Есть-ли какие-то ассемблеры-симуляторы под Microchip PIC которые нормально относятся к русскоязычным комментариям в тексте программы ?

[Serge_L]

Не видел
Все микрочиповские всю жизнь становились "в позу" от русского языка и русских путей

[Wladimir_TS]

Если что, рекомендованное где-то Tools->Options->Embedded->Default Charset и сменить на Windows-1251 не помогло....

Что самое смешное ввод на русском языке в редакторе возможен... но не сохраняется.

Я его победилЪ !!! Надо 1251 еще выставлять и в свойствах проекта и он начинает сохранять русский текст корректно. Но всё-ж среда с излишним количеством накруток и выворотов...и постоянно ломится в инет, так еще и порты меняет в попытках "позвонить дяде Сэму...."

ЗЫЖ Как понимаю регистр FSR указывает на ячейку памяти данных адрес которой занесен в IDNF ?

А вообще странные элементы есть в программе - например подпрограмма, которая всего-лишь сбрасывает бит в ячейке памяти данных, один и тот-же в фиксированной ячейке....


ЗЫЖ2 Более-менее разобрался - но дело идет небыстро 528 меток осталось... (из них 50% ложные) обработано порядка 30.... Нужно по хорошему какое-то ПО для оптимизации процесса иначе так пол года мучатся. А еще надо комментарии расставить. Но тут проще - там где порты ВВ или внутренняя переферия с известными именами - то и описываем эти строки. Логики в работе этой программы не прослеживается совсем.

[Wladimir_TS]

Как-то все чудесастее и чудесастие....

Вот в тестовой программе :

    processor 16C65A
    #include  p16c65a.inc

RES_VECT  CODE    0x0000
    GOTO    START

START

    DECFSZ 0x73,	F
    GOTO   M19
M18
    MOVLW  0x12	
    MOVWF  0x73
M19
    MOVLW  0x13
    SUBWF  0x73,	W
    BTFSC  STATUS,	C
    GOTO   M18
    GOTO   START
    END

Декриментируется ячейка памяти 0х73h и доходя до 0 снова в неё заносится 12h Соответственно максимум в этой ячейке 12h и вычитая из него 13h всегда будет заём и С="1" и вроде-бы вторая проверка бессмысленна, однако в симуляторе MPLAB X IDE 3.3 ежели поставить точку останова на "GOTO M18" то раз в несколько десятков секунд там остановка и ячейка 0x73h = FFh - як так получается ??? Не понимаю - или у меня MPLAB кривой или что-то одно из двух ????

[Openreel]

Не понимаю - или у меня MPLAB кривой или что-то одно из двух ?

смотрим в юзер мануал

Use IDE Scripting
MPLAB X IDE provides scripting capabilities to control the IDE behavior programmatically. Allow developed for use
with Microchip MPU projects, scripts may be used with MCU projects as well.
About the Scripts
The scripts are written in Jython. The scripts have access to an API that allows you to:
•Control the debugging session state (run, halt, etc.).
•Access memory in the device while debugging.
•Set breakpoints with callbacks to functions that determine if a halt should happen or not. This allows
implementation of conditional breakpoints.
•Place actions in the Projects window which, when clicked, will run methods in a script.
•Provide hooks for debug events: a function will be called when a given event happens.

Пишешь трассировочный скрипт на пайтоне и анализируешь результат логов.

[Serge_L]

Openreel, Миш, я такое тоже не осилю(

[Wladimir_TS]

Пишешь трассировочный скрипт на пайтоне и анализируешь результат логов.

Ээээ ????

Понял только предлги союзы и знаки препинания, остальное не понял. Просто программа-то на вид простая 9 команд - а такой глюк, почему ?

ЗЫ Побеждено примерно 100 адресов Примерно 10 подпрограмм еще выделил. Но обработано 8% теста программы.

[Openreel]

Просто программа-то на вид простая 9 команд - а такой глюк, почему ?

Понятия не имею, не пишу под пики.

Учебные программы можно прошагать в отладчике. С ростом сложности шагать становится долго. В реальных проектах зачастую и вовсе нет шансов.
Поэтому используют другие методы - трассировка. С остановом в плохом месте и просмотром "киноленты" в обратном порядке, чтоб понять, почему оно сломалось.
И называется это обратная трассировка или back trace. Взрослые системы которые это умеют - сложно и очень дорого, подробности в профильной литературе.
Для простых задач можно обойтись средствами обычного отладчика, просто прикрутив к нему автоматизацию. я просто поискал в мануале на мплаб по ключевым словам trace script.

Не знаю, что тут такого сложного, свой первый трассировщик я писал еще студентом, самостоятельно, с нуля, больше 30ти лет назад. Естественно, "это мы не проходили, это нам не задавали".

[Wladimir_TS]

Понятия не имею, не пишу под пики.

Я тоже, но приходится разбираться Иначе подпрограммы не вычленишь.

Учебные программы можно прошагать в отладчике.

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

и просмотром "киноленты" в обратном порядке,

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

Не знаю, что тут такого сложного, свой первый трассировщик я писал еще студентом

Видимо в мозгах... я не программист, хотя периодически пытаюсь писать на ассемблере под Atmel AVR маленькие программки.

ЗЫ - а что у PIC16yxxx происходит при переполнении стека, он-же у него аппаратный 8ми уровневый ? А то столкнулся с рекуррентным вызовом подпрограммы из самой себя.

ЗЫ2 - еще интересный момент - из одной части программы в другую передается переменная...но передается она в регистре счетчика-таймера 2 (основном - TMR2)... но самое веселое в том, что таймер в это время - СЧИТАЕТ на Fclk/4 и до программы целевой доходит данные в несколько "инкрементированном" виде, а вот коли промеж ними что-то как-то по другому работает - то данные исказятся и все пойдет "по плинтусу"...

ЗЫ3 - еще 88 меток, осталось 410 неприкаянных