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

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

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

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

Спасибо.

Только "метод пристального взглядывания" + опыт дисассемблирования + умение читать асм + наличие электрической схемы

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

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

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

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

"3.1" - это, наверное, Р3.1? Т.е., TXD? Вывод байтов происходит по UART? В программе нужно смотреть 1) на что указывает вектор 23; 2) участки кода, использующие SFR с именами (адресами) SCON (98h) и SBUF (99h). Эти участки кода и отвечают за ввод/вывод по UART.
Кстати, какой тип МК применён в устройстве?

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

Все это делается исключительно ручками, к сожалению если у Вас интенсивно переключаются банки памяти - еще труднее. Основная проблема - в ловле таких мест, как таблица переходов,
или типа такого:

В общем, реверс-инженегринг. А то, что Вы эту тему положили в AVR, наверное, символизирует тоску
Int0 или Int1 свободны? Если да, то можно кого-то из них засадить в ноль и пропатчить программу своим пошаговым трассировщиком.

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

Всем спасибо... сделал вывод что не осилю В иде канеш красиво в графическом виде выглядит, но видимо писано на С потому что некоторые телодвижения программы мне не понятны впринципе ...


А тему в авр написал, потому что проц АТ.

Вам подсказали правильный путь: проверить наличие аппаратного USART'а на ноге 3.1. Это ж TXD на AT89S8252 к примеру (ну у вас что-то еще явно). У USART'а есть прерывания, на обработчики прерываний ведут вектора из таблицы прерываний, которая, обычно по адресу 0. Далее прям поиском по тексту в IDA можно искать имена регистров USART'а - найдете обращение к ним. Логику вокруг них понять можно обычно. Далее найдете куда сохраняются данные, откуда передаются - это буферы. Найдете где обращение к ним - вот там и обработка данных. И далее анализируйте код. Если есть примерное понятие как работает устройство и схема - это упростит дело.

PS: IDA почему-то неверно декодит *.hex (может я не умею ее готовить?), я ей обычно бинарник отдаю.

AT означает Atmel и Ваша тема к AVR не имеет никакого отношения.
Тему перенёс в 51, где ей и место.

Для разбора программ из-под С надо начинать с анализа библиотек, после этого разбор в некотором смысле становится даже проще