Перевод дизассемблера обратно в исходник Опции

[gem]

Приветствую Уважаемые!
Есть дизассемблированный код процессора pic18ф4620/2620, пытаюсь собрать исходник обратно с помощью МПЛАБ IDE МPASMWIN, чтобы потихоньку разбираться что к чему и как работает.
Естественно вылазит куча ошибок.
Самая распространенная это Error[126] 32273 : Argument out of range (8423 not between FC00 and 03FF). В коде данных строк стоит переход BRA 720.
Про команду эту почитал, и вроде метка есть L720. Но ругается я так понимаю на диапазон. Как узнать почему ?
Та же ошибка, только тут уже не нравиться RCALL
L1903 RCALL 987
NOP
BRA L1850
BRA L1851
NOP
NOP
BNC L1852.

и еще

Error[126] 27724 : Argument out of range (9FF8 not between 0000 and FFFF) // CALL 0x0F9FF8,FAST
Error[126] 27769 : Argument out of range (D29A not between 0000 and FFFF) // GOTO 0x1ED29A


Понятно что, тут возможно код так дизассемблировался и в идеале он уже не тот, но все же 80% кода собирается и выглядит один в один с исходником хекса, если все убрать где начинаются это ошибки. Помогите исправить, чтобы программа компилировалась.

https://mega.nz/#!FMZlGLzZ!EtARv8iv...7F1VN1M4MkJKPFA

Сам код.

[Baser]

Встроенные в IDE дизассемблеры, как правило, не обладают хорошим интеллектом, поэтому спотыкаются об секции с данными, таблицами и тому подобным. И начинают дизассемблировать данные как код. Ессно получается лабуда.
Тут нужно или глазами эти куски смотреть, или применять сторонние интерактивные дизассемблеры.

[gem]

Тут использовался не встроенный в МПЛАБ дизассемблер, с ним многие говорят что код получается нормальный, ничего подобного. Для дизассемблера использовался не он, как раз сторонний.

[k155la3]

IDA. Посмотрите, возможно есть PIC.
Более удобного софта не встречалось.

[kovigor]

Тут нужно или глазами эти куски смотреть, или применять сторонние интерактивные дизассемблеры.

А лучше (в 99% случаев, как мне представляется), проще, надежнее и дешевле - нанять специалиста, который напишет программу для этого ПИКа заново, с нуля. Идея с дизассемблированием и последующей перекомпиляцией крайне неудачна, ИМХО. Если, конечно, речь не идет о простейшем проекте вроде светодиодной мигалки ...

[jcxz]

Если, конечно, речь не идет о простейшем проекте вроде светодиодной мигалки ...

А в этом случае тем более проще с нуля написать. Чем ковыряться в много-десятко-килобайтной инициализации чего-нить посредством PICо-HALа, в которой потеряется само мигание на пару десятков команд.

[k155la3]

Посмотрел листинг. Всего - около 500 страниц текста. Если убрать NOP - примерно 250.
Если есть возможность выделить код и данные, а также обработчики прерывания, возможно удастся сократить еще в несколько раз.
Ошибки могут лезть по причине "отработки" дизассемблера по участку данных, строк-литералов. Естественно, получается бредо-код.
Поэтому сперва просмотрите хотябы bin-образ прошивки в символьном виде напредмет нахождения литералов. В ASM этот блок пометьте как массив данных.
---------
Возиться с этим имеет смысл, если проект изначально писан на ASM и прикладная задача нетривиальная.
Если это код С(++) то лучше переписать.
ТС, какая прикладная задача прошивки ?

[Smen]

Более удобного софта не встречалось.

Да без разницы.
Любой дизассемблер не умеет отличать области кода от данных, таблиц и т.п.

[gem]

В этом все и дело, сам код без проблем компилируется, а вот блок данных нет, именно в нем ошибки и идут. Как их вернуть в исходное или рабочее состояние. Код написан на АСМе, с данными там вообще не понятка, т.к если смотреть по IDA то видно слова типа "Подключение к БД", Меню и т д... Соответственно без данных программа включается, но не работает как надо и соотвественно 20% кода который компилируется в hex получается лажой.

Сообщение отредактировал gem - Jun 14 2018, 14:26

[k155la3]

литералы смотрите в FAR. По адресу или смещению находите эти блоки в IDA (или в вашем исходнике ASM) и помечаете их как данные.
Если литералы не видны - возможно юникод.
Если строки сишные - терминатор 0x00.
Компилируете свой ASM.
Из hex-модуля преобразуете в bin-образ памяти флеш.
Сверяете длину "нового" bin-образа с "старым"/исходным-образцом.
Если длина одинаковая - делаете побайтное сравнение fc f_new.bin f_old.bin /b >bin_log.txt
Если совпало - "правка" нового асм-файла корректна. Идем далее.
Если не совпало - смотрим в каком месте и что не совпадает.
и т д,, получаем удовольствие от процесса

[Smen]

Как их вернуть в исходное или рабочее состояние.

Помнится проделывал подобное для 51 МК.
В принципе, выше вкратце уже сказали.
Единственно что, данные не обязательно являются текстом, а если являются, то вряд ли в МК будет юникод.
А собственно для чего Вам это надо?
У меня тогда стояла задача дополнить старт устройства дополнительной фичей.
Поэтому, немного разобравшись с программой (по дизасму), сделал в самом начале переход на конец программы (где было свободное место) и там уже написАл необходимую вставку с возвратом в точку перехода.
Дальше уже более для интереса, нашёл куски текста, указал дизасму адреса, дизассэмблировал.
Опять засунул в ИДЕ (точнее не весь, а только обновлённые куски, так как по ходу в листинге менял названия меток и добавлял коментарии), стал анализировать программу и находить блоки данных.
По-новой в дизасм и т.д.
Периодически, после изменений АСМа, компилировал в BIN и сверял с исходным (пользовался вот программкой Dronf).
И, да! Удовольствие получил обалденное.

[gem]

Чтобы что-то дополнить нужно исходник иметь, для этого и делается, плюс для себя поразбираться в коде. Просто хочется сделать готовый исход, который можно будет править и добавлять в него. В Hex новое не запихнешь Данные то понятно они там есть точно, в сам процесс вникнуть не могу пока. Как данные пометить ? Нашел, да данные и текст даже есть, но не везде. Теперь как мне перенести все это правильно в компилируемый проект?
Под литералами что понимается? Сами данные. Вопросов больше чем ответов У меня вообще такое чувство что там типа базы данных. Либо вывод какой-то на дисплей, терминал. Чего изначально нет.
Может тут есть люди которые шарят в этом и могут подсказать как и что. Код на ассемблере был написал.

Сообщение отредактировал gem - Jun 15 2018, 16:15

[k155la3]

(1)Как данные пометить ? Нашел, да данные и текст даже есть, но не везде. Теперь как мне перенести все это правильно в компилируемый проект?
(2)Под литералами что понимается?
(3)Может тут есть люди которые шарят в этом и могут подсказать как и что. Код на ассемблере был написал.

(1) изучаете ASM для Вашего процессора + сам проц., распределение памяти, портов, адреса векторов прерывания итд.
для абстрактного процессора - примерно так

Код

             org   8000h;  начало сегмента данных, "вычисляется" из дампа, стартовый адрес строки или данных
L_START_MSG:   DS   'LOAD'; сюда переписываем текст из дампа прошивки.
             DB    00h

(2) литерал - набор символов, как правило "читабельных" для вывода на экран, передачи на терминал итп.
Расположены в памяти последовательно, кодировки символов могут быть разные. "закрывающего" последнего символа может не быть (а может быть).
Литерал, за последним символом которого расположен код 00 - это "сишная" строка. (для 1-байтовых символов ASCII)
(3) Если для Вас приемлем (1) и будете отвечать на вопросы, а не "кодироваться".

[Марк_Я]

В системе команд PIC18 (как и других PIC-ов) под литералом понимается константа в поле команды.
То есть в команде movlw 0x5C константа 0x5C является литералом. Отсюда и аббревиатура самой команды move literal to working register.

По поводу дизассемблирования.
Автоматические дизасмы - полная фигня. Для восстановления исходника на АСМе из бинарника требуется только текстовая декомпиляция и ПОНИМАНИЕ ФУНКЦИОНАЛА исследуемого прибора. Ну и знание архитектуры МК, естественно.

Как то у меня оказался утерянным последний исходник под dsPIC33, но остался экземпляр живого устройства с открытой прошивкой и исходник предыдущей прошивки. Строк кода - около 3000. Изменения касались лишь примерно 5 % исходника (по сравнению с предыдущим). Я пахал как папа Карло примерно 2 недели. Восстановил, но имена пары флагов так и остались бессмысленными. Примерно понимаю функционал, но сил и времени на эти флаги уже не осталось. Плюнул и оставил их как есть - безымянными.
Это я к тому, что даже свой собственный код с полным пониманием что куда и откуда декомпилировать крайне сложно и долго.
Порой гораздо проще и полезнее написать заново.

[k155la3]

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

Перечитал определение из "кладезя мудрости". Если в "двух словах" - различные константы в исходном коде.
(ониже, - в машинных кодах команд). Бинарные константы "смотреть" в дампе достаточно проблематично,
а вот символьные и строковые - вполне комфортно. Поэтому я начинаю "разбор" с них.
Затем - удобно выделять константы во флеш формата float'32 (например массивы, таблицы достаточно легко идентифицировать).
Лично мне (почему-то) литералами бинарные значения float как-то называть некомфортно. Но это - уже психоанализ

[Марк_Я]

Поэтому я начинаю "разбор" с них.

Разбор обычно начинают с КОМАНД, а не с полей констант. Тем более, что таблицы констант в ассемблере PIC18 могут быть оформлены и как табличное чтение и как функция команды retlw <const>. Если последний вариант дизассемблируется достаточно очевидно (там нечего искать, достаточно начального адреса стандартного блока с retlw), то вариант с табличным чтением программного флеша совершенно неопределенное занятие без разбора адресующего эту таблицу кода. Ибо при побайтной упаковке таблицы во флеш эта таблица ничем от исполняемого кода внешне не отличается.

[k155la3]

Под "разбором" с литералами-константами подразумевал следующее.
После получения "сырого" листинга disasm первоочередная задача - сократить его длину, убирая "бредо-код", соответствующий различным данным.
Самое простое - это просмотреть дамп бинарника в символьном виде и диапазоны адресов, которые явно не являются кодом, например строки для LCD,
определить в исходнике асм как DB. Если использовать IDA - значительную часть этой работы выполняется (полу)автоматически.
Процесс творческий и итерационный. У каждого процессора - свои ньюансы.

[Марк_Я]

например строки для LCD,
определить в исходнике асм как DB.

Извините, но Вы - жертва стереотипов.
С чего Вы взяли, что строки для LCD будут обязательно определены как DB?
Элементарно и целесообразно их определять как DW.
Но дело даже не в этом. Я не понимаю чем поможет восстановлению исходника отделение полей констант. Ну отделили, и что?
И LCD может быть графическим, и упаковка графики не иметь формата экрана, а состоять из примитивов...
Опять же главное в восстановлении исходника - восстановление глобального алгоритма, а так же выделение основных функций этого алгоритма.
Поэтому начинать надо с выделения main, то есть участка общей инициализации и главного цикла (суперлупа). И из функций вызываемых этим циклом развернуть остальной код.
А где будут константы, - укажут команды табличного чтения. Это элементарно и определяется В САМОМ КОНЦЕ реверсинжиниринга.

[k155la3]

Извините, но Вы - жертва стереотипов.

Не исключаю. Позволю себя процитировать

Процесс творческий и итерационный. У каждого процессора - свои ньюансы.

Поскольку Вы хорошо знаете платформу (PIC), а я - нет (последние 5 лет "сижу" на MSP430) - Вы правы.
Да и ТС выкладывать прошивку не пожелал . . .