noobie 0 25 марта, 2009 Опубликовано 25 марта, 2009 · Жалоба Ребята, натолкните на истинный путь.... Есть сабж который обрабатывает приходящую на него инфу и выплевывает чтото понятное программе, с которой он работает. Допустип улетело на него 17 байт там чота внутри поделалось и вылетело 17. Все это красиво видно в различных сниферах. Содержимое этого процессора у меня есть, однако когда в IDA видишь программу почти 100 кб :( теряешься. Может ктонибудь подскажет как проще найти тот самый алгоритм где именно обрабатываются наши заветные байтики :laughing: В качестве дебаггера пробовал искользовать Keil однако дизассемблированный прошивон надо дорабатывать, чтобы он закрутился в дебаггере, а опыта ни очень :smile3046: много... Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vvs157 0 25 марта, 2009 Опубликовано 25 марта, 2009 · Жалоба Содержимое этого процессора у меня есть, однако когда в IDA видишь программу почти 100 кб :( теряешься. Может ктонибудь подскажет как проще найти тот самый алгоритм где именно обрабатываются наши заветные байтики :laughing: Только "метод пристального взглядывания" + опыт дисассемблирования + умение читать асм + наличие электрической схемы Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
noobie 0 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба Только "метод пристального взглядывания" + опыт дисассемблирования + умение читать асм + наличие электрической схемы дело в том, что как бы всего етого есть по чуть чуть... просто я уповал на наличие некой методики... скажем методом от обратного, когда ищется выходной порт который у сабжа 3.1 и потом от него по обратной цепочке... :maniac: Просто я не могу до конца предстаить себе как можно отследить весь этот технологический процесс обработки данных процессором, тобишь программно сэмулировать его работу и самому руками скажем внести ети 17 байт и дальше смареть что с ними происходит. :smile3046: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Палыч 10 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба Содержимое этого процессора у меня есть, однако когда в IDA видишь программу почти 100 кб :( теряешься. Сто килобайт - это размер программы МК? Что же за МК применён в устройстве? Или программа хранилась во внешнем ПЗУ? При таком размере кода найти обработчик информации, действительно, очень трудно. В качестве дебаггера пробовал искользовать Keil однако дизассемблированный прошивон надо дорабатывать, чтобы он закрутился в дебаггере, а опыта ни оченьМожно использовать другие симуляторы, которые не интегрированны в единую среду с транслятором и линковщиком, и принимают на входе hex-файл (или бинарник) для симуляции. Когда-то давно сам таким пользовался, но за ненадобностью - симулятор не сохранился... Погуглите. В такой большой программе алгоритм поиска искомого Вами участка, наверное, один: 1) определить тот кусок программы, который ответственнен за вывод байтов (например, по вектору прерывания ввода/вывода и просмотра соседних участков программы); 2) определение кусков программы, которые обращаются к нему (это делает IDA); 3) выбор из них нужного Вам; 4) разбор этого участка программы. Всё это можно проделать и без симулятора. Но, нужно упорство, усидчивость, внимательность и время... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
noobie 0 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба Сто килобайт - это размер программы МК? Что же за МК применён в устройстве? Или программа хранилась во внешнем ПЗУ? При таком размере кода найти обработчик информации, действительно, очень трудно. Можно использовать другие симуляторы, которые не интегрированны в единую среду с транслятором и линковщиком, и принимают на входе hex-файл (или бинарник) для симуляции. Когда-то давно сам таким пользовался, но за ненадобностью - симулятор не сохранился... Погуглите. В такой большой программе алгоритм поиска искомого Вами участка, наверное, один: 1) определить тот кусок программы, который ответственнен за вывод байтов (например, по вектору прерывания ввода/вывода и просмотра соседних участков программы); 2) определение кусков программы, которые обращаются к нему (это делает IDA); 3) выбор из них нужного Вам; 4) разбор этого участка программы. Всё это можно проделать и без симулятора. Но, нужно упорство, усидчивость, внимательность и время... в бине размер проги 64кб, в хексе вдвое больше... ну а сорс вообще 600 кб :( Но мы трудностей не боимся. Я поробовал следовать вашей логике Палыч, но к сожалению зашел в тупик. в мануале нашел какой порт там вывод... 3.1 оказался... но к сожалению к успеху не привело. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Палыч 10 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба Я поробовал следовать вашей логике Палыч, но к сожалению зашел в тупик. в мануале нашел какой порт там вывод... 3.1 оказался... но к сожалению к успеху не привело. "3.1" - это, наверное, Р3.1? Т.е., TXD? Вывод байтов происходит по UART? В программе нужно смотреть 1) на что указывает вектор 23; 2) участки кода, использующие SFR с именами (адресами) SCON (98h) и SBUF (99h). Эти участки кода и отвечают за ввод/вывод по UART. Кстати, какой тип МК применён в устройстве? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladimirYU 0 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба в бине размер проги 64кб, в хексе вдвое больше... ну а сорс вообще 600 кб :( Но мы трудностей не боимся. Я поробовал следовать вашей логике Палыч, но к сожалению зашел в тупик. в мануале нашел какой порт там вывод... 3.1 оказался... но к сожалению к успеху не привело. Задача не из простых. Откуда уверенность, что исходник писался на асме. Первое с чего можно начать, это отследить все вектора прерываний от входа до RETI. Далее инициализацию всех SFR. Затем более детальный анализ кода с целью выделить таблицы, это делается достаточно просто, они, как правило дизасемблируются в бессмыслицу. Конечная цель получить исходник дающий при компиляции исходный HEX. После этого можно анализировать алгоритмы, если необходимо вносить изменения. Труд почти египетский, но при наличии опыта реальный. ИДА для этих целей, пожалуй, лучшее, что есть, особенно если она поддерживает Ваш тип МК. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба В качестве дебаггера пробовал искользовать Keil однако дизассемблированный прошивон надо дорабатывать, чтобы он закрутился в дебаггере, а опыта ни очень :smile3046: много... Все это делается исключительно ручками, к сожалению если у Вас интенсивно переключаются банки памяти - еще труднее. Основная проблема - в ловле таких мест, как таблица переходов, или типа такого: push r0 push r1 ret В общем, реверс-инженегринг. А то, что Вы эту тему положили в AVR, наверное, символизирует тоску :) Int0 или Int1 свободны? Если да, то можно кого-то из них засадить в ноль и пропатчить программу своим пошаговым трассировщиком. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Палыч 10 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба Конечная цель получить исходник дающий при компиляции исходный HEX.Автору ведь не нужно вносить изменения в работающий код, нужен алгоритм преобразования некой (наверное, ключевой) информации в ответную последовательность символов. Всю память программ перелопачивать до вида исходника нет необходимости. Конечно, если программа писалась на языке высокого уровня, то понять алгоритм сложнее, но, при старании - можно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
noobie 0 26 марта, 2009 Опубликовано 26 марта, 2009 · Жалоба Автору ведь не нужно вносить изменения в работающий код, нужен алгоритм преобразования некой (наверное, ключевой) информации в ответную последовательность символов. Всю память программ перелопачивать до вида исходника нет необходимости. Конечно, если программа писалась на языке высокого уровня, то понять алгоритм сложнее, но, при старании - можно. Всем спасибо... сделал вывод что не осилю :( В иде канеш красиво в графическом виде выглядит, но видимо писано на С потому что некоторые телодвижения программы мне не понятны впринципе :(... А тему в авр написал, потому что проц АТ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NullPointer 0 26 марта, 2009 Опубликовано 26 марта, 2009 (изменено) · Жалоба Вам подсказали правильный путь: проверить наличие аппаратного USART'а на ноге 3.1. Это ж TXD на AT89S8252 к примеру (ну у вас что-то еще явно). У USART'а есть прерывания, на обработчики прерываний ведут вектора из таблицы прерываний, которая, обычно по адресу 0. Далее прям поиском по тексту в IDA можно искать имена регистров USART'а - найдете обращение к ним. Логику вокруг них понять можно обычно. Далее найдете куда сохраняются данные, откуда передаются - это буферы. Найдете где обращение к ним - вот там и обработка данных. И далее анализируйте код. Если есть примерное понятие как работает устройство и схема - это упростит дело. PS: IDA почему-то неверно декодит *.hex (может я не умею ее готовить?), я ей обычно бинарник отдаю. Изменено 26 марта, 2009 пользователем SysRq Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 27 марта, 2009 Опубликовано 27 марта, 2009 · Жалоба А тему в авр написал, потому что проц АТ. AT означает Atmel и Ваша тема к AVR не имеет никакого отношения. Тему перенёс в 51, где ей и место. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vvs157 0 27 марта, 2009 Опубликовано 27 марта, 2009 · Жалоба Конечно, если программа писалась на языке высокого уровня, то понять алгоритм сложнее, но, при старании - можно.Для разбора программ из-под С надо начинать с анализа библиотек, после этого разбор в некотором смысле становится даже проще Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
