Disasm 8051, MCS-51 Опции

[noobie]

Ребята, натолкните на истинный путь....
Есть сабж который обрабатывает приходящую на него инфу и выплевывает чтото понятное программе,
с которой он работает.

Допустип улетело на него 17 байт там чота внутри поделалось и вылетело 17. Все это красиво видно в различных
сниферах.

Содержимое этого процессора у меня есть, однако когда в IDA видишь программу почти 100 кб теряешься. Может ктонибудь
подскажет как проще найти тот самый алгоритм где именно обрабатываются наши заветные байтики

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

Спасибо.

[Палыч]

Содержимое этого процессора у меня есть, однако когда в IDA видишь программу почти 100 кб теряешься.

Сто килобайт - это размер программы МК? Что же за МК применён в устройстве? Или программа хранилась во внешнем ПЗУ? При таком размере кода найти обработчик информации, действительно, очень трудно.

В качестве дебаггера пробовал искользовать Keil однако дизассемблированный прошивон надо дорабатывать, чтобы он закрутился в дебаггере, а опыта ни очень

Можно использовать другие симуляторы, которые не интегрированны в единую среду с транслятором и линковщиком, и принимают на входе hex-файл (или бинарник) для симуляции. Когда-то давно сам таким пользовался, но за ненадобностью - симулятор не сохранился... Погуглите.

В такой большой программе алгоритм поиска искомого Вами участка, наверное, один: 1) определить тот кусок программы, который ответственнен за вывод байтов (например, по вектору прерывания ввода/вывода и просмотра соседних участков программы); 2) определение кусков программы, которые обращаются к нему (это делает IDA); 3) выбор из них нужного Вам; 4) разбор этого участка программы. Всё это можно проделать и без симулятора. Но, нужно упорство, усидчивость, внимательность и время...

[noobie]

Сто килобайт - это размер программы МК? Что же за МК применён в устройстве? Или программа хранилась во внешнем ПЗУ? При таком размере кода найти обработчик информации, действительно, очень трудно.
Можно использовать другие симуляторы, которые не интегрированны в единую среду с транслятором и линковщиком, и принимают на входе hex-файл (или бинарник) для симуляции. Когда-то давно сам таким пользовался, но за ненадобностью - симулятор не сохранился... Погуглите.

В такой большой программе алгоритм поиска искомого Вами участка, наверное, один: 1) определить тот кусок программы, который ответственнен за вывод байтов (например, по вектору прерывания ввода/вывода и просмотра соседних участков программы); 2) определение кусков программы, которые обращаются к нему (это делает IDA); 3) выбор из них нужного Вам; 4) разбор этого участка программы. Всё это можно проделать и без симулятора. Но, нужно упорство, усидчивость, внимательность и время...

в бине размер проги 64кб, в хексе вдвое больше... ну а сорс вообще 600 кб
Но мы трудностей не боимся. Я поробовал следовать вашей логике Палыч, но к сожалению
зашел в тупик. в мануале нашел какой порт там вывод... 3.1 оказался...
но к сожалению к успеху не привело.

[VladimirYU]

в бине размер проги 64кб, в хексе вдвое больше... ну а сорс вообще 600 кб
Но мы трудностей не боимся. Я поробовал следовать вашей логике Палыч, но к сожалению
зашел в тупик. в мануале нашел какой порт там вывод... 3.1 оказался...
но к сожалению к успеху не привело.

Задача не из простых. Откуда уверенность, что исходник писался на асме. Первое с чего можно начать, это отследить все вектора прерываний от входа до RETI. Далее инициализацию всех SFR. Затем более детальный анализ кода с целью выделить таблицы, это делается достаточно просто, они, как правило дизасемблируются в бессмыслицу. Конечная цель получить исходник дающий при компиляции исходный HEX. После этого можно анализировать алгоритмы, если необходимо вносить изменения. Труд почти египетский, но при наличии опыта реальный. ИДА для этих целей, пожалуй, лучшее, что есть, особенно если она поддерживает Ваш тип МК.