Desassembler, Дизассемблирование hex под AVR Опции

[Sugar]

Господа, не подумайте что хочу заняться пиратсовом, оровать чужие идеи и т.д.
Ради спортивного интереса?
Попробовал IDA и AVRStudio.
Впечатления хорошие, пробовал так, прошил кристалл, (программа loader), считал hex, дизассемблировал IDA, получил asm.
Вопрос такой, а можно этот asm переконвертировать в c.
ведь распространены всего пару компиляторов:IAR, WinAVR, CodeVision, ImageCraft.
Они же из с делают asm, могут ли они делать обратную операцию, из asm - С.

[M_A]

К цели (бинарный машинный код, заливаемый во флэш) ведет теоретитески неограниченное число путей - программ на ОДНОМ из языков, в данном случае ассэмблер. По этому ОДНОЗНАЧНОГО дизассемблирования ИСХОДНОГО текста программы принципиально не может быть. От языков более высокого уровня к ассэмблеру - аналогично. По этому возможно только нечто усредненно-приближенное, дающее ТАКОЙ ЖЕ машинный код.

То есть если это усредненно приближенное снова экспортировать в НЕХ и залить в железо, будет работать как первоначальный вариант?

[Andrey_Sudnov]

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

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

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

Другое дело, что самом деле существует не так уж много алгоритмических конструкций, и машину можно научить распозновать их. Очень легко машине отслеживать поток данных, т.е. указав начальный и конечный адрес получить на выходе алгоритма все входные данные, все выходные и все побочные эфекты (изменяющиеся в процессе) этого участка кода. Существуют даже перекомпиляторы из одного машинного кода в другой, например http://fabrice.bellard.free.fr/qemu/

Мне самому очень интересен этот вопрос. Нашел очень много информации в различных источниках. Что интересно в СССР в 70-80 годах на академическом уровне активно развивалась теория схем программ. В библиотеке очень много книг об этом.

Современное развитие эта тема имеет в построении интерпретаторов, таких как Java, Perl и т.д. В западных источниках очень много публикаций по этому вопросу.

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

Я вам советую потренироваться диззасемблировать вручную (в смысле с помощью IDA, но без тех средств, которые вы ищите). Во первых это полезно (поможет вам в дальнейшем при вылавливании тяжелых глюков у ваших программ). Во вторых врядли необходимо полная декомпиляция всего файла. Обычно необходимо найди участок кода, в котором выполняется интересуемое действие, например проверка защиты, или реализован какой-то протокол, хотя в этом случае изучаемый участок будет больше. Очень скоро вы обнаружите, что при хорошей автоматизации и организации, вы очень просто читаете машинные листинги и способны держать в голове назначение и текущее значение нескольких регистров и т.д. Короче это всего лишь дело опыта. А без труда, как известно, не выташишь и рыбку и пруда. И всякие там средства будут вам не нужны.