Хоспаде.. наплели семь бочек арестантов.
Magadan69 уверен у вас сейчас каша в голове. Давайте начнем с терминологии:
То что вы хотите - реверс-инжиниринг. Очень не простоая задача
Байт-код - слово применяемо к промежуточному представлению программы. к примеру Java программы находятся именно в этом состоянии (
https://ru.wikipedia.org/wiki/Байт-код). Давайте о нем
забудем. То что вы подразумевали будем называть Прошивкой/Фирмварью/хексом/бинарем (4)
1) Исходный код - надеюсь тут вопросов нету, С/С++, asm, или что-угодно
2) Объектные файлы - то что получили в результате компиляции(!) пример: *.o
3) Исполняемые файлы - то, что получили в результате линковки(!) пример: *.exe, *.dll, *.elf, *.so
4) Прошивка - бинарное представление программы, что можно залито непосредственно в камень (микроконтроллер) и прочитано из него. примеры: *.bin, *.hex
Собственно, у вас нету пунктов [1;3]. Есть только 4.
Если при сборке был флаг -g, то пунк 3 будет содержать в себе всю дебаг информацию (пути к файлам, символы и тд). его можно "полноценно" дебажить
То, что вы хотите сделать software developer'ы называют Debug. для этого есть Debug'еры (gdb например). Это очередная грамма которая контролирует исполнение вашей программы ( debug(myprogramm()) )
Как происходит процесс дебага на вашем десктопе? К примеру накидали вы hello world. скомпили. слинковали. запустили под дебагером. Дебагер получает от вас команды "шаг. стоп. run. и тд" он же может и модифицировать код/перменные!
Ситуация с микрокнтроллером чуть сложнее. Потмоу что мы делаем cross-компиляцию. То есть на x86 машине м собираем код для ARMv7-M. Соответсвенно в случае отладки у нас так же - cross-debug. Здесь трабла - отладчик то не запустить на x86, он же ARM... Но тут нас спасает gdb! Он ведь умеет в remote.
То есть у нас есть две сущности:
1) gdbserver - собственно ваш отладчик (j-link, st-link, etc.) и ваш камень с прошивкой
2) gdb client - то, что подключится к серверу и будет посылать команды
Тут есть варианты выбора, CMD, Keil, IAR и всё такое. Лично я эти виндовые проприретарные вещи ненавижу. Так что опишу вообще Unix'овый подход
Итак, что надо:
1) openocd - прекрасный gdbserver - который работает с любым отладчиком (j-link, st-link, etc.)
http://gnutoolchains.com/arm-eabi/openocd/2) arm-none-eabi-gdb - gdb client
https://developer.arm.com/open-source/g ... /downloadsКак:
1) вам надо запустить gdbserver. Открываем консоль и скорее всего будет так
openocd -f interface/jlink.cfg -f target/stm32f1x.cfg - собственно в таргете - и есть ваш камень (семейство)
2) клиент. Опять же - консоль и
arm-none-eabi-gdb
здесь же
target remote :3333
и всё - можно апсчаться
Но есть одна загвоздочка.... Микроконтроллер вещь противная с флеш-памятью. и прошивка живет во флеше. Как все мы знаем, во флешку можно писать побайтно, стирать - только страницей. Значит если вы хотите поменять хотя бы 1 бит с 0->1 то придется теперь всю страницу.
Поэтмоу я б рекомендовал вам не заморачивать с пошаговой отладкой, а, как писали выше. Выкачать прошивку. Взять IDA и уже там модифицировать прошивку (ида это умеет) и дальше - заливать и смотреть что происходит. Благо у арма есть bkpt инструкция
Надеюсь вы сможете оценить сложность данной процедуры и напишете код с 0, а не будете пытаться реверсить не понимая что там внутри....