Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекция № 20
Цель: Изучить базовые задачи, решаемые злоумышленником при реализации обратного проектирования с целью взлома ПО и классификацию средств обратного проектирования.
План лекции
2. Rational Rose – пример инструментального средства обратного проектирования
1 Обратное проектирование (Reverse engineering)
Обратным проектированием называется процесс преобразования в модель кода, записанного на каком-либо языке программирования. В результате этого процесса получается огромный объем информации, часть которой находится на более низком уровне детализации, чем необходимо для построения полезных моделей. В то же время обратное проектирование никогда не бывает полным. Поскольку прямое проектирование ведет к потере информации, полностью восстановить модель на основе кода не удастся, если только инструментальные средства не включали в комментариях к исходному тексту информацию, выходящую за пределы языка реализации.
Рассмотрим пример, связанный с языком UML.
Прямое и обратное проектирование компонентов выполняется довольно просто, так как компоненты – это физические сущности (исполняемые программы, библиотеки, таблицы, файлы и документы), а потому они близки к работающей системе. При прямом проектировании класса или кооперации вы на самом деле проектируете компонент, который представляет исходный код, двоичную библиотеку или исполняемую программу для этого класса или кооперации. Точно так же при обратном проектировании исходного кода, двоичной библиотеки или исполняемой программы вы в действительности проектируете компонент или множество компонентов, которые отображаются на классы или кооперации.
Решая заняться прямым проектированием (созданием кода по модели) класса или кооперации, вы должны определиться, во что их нужно преобразовать: в исходный код, двоичную библиотеку или исполняемую программу.
Логическую модель имеет смысл превратить в исходный код, если вас интересует управление конфигурацией файлов, которые затем будут поданы на вход среды разработки.
Логические, модели следует непосредственно преобразовать в двоичные библиотеки или исполняемые программы, если вас интересует управление компонентами, которые фактически будут развернуты в составе работающей системы.
Иногда нужно и то, и другое. Классу или кооперации можно поставить в соответствие как исходный код, так и двоичную библиотеку или исполняемую программу.
Прямое проектирование диаграммы компонентов состоит из следующих этапов:
Обратное проектирование (создание модели по коду) диаграммы компонентов – не идеальный процесс, поскольку всегда имеет место потеря информации. По исходному коду вы можете обратно спроектировать классы - это более или менее обычное дело. Обратное проектирование компонентов из исходного кода выявляет существующие между файлами зависимости компиляции. Для двоичных библиотек самое большее, на что можно рассчитывать, – это обозначить библиотеку как компонент, а затем путем обратного проектирования раскрыть его интерфейсы. Это второе из распространенных действий, которые выполняются над диаграммами компонентов. Такой подход может быть полезен при знакомстве с новыми плохо документированными библиотеками. Исполняемую программу можно лишь обозначить как компонент и затем дизассемблировать ее код, но вряд ли вы будете этим заниматься, если не пишете на языке ассемблера.
Обратное проектирование диаграммы компонентов осуществляется так:
2 Rational Rose – пример инструментального средства обратного проектирования
Одно из неоспоримых преимуществ Rational Rose – обратное проектирование, поскольку разработчику и проектировщику важно увидеть перед изменениями уже работающую систему в нормальном графическом представлении. Как правило, визуально-графический ряд оказывает куда большее воздействие, нежели пролистывание технических заданий и программных текстов. Тем более что проект, подвергшийся обратному проектированию, может быть доработан и вновь сгенерирован (а впоследствии и скомпилирован). Rational Rose предоставляет для этого все необходимые средства.
Для осуществления обратного проектирования в Rational Rose предусмотрен мощный модуль Analyzer, чье основное предназначение, вытекающее из названия, – анализ программ, написанных на С и C++. Данный модуль способен проанализировать имеющийся файл на одном из вышеупомянутых языков и преобразовать его в визуальную модель, присвоив выходному файлу расширение mdl. Далее файл можно спокойно открыть для модификации из Rational Rose уже в визуальном режиме.
Analyzer представляет собой отдельный программный файл, вызываемый как из самой Rose, так и обычным способом. Модуль входит не во все поставки Rational Rose, а только в Enterprise, Professional и Real Time. В поставку Data Modeler данный модуль не входит, поскольку специфика поставки не предусматривает генерации кода и обратного проектирования. Для правильного преобразования кода в модель необходимо провести несколько настроек.
На рис. 1 показан внешний вид программы в стандартных настройках и с незагроможденным экраном. Запустить Analyzer можно, выбрав в меню программы Tools/C++/Reverse engineering.
Рис. 1.
Основные поля, подлежащие обязательному заполнению (на первом этапе), – это:
• Caption – имя проекта. Впоследствии имя модели будет определено по имени проекта.
• Directories – путь к исходящей директории. По умолчанию Rose использует для хранения исходящих модельных файлов директорию C++\Source из домашней директории, что в некоторых случаях может приносить некоторые неудобства.
• Extensions – типы используемых расширений. Здесь можно настроить систему так, чтобы она распознавала только определенные виды расширений.
• Bases – место сохранения текущего проекта.
• Files – список из файлов, подлежащих генерации.
Для проведения правильного обратного проектирования необходимо заполнить вышеописанные поля. Все файлы, подлежащие обратному проектированию, указываются в поле Files. Следует учитывать, что при этом вы получаете визуальную модель взаимодействия классов и структур; стало быть, речь не идет о том, чтобы на визуальной модели отразился существующий код системы. Далее, все нестандартные конструкции не будут выведены в модель (анализатор их просто проигнорирует); это значит, что любое отклонение от заранее известных конструкций приводит к тому, что в изначальном варианте Rose не сможет правильно проанализировать код. Этот факт не является недостатком, поскольку в арсенале Analyser есть инструменты тонкой настройки, позволяющие настроить все таким образом, чтобы специфика конкретного проекта была полностью учтена.
Процесс обратного проектирования делится на два этапа: анализ и генерацию модели.
На первом этапе производятся все подготовительные операции по анализу текста программы на отсутствие синтаксических ошибок. Второй этап –это преобразование кода в модель.
Все операции выполняются независимо, что дает больший маневр для разработчика, который, например, хочет провести только синтаксический разбор теста, без генерации модели.
Соответственно при отсутствии ошибок в файле можно приступить к генерации модели. В целях оптимизации времени генерации в Rose предусмотрено три способа проведения обратного проектирования, каждый из которых может охватить и превосходно выполнить определенный сегмент работ. Если пользователю по каким-либо причинам не подходит ни один из трех предустановленных способов, то Rose допускает создание собственного способа обратного проектирования.
Поговорим подробнее о следующих трех стандартных способах:
• First Look – приближенная пробежка по телу программы;
• Detailed Analysis – детальный анализ проекта;
• Round Trip – комбинация двух вышеперечисленных способов. Позволяет безболезненно строить и перестраивать разрабатываемые приложения по принципу круговой разработки.
Все настройки могут быть изменены по усмотрению пользователя. При сохранении изменений возможно указать новое имя шаблона или перезаписать уже существующее, что позволит при частом использовании обратного проектирования не терять времени на установку нужного пункта. Выбор соответствующего пункта обязательно сказывается на скорости анализа, чем больше – тем дольше. Еще хочется отметить такую особенность модуля Analyzer: после анализа создается не только модель, но и лог-файл с сообщениями, возникшими в результате сканирования программы. Лог может содержать как предупреждения, так и ошибки. А особенность генерации модели состоит в том, что она состоится несмотря ни на что, т. е. невзирая на ошибки в тексте программы. Естественно, никакой речи нет о какой-либо правильной модели! Эту особенность следует учитывать и внимательно анализировать файл отчета после генерации модели.
Как правило, обратному проектированию подвергается полноценный проектный файл, содержащий в себе и директивы #INCLUDE для определений, и комментарии, а также прочие сопроводительные инструкции. И естественно, разработчику хочется иметь такой инструмент, который адекватно будет реагировать на все составляющие. Для этого модуль Analyzer в режиме (Detailed Analysis) обеспечивает следующее:
• анализ программ и преобразование в визуальную модель классов и структур;
• генерацию связей в модели (между классами или структурами);
• нахождение в исходном тексте комментариев и перенос их в качестве атрибутов компонентов модели. То есть если исходный текст снабжен комментариями, то они все перейдут в виде атрибутов к соответствующему элементу (переменной, массиву и т. д.);
• способен закачать в проект все заголовочные файлы (по цепочке один за другим).
Нашей целью будет получение графической модели из класса на языке программирования. Обратите внимание на комментарии. Каждая строка снабжена комментарием. Смысл обратного проектирования состоит не только в том, чтобы корректно нарисовать модель, но и для правильного описания спецификации каждой составляющей класса. За основу программы возьмем следующий класс:
//It's main class class string public:
char *string; //Structure's pointer
int buffer[100]; //Temporary buffer
char name[10]={"Massiv"}; //Name of data
int a; //Integer
int b; //Integer void string(void); //constructor
void ~string(void); //destructor char String Copy(char *, //Buffer char *, //source char *); //source2 private:
int tmp_a;
int tmp_b;
Результат обратного проектирования представлен на рис. 2.
Рис. 2 - Класс String
Рис. 2 показывает модель класса string. А на рис. 3 отображается вкладка, описывающая функции класса.
Рис. 3 - Вкладка описывающая функции класса String
Как и в случае с переменными имена функций отображаются на экране. Также доступен вход в спецификации конкретной функции. Если еще раз вернуться к листингу, то можно обратить внимание на декларацию функции String Copy, в которой входные параметры подробно документированы. Так вот: если был применен подобный подход к документированию, то комментарий каждого параметра перенесется в качестве описательного комментария в соответствующую часть атрибута модели класса. То есть, получается, очень выгодно подвергать обработке исходные тексты, написанные по всем правилам программирования.
Выразительные средства визуального проектирования и анализа делают Rational Rose незаменимым инструментом при создании крупных информационных систем. Особенно полно Rose раскрывает свои возможности при анализе эффективности не новой системы, а уже существующей. Вышеуказанные примеры показывают, что это мощный инструмент при анализе проекта на предмет повышения его эффективности. Данная проблема не является надуманной, поскольку подобный анализ нужен компаниям переводящим, например, старое программное обеспечение на новые платформы и новые технологии.
Модель ничего не теряет в результате обратного проектирования, в то же время само обратное проектирование представляет мощный механизм анализа эффективности существующих программных наработок нажатием на одну-две кнопки.
Rational Rose имеет в своем арсенале возможность прямого и обратного проектирования на ADA, Java, C++, COM, DDL, Basic, XML; схемы Oracle и Sql srv. Roseимеет открытое, хорошо документированное API, позволяющее любому человеку создать дополнительный модуль (мост) для любого языка. На сегодняшний день Rose – это уникальный продукт в плане открытости архитектуры.
Контрольные вопросы
1.Для чего предназначено обратное проектирование?
2.Какой модуль используется для анализа исходного кода?
3.Какая часть кода не используется при построении модели?
4.Какие основные способы обратного проектирования присутствуют в Rational Rose?
5.Как при обратном проектировании описываются внешние связи системы?