|
Когда-то хакеры делали инструменты для себя, чтобы украсть чужой код-сломать защиту, убрать ограничения и прочее. Это актуально и сейчас. Но уже актуально и другое: потому как во многих фирмах сменились поколения разработчиков, а рабочий софт остался и переписывать заново далеко не всюду позволяют различные обстоятельства. Хорошо, когда железяка сменилась-тут уж и флаг в руки. А если нет? Если сарай достраивают вместо того, чтобы снести и начать новый? Так что задача достаточно общая. Я тут погулял по воздуху, и подумал, что конечно идентичность кода - это мурня! И разный код может делать практически одно и то же( особенно если это код не низкоуровневый инициализирующий разные функциональные регистры).
Но все же в ассемблере очень существенно не исказить "критические состояния" железяки! То есть всякие там флажки в статусных регистрах, указатели сегментов и прочее. А это видно в фрагментах, следующих за вызовами процедур.
Если говорить, что есть некая железяка и важно, что на ней должно делаться то же самое- это одно. Тут можно переписать заново процентов на 90. А если речь идет о поэтапной замене частей отлаженного и работающего определенным образом пакета - это другое!
Ведь структура его задается и железом, и функциональностью софта, но есть общие части: главный цикл, процедуры обработки прерываний и т.д.
В моем случае этот софт структурирован очень хорошо. И даже есть пример внедрения в него функций на C(правда когда у этого внедрятеля не хватало терпения и средств, он в своих с-функциях использовал опять-таки скобку asm-endasm.Поэтому хотелось бы ссылку на статью, где обсуждается эта проблема, или на готовый инструмент этого класса.
Заодно там бы нашлись и нужные термины, чтобы не пороть отсебятину.
Самое простенькое - зарисовать все в виде иерархического дерева вызовов, с указанием из какого модуля что вызывается и где, что определено. Файлов в проекте около 40 (.inc,.asm,.h,.c). Уже если это где-то есть готовое и то уже хорошо. Мультиед позволяет делать таги, но дерева не рисует.
E-mail: info@telesys.ru