---

Тема 10 Проведение изменений в ПО

Обратный инжиниринг. Определение, цели проведения

Под реверс-инжинирингом программного обеспечения понимается следующее:

Обратная разработка (обратный инжиниринг, реверс-инжиниринг; англ. reverse engineering) — исследование некоторого устройства или программы, а также документации на них с целью понять принцип его работы и, чаще всего, воспроизвести устройство, программу или иной объект с аналогичными функциями, но без копирования как такового.

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

Реверс-инжиниринг (Reverse Engineering) или, как его еще называют, обратная разработка, а иногда — обратное проектирование — это процесс анализа приложения для определения его функциональных характеристик, внутренней архитектуры и, собственно, его работы: модулей, функций, алгоритмов.

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

Цели проведения реинжиниринга заключаются в следующем:

· получение представления о составе существующей системы;

· моделирование существующей системы;

· определение фрагментов программного кода, которые могут быть использованы в разрабатываемой новой системе;

· определение наследуемых данных.

Задачи, решаемые при реинжиниринге, включают:

· определение системных архитектур;

· определение актеров существующей системы;

· определение функциональности существующей системы;

· определение логической структуры системы;

· восстановление реляционной модели данных.
Этапы обратного инжиниринга

• 
  Начальная фаза. Фиксируется текущее состояние наследуемой системы (все изменения, вносимые в нее после этого момента, при выполнении реинжиниринга не учитываются).
  
• 
  Определение системных архитектур. Определяются архитектуры БД, оборудования и стандартного ПО, телекоммуникаций. Все архитектуры представляются в нотации UML и при необходимости дополняются текстовыми описаниями.
  
• 
  Автоматический реинжиниринг осуществляется с помощью инструментальных средств визуального моделирования. Ему подвергается как бизнес логика (если есть исходные коды на объектно-ориентированном или объектно-базированном языке), так и БД.
  
• 
  Реинжиниринг БД выполняется с помощью инструментальных средств проектирования БД. Результатом является реляционная модель данных, которая может графически отображаться этим средством.
  
• 
  Редактирование диаграмм моделей. Главной целью редактирования на этом этапе является достижение наглядности диаграмм. Метод повышения наглядности диаграмм хорошо известен. Это иерархическая реструктуризация. Средством ее осуществления в UML являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих разное целевое назначение и функциональность.
  
• 
  Построение функциональной модели. Модель функционирования описывается с помощью диаграмм ВИ и детализирующих их диаграмм последовательностей и деятельностей. Источником для ее построения является работающая наследуемая система и проводимые с ней эксперименты.
  
• 
  Определение актеров. Для нахождения актеров следует искать ответы на следующие вопросы: · Кто является непосредственными пользователями системы? Необходимо при ответе на данный вопрос указывать роли, а не конкретных людей, исполняющих эти роли.
  
• 
  Определение вариантов использования выполняется на основе анализа экранов работающей системы. Сначала определяются пакеты ВИ. Для этого следует найти все первичные экраны и для каждого из них в модели на головной диаграмме ВИ завести отдельный пакет. Таким образом, на этой диаграмме будет пакет актеров и несколько пакетов ВИ. Далее выполняется детализация построенных пакетов ВИ на основе анализа экранных форм.
  
• 
  Определение взаимодействий актеров и ВИ. В модель включаются ассоциации. Они имеют направления, соответствующие направлениям передачи информации между актерами и ВИ.
  
• 
  Распределение по пакетам. Если число актеров или ВИ слишком велико, то для упрощения поддержки модели ВИ целесообразно разделить их по пакетам.
  
• 
  Построение навигации экранов. Одновременно с выделением ВИ строится навигация экранов наследуемой системы в виде диаграммы классов UML. Каждый экран показывается в модели как отдельный класс, в котором полям соответствуют атрибуты, функциональным кнопкам – операции, а кнопкам меню – одноименные отношения.
  
• 
  Детализация функциональности представляет собой построение сценариев реализации ВИ, представленных в модели ВИ. Она выполняется с помощью диаграмм последовательностей и диаграмм деятельностей UML.
  

---

Анализ исходных данных

Цель процесса анализа и проектирования состоит в разработке технических инструкций, предписывающих, как реализовать ПС, удовлетворяющую сформулированным требованиям. Для этого следует хорошо понять требования к ПС и преобразовать их в проект системы, выбрав правильную стратегию реализации. На ранних стадиях процесса должна быть создана устойчивая архитектура, на основе которой можно спроектировать ПС, легкую для понимания, построения и развертывания. Архитектура должна быть согласована со средой реализации с целью удовлетворения требований к производительности, устойчивости, безопасности, расширяемости и тестируемости.

К числу решаемых задач при этом относятся:

• 
  разработка точной архитектуры распределенной программной системы;
  
• 
  преобразование модели требований в модель проектную разрабатываемой системы;
  
• 
  адаптация проекта системы к среде реализации с целью повышения производительности разработки;
  
• 
  выбор механизмов реализации и определение ограничений на реализацию;
  
• 
  разработка компонентной структуры;
  
• 
  распределение компонентов по узлам.
  

Главной задачей анализа является преобразование требований в форму, понятную разработчику, то есть, определение подсистем, компонентов и классов, с помощью которых реализуется требуемое поведение ПС. В основе такого преобразования лежат ВИ, созданные при определении требований к ПС. При этом рассматриваются только функциональные требования и игнорируются нефункциональные.

В процессе анализа и проектирования создаются следующие документы:

Модель проектирования – это основная модель ПС. Она описывает подсистемы, пакеты, компоненты, интерфейсы и классы, а также их взаимодействия, обеспечивающие требуемое поведение ПС.

Документ «Архитектура ПС», в котором собраны различные архитектурные представления ПС.

Модель данных – это описание структуры данных, хранимых в БД (например, реляционная модель данных).
Получение экспертиз. Реверсивный инжиниринг

Исследование и обратная разработка программ обычно осуществляются с целью дальнейшей модификации, копирования, или, например, написания генераторов ключей, алгоритм работы которых получен на основе анализа алгоритма их проверки. Также исследование программ применяется с целью получения некоторых закрытых сведений о внутреннем устройстве программы — о протоколе сетевого обмена с сервером, аппаратным средством, ключом защиты или о взаимодействии с другой программой. Ещё одна область применения — получение информации о способах экспортирования данных из многочисленных проприетарных форматов файлов.

---

Такой способ наиболее приемлем в тех случаях, когда создатель первоначальной программы скрыл или не предоставил информацию о производстве конкретного объекта. Осуществляет такой инжиниринг специалист, имеющий квалификацию: «программист» или «инженер компьютерных технологий». Способ широко применяется в производстве, бизнесе, различных отраслях промышленности.

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

• 
  Машинный анализ кода.
  
• 
  Составление алгоритма.
  
• 
  Выработку кода.
  
• 
  Выделяет особенности и спецификации.
  
• 
  Вносит усовершенствования.
  
• 
  Использует некоторые элементы идентичности.
  
• 
  Заменяет драйвер собственным.
  

С развитием Интернета популярные операционные системы и программы всё интенсивнее исследуются на предмет обнаружения в них уязвимостей или т. н. «дыр». В дальнейшем найденные дыры могут использоваться для получения несанкционированного доступа к удалённому компьютеру или компьютерной сети. C другой стороны, обратная разработка применяется при исследовании антивирусными компаниями вредоносного ПО c целью добавления его сигнатур в базы своих продуктов.
В настоящее время под словами «reverse engineering» чаще всего понимается т. н. clean room reverse engineering, то есть процесс, при котором одна группа разработчиков анализирует машинный код программы, составляет алгоритм данной программы на псевдокоде либо, если программа является драйвером какого-либо устройства, составляет исчерпывающие спецификации интересующего устройства. После получения спецификаций другая группа разработчиков пишет собственный драйвер на основе полученных спецификаций или алгоритмов. Такой подход позволяет избежать обвинений в нарушении авторских прав на исходную программу. Результат обратной разработки редко идентичен оригиналу, что и позволяет избежать ответственности перед законом, особенно при условии контроля отсутствия этой идентичности первой группой разработчиков и отсутствия нарушений торговых марок и патентов.
Методики проведения обратного инжиниринга

Обратная разработка программного обеспечения основана на следующих способах, применяющихся в производстве и бизнес-сфере:

---

Постоянный обменный анализ данных любого протокола. Здесь используют анализатор шины, а также пакетный сниффер.

Дизассемблирование – метод считывания прямого кода машины и используемого языка. Применяется к любой компьютерной программе. Считается длительным процессом.

Декомпиляция – создание ключевого кода программы с помощью определенного языка программирования. Язык выбирает инженер-программист.

Использование первоначальной базы данных. Это позволяет создать конкретную модель.

Аналитика исходного кода и создание нужной программы предоставляют возможность восстановления исходного кода проекта, который был первоначальным. Это позволяет образовать связи между классами и блоками различных бизнес-процессов. Реверс часто применяется в отношении форматов, которые поддерживаются программой Microsoft Office.

В ряде инструментов UML процесс импорта и анализа исходного кода для создания диаграмм UML называется «обратным проектированием». Хотя UML является одним из подходов к обеспечению «обратного проектирования», недавние достижения в области международных стандартов привели к разработке Метамодели обнаружения знаний (KDM). Стандарт предоставляет онтологию для промежуточного (или абстрактного) представления конструкций языка программирования и их взаимосвязей. Стандарт группы управления объектами (который также становится стандартом ISO), KDM начал завоевывать промышленность с помощью разработки инструментов и сред анализа, которые могут обеспечивать извлечение и анализ источника, двоичный и байтовый код. Для анализа исходного кода архитектура гранулярных стандартов KDM позволяет извлекать потоки программной системы (данные, управление и карты вызовов), архитектуры и знания бизнес-уровня (правила, термины и процессы). Стандарт позволяет использовать общий формат данных (XMI), позволяющий коррелировать различные уровни системных знаний для детального анализа (например, первопричина, влияние) или производного анализа (например, извлечения бизнес-процессов). Хотя усилия по представлению языковых конструкций могут быть бесконечными из-за количества языков, непрерывной эволюции языков программного обеспечения и разработки новых языков, стандарт все же позволяет использовать расширения для поддержки широкого набора языков, а также эволюция. KDM совместим с UML, BPMN, RDF и другими стандартами, что позволяет выполнять миграцию в другие среды и, таким образом, использовать системные знания для таких усилий, как преобразование программных систем и анализ уровня предприятия.

---

Смотрите также файлы

• Генеральный директор ооо Альтернатива.doc

• Рабочая программа по предмету Информатика для 8 А класса срок реализации 20212022 уч год.pdf

• Программа применения методов увеличения добычи нефти на проектный период.docx

• Образовательное учреждение высшего образования воронежский государственный технический университет.docx

• Антропова надежда александровна.rtf