Графическое построения вида функций исполняемого модуля
Уважаемые форумчане! Срочно требуется помощь. Я не прошу написать за меня код, а лишь подсказать направление, в котором думать.
Необходимо построить графическую схему ветвлений программы на основе дизассемблированного кода. Задача официально называется: Статический анализ исполнительных модулей с целью определения возможных недекларируемых возможностей в программном средстве.
Может кто-то предложить алгоритм подобной программы? Сам-то код я напишу, но вот как построить ветвление? С ассемблером очень плохо знаком, а задачу нужно решить в кратчайшие сроки. Нечто подобное есть в IDA Pro, Graphs -> Function calls. Т.е. мне надо построить некое графическое ветвление вызова функций, чтобы потом в ручную их анализировать. А вот как это ветвление определить на основании кода ассемблера?
Я может быть сам бы и понял алгоритм работы этого построителя в IDA Pro, но у меня жутко не хватает примеров программ и их кода на ассемблере.
Заранее огромное спасибо.
Необходимо построить графическую схему ветвлений программы на основе дизассемблированного кода. Задача официально называется: Статический анализ исполнительных модулей с целью определения возможных недекларируемых возможностей в программном средстве.
Может кто-то предложить алгоритм подобной программы? Сам-то код я напишу, но вот как построить ветвление? С ассемблером очень плохо знаком, а задачу нужно решить в кратчайшие сроки. Нечто подобное есть в IDA Pro, Graphs -> Function calls. Т.е. мне надо построить некое графическое ветвление вызова функций, чтобы потом в ручную их анализировать. А вот как это ветвление определить на основании кода ассемблера?
Я может быть сам бы и понял алгоритм работы этого построителя в IDA Pro, но у меня жутко не хватает примеров программ и их кода на ассемблере.
Заранее огромное спасибо.
Неужели никто не может подсказать?
процедуры а асме вызываются командой call или парой команд push , jmp\Jnn(условный jmp) . если с командой call всё понятно , то со вторым вариантом возникает столько возможностей , что реализовать всё нереально .
возврат из процедура - команда ret .
возврат из процедура - команда ret .
[QUOTE=3D-GRAF]
Я может быть сам бы и понял алгоритм работы этого построителя в IDA Pro, но у меня жутко не хватает примеров программ и их кода на ассемблере.
[/QUOTE]
Гм, какого именно кода тебе не хватает? Того что анализирует или того который анализируют? Если первое то
[QUOTE=3D-GRAF]
Я не прошу написать за меня код...
[/QUOTE]
Ето еще ладно. Но строить график и потом анализировать его глазками - имхо, мазохизмъ! Вод вздумается тебе раскрыть недокументированные возможности фотошопа... Исполняемых модулей, которые теоретично юзает фотошоп, насобирается примерно на ~70 мб... Можеш уже записыватся на прием к окулисту.
Но абстрагируюсь. Строить график по бинарнику (типа как у IDA) можно руководствуясь таким правилом: как только натыкаешся при разборе на инструкцию условного перехода - создаеш два новых потока разбора: один начинается с адреса на который переходит управление в случае истины, другой - с адреса куда переходит управление в случае не истины (обычно ето следующая за сравнением инструкция). Правило повторяется для каждого нового потока.
upd:
Немножко невнимательно прочел пост.
Если надо построить именно график ветвлений вызовов функций то тут всё еще проще чем при условных переходах. Снова таки, перебираем по почереди инструкции. Если нашли call - увеличиваем стчитчик глубины и переходим разбирать вызываемую функцию. Если ret - возвращаемся на предыдущий уровень и уменьшаем стчетчик глубины.
Но тут могут всплыть такие ньюансы:
первый: алгоритм такого перебора падет на рекурсии
второй: процедуры могут вызыватся разными способами
к примеру (так делают нормальные люди):
или (так нормальные люди не делают)
Вообщем для ефективности надо следить за оперециями над стеком.
третий: возвраты в процедуре могут встречатся не только в конце тела
Я может быть сам бы и понял алгоритм работы этого построителя в IDA Pro, но у меня жутко не хватает примеров программ и их кода на ассемблере.
[/QUOTE]
Гм, какого именно кода тебе не хватает? Того что анализирует или того который анализируют? Если первое то
[QUOTE=3D-GRAF]
Я не прошу написать за меня код...
[/QUOTE]
Ето еще ладно. Но строить график и потом анализировать его глазками - имхо, мазохизмъ! Вод вздумается тебе раскрыть недокументированные возможности фотошопа... Исполняемых модулей, которые теоретично юзает фотошоп, насобирается примерно на ~70 мб... Можеш уже записыватся на прием к окулисту.
Но абстрагируюсь. Строить график по бинарнику (типа как у IDA) можно руководствуясь таким правилом: как только натыкаешся при разборе на инструкцию условного перехода - создаеш два новых потока разбора: один начинается с адреса на который переходит управление в случае истины, другой - с адреса куда переходит управление в случае не истины (обычно ето следующая за сравнением инструкция). Правило повторяется для каждого нового потока.
upd:
Немножко невнимательно прочел пост.
Если надо построить именно график ветвлений вызовов функций то тут всё еще проще чем при условных переходах. Снова таки, перебираем по почереди инструкции. Если нашли call - увеличиваем стчитчик глубины и переходим разбирать вызываемую функцию. Если ret - возвращаемся на предыдущий уровень и уменьшаем стчетчик глубины.
Но тут могут всплыть такие ньюансы:
первый: алгоритм такого перебора падет на рекурсии
второй: процедуры могут вызыватся разными способами
к примеру (так делают нормальные люди):
Код:
call fn_xxx
или (так нормальные люди не делают)
Код:
push $+11
push fn_xxx
ret
push fn_xxx
ret
Код:
sub esp,4
mov dword [esp],$+9
jmp fn_xxx
mov dword [esp],$+9
jmp fn_xxx
Вообщем для ефективности надо следить за оперециями над стеком.
третий: возвраты в процедуре могут встречатся не только в конце тела
может быть поможет поиск в направлении "дерево абстрактного синтаксиса" (синон. "абстрактное синтаксическое дерево") ?!
