Собсна, есть ATmega328P и дамп флеш-памяти. Юзаю binutils от avr-gcc, т.к. это первое, что я нашёл в репах, и по названию вроде как подходит. Сейчас зачаток процесса выглядит примерно так.
Получаем ассемблер:
$ avr-objdump -D -b binary -m avr flash.bin --no-show-raw-insn > flash.s
Подчищаем вывод обждампа в начале, дописываем к меткам адресов какую-нибудь буковку sed-ом, чтобы as кушал.
Собираем обратно:
$ avr-as -mmcu=atmega328p flash.s -o flash.o
$ avr-ld flash.o -o flash.bin
avr-ld: flash.bin section `.text' will not fit in region `text'
$ avr-ld --oformat binary flash.o -o flash.bin
avr-ld: error: cannot change output format whilst linking AVR binaries
Вот тут загвоздка. as заменяет адреса в прыжках на нули. Видимо, куда-то в другое место в ELF записывает. Следовательно, просто objcopy не катит, нужно прогнать через линковщик, чтобы тот поставил адреса обратно. Но линковщик почему-то отказывается работать - как я понял, секция в процессе пересборки якобы толстеет и в итоге может не поместиться на чип. За счёт чего толстеет - пока непонятно.
Вообще говоря, я действую почти наугад и, возможно, иду не тем путём и использую не те инструменты, так что если кто-то подскажет, чем, кроме avr-gcc+vim можно нормально пореверсить на досуге прошивку от дуины, будет очень здорово.
UPD: большую часть файла с ассемблером составляет забитие дампа 0xff-ами. Если их убрать и оставить только осмысленный текст, получившийся объектник станет гораздо меньше и по случайности уместится в 32 кБ, чем и отличается от варианта с оставленным забитием. При этом он успешно проходит через ld, а извлечённая из него секция .text побайтово совпадает с концом оригинального дампа. Всплывает вопрос: ld думает, что я буду сам эльф писать на чип?
