Реверс хекскода Atmel

[vitvp]

Просто любопытно, что это всё дало нашему топикстартеру, который после своего второго поста на первой странице сюда больше не заглядывал?

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

2 ut1wpr, #69
Не стоит так категорично о RE. Для начинающих он, качественных разработок, - неплохая школа. Для профи - средство для выведения шарлатанов на чистую воду,
типа этого: https://kazus.ru/forums/showthread.php?p=491477

[_Артём_]

Допустим в подрограмме идет сложная и запутанная отработка некоего массива памяти. Я думаю что имея логгер памяти и войдя в подпрограмму, поставив курсор на конец, запустив исполнение до курсора, потом открыв отчет логгера можно будет не спеша исследовать к какой области памяти было обращение и лучше понять алгоритм. Встречал ли кто то что нибудь подобное?
Вывод логгера что то типа:
1. Строка (номер), откуда было обращение.
2. Тип (R/W).
3. Байт (желательно)

В чём сложность написать такой?
Вызвать на стадиях 1 и 3 функцию SendMemory то порт.
На Com-порту повесить принимающую программу, которая сохранит в файл. Полдня работы (или меньше).

[vitvp]

Искал ранее, не нашел, но не оставляю попыток найти логгер памяти для отладчика AVR. Обьясню что я имею в виду.
Допустим в подрограмме идет сложная и запутанная отработка некоего массива памяти. Я думаю что имея логгер памяти и войдя в подпрограмму, поставив курсор на конец, запустив исполнение до курсора, потом открыв отчет логгера можно будет не спеша исследовать к какой области памяти было обращение и лучше понять алгоритм. Встречал ли кто то что нибудь подобное?
Вывод логгера что то типа:
1. Строка (номер), откуда было обращение.
2. Тип (R/W).
3. Байт (желательно)

Для отладчика это скорее не логгер, а profiler. Для AVR не сталкивался. Во взрослых IDE, Visual Studio for examle, присутствует штатно и используется для анализа и оптимизации производительности - тайминг и частота вызова ф-ий и т.п.

По-слухам Code::Blocks (есть он и для AVR) имеет Сode Profiler в виде не бесплатного плагина. Как там с этим и его функциональностью - без понятия.

[vitvp]

Для отладчика это скорее не логгер, а profiler. Для AVR не сталкивался. Во взрослых IDE, Visual Studio for examle, присутствует штатно и используется для анализа и оптимизации производительности - тайминг и частота вызова ф-ий и т.п.

По-слухам Code::Blocks (есть он и для AVR) имеет Сode Profiler в виде не бесплатного плагина. Как там с этим и его функциональностью - без понятия.

Там скорее всего надстройка над GCC/GDB, штатно и так имеющаяся:

http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html
".\Program Files\Atmel\WinAVR\doc\binutils\gprof.html"
".\Program Files\Atmel\WinAVR\bin\avr-gprof.exe"

[anakost]

В чём сложность написать такой?
Вызвать на стадиях 1 и 3 функцию SendMemory то порт.
На Com-порту повесить принимающую программу, которая сохранит в файл. Полдня работы (или меньше).

Не понял вашу мысль. Как заставить уже скомпилированный *.hex генерировать подобные вызовы?

Пока склоняюсь к использованию отладчика VMLab.
Как известно, в модели памяти AVR регистры и SRAM находятся в одной непрерывной области памяти. Адреса 0х00...0х59 занимают регистры, а 0х60...RAMEND занимает SRAM.
В VMLab есть функции обратного вызова On_register_read(ID) и On_register_write(ID). Они позволяют легко отследить обращения к регистрам по адресам 0х00...0х59. Функций On_SRAM_read(Adr) и On_SRAM_write(Adr) к сожалению нет.
Для поддержки новых кристаллов, адреса новых регистров у которых залезли в область SRAM, можно в INI файле указать их адреса.
И для того, чтобы отследить обращения к SRAM необходимо будет определить в INI файле столько фиктивных регистров, сколько имеется ячеек SRAM. Т. е. 512 для Atmega8535, 1024 для Atmega8, 2048 для ATmega16 и т. д.
И по каждому вызову On_register перебирать в цикле все вновь определенные регистры, ища нужный. Не нравится мне такой подход, но ничего лучше я пока не придумал.
Другой подход рекомендуют сами разработчики VMLab. Они советуют обратиться на официальный форум VMLab, и если требуемая функциональность реализуема, для вас могут собрать специализированную версию VMLab. Я думал о том чтобы обратиться на этот форум с просьбой включить в сборку Callback вызовы On_SRAM_read(Adr) и On_SRAM_write(Adr), но меня останавливает незнание разговорного английского.
Во всех учебных зведениях изучал немецкий, а технический английский выучил сам, работа заставила. И боюсь переводчик GOOGLE может настолько исказить мою мысль, что меня просто не поймут.

[_Артём_]

Не понял вашу мысль. Как заставить уже скомпилированный *.hex генерировать подобные вызовы?

Вставить в нужное место hex-файла вызов своей функции.

Пока склоняюсь к использованию отладчика VMLab.

По мне jtag+рабочая схема лучше.
VMLab не использовал, ничего сказать не могу (но думаю что все эти симуляторы - это несколько не то).

[anakost]

Вставить в нужное место hex-файла вызов своей функции.

Сомневаюсь что это вообще работоспособно. При вставке даже единственного байта в середину скомпилированного *.hex файла у вас уедет вся адресация по уже распределенным компилятором адресам.

По мне jtag+рабочая схема лучше.
VMLab не использовал, ничего сказать не могу (но думаю что все эти симуляторы - это несколько не то).

Не могу с этим не согласиться. Живая отладка через JTAG всегда лучше симуляции. Но во первых JTAG есть не у всех камней. А во вторых, логгер памяти предназначен не для симуляции, а для вдумчивого и неспешного анализа кода.

[AJScorp]

При вставке даже единственного байта в середину скомпилированного *.hex файла у вас уедет вся адресация по уже распределенным компилятором адресам.

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

[anakost]

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

Это напоминает монитор-отладчик во времена 51 камней. Если помните на время отладки средствами условной компиляции в программу добавлялся монитор, и вся отладка шла через него. После отладки монитор изымался. Возможно подобный прием применим и до сих пор, но для реверсинга это как то круто. Впрочем это только мое мнение.

[AJScorp]

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

Это из моего прошлого опыта по "лечению" программ, способ применялся в том случае, когда было лень докапываться до сути, либо не было времени. И да, для реверсинга это совсем не круто.