Что такое обратная разработка и где она применяется
Законно ли это.
Обратная разработка — метод разборки объекта, который помогает понять, как сконструировано ранее созданное устройство, процесс, система или часть программного обеспечения. Инженер разбирает продукт на части, чтобы понять, как он работает, а потом воссоздать похожее или идентичное решение. Разработчик отвечает на вопрос: «Какие процессы провоцируют именно такое поведение продукта?».
Таким способом не удастся получить точный исходный код, но инженеры смогут понять общую логику работы и повторить функционал.
Часто встречаются названия «обратное проектирование», «обратный инжиниринг», «реверс-инжиниринг» — они означают одно и то же.
Где применяется реверс-инжиниринг
Обратный инжиниринг применяют в компьютерной инженерии, геймдеве, машиностроении, дизайне, электронной инженерии, разработке программного обеспечения, химической инженерии и даже системной биологии.
Компании часто используют обратный инжиниринг старых электронных компонентов, снятых с производства. Если у части компьютерного оборудования были функции, потерянные из-за изменений в технологии, реверс-инжиниринг позволяет производителям открыть и обновить эти формулы. Также метод помогает разрабатывать компоненты, соединяющие новое и старое, чтобы подключать устаревшее оборудование к новому.
В IT обратная разработка программ применяется для исследования софта и железа, их элементов и принципов работы.
Объектами могут быть:
- файлы — чтобы узнать, как именно работает приложение;
- часть операционной системы — чтобы использовать недокументированные функции;
- формат данных — чтобы получить структуру файлового формата;
- сетевой протокол — чтобы восстановить формат пакетов данных и последовательность обмена данными.
Для чего используют обратную разработку:
- поиск и исправление ошибок в программах, к исходному коду которых у разработчиков нет доступа;
- анализ вирусов для создания антивирусного программного обеспечения;
- улучшение функциональности приложения, когда связаться с предыдущим разработчиком не получается — например, компания-разработчик перестала существовать;
- описание механики игры, когда разработчик берет в пример существующую игру, наблюдает за ее развитием, анализирует сценарий и предлагает свой вариант;
- обучение: если разработчик не понимает какую-то часть своего продукта, он может проанализировать чужую и сделать выводы о ее функционировании.
Реверс-инжиниринг также применяют для нелегальных целей — кражи кода, обхода технических средств защиты авторских прав, бесконечного использования бесплатных версий приложения.
Типы реверс-инжиниринга
Существуют десятки видов обратной разработки, поскольку процесс может разбить объект на части по-разному — например, анализ системного уровня, извлечение схемы и разборка продукта.
Принципы обратной разработки
Процесс обратной разработки регулируют общие принципы:
- 1. Не путать гипотезы с выводами. Обратный инжиниринг дает гипотезы. Разработчик должен полностью понять приложение, прежде чем делать выводы.
- 2. Получить несколько интерпретаций. Альтернативные интерпретации данных могут давать разные результаты. Чем больше информации доступно, тем меньше должны различаться суждения реверс-инженеров.
- 3. Понимать, что результаты приблизительны. К примеру, 80% информации девелопер получит благодаря обратной разработке. Чтобы получить оставшиеся 20%, нужно использовать методы прямого проектирования, например, опрос пользователей.
- 4. Не удивляться странным конструкциям. Инженер не сможет воссоздать полную и точную модель, потому что такой модели до этого, возможно, не существовало.
- 5. Следить за единым стилем. Продукт разрабатывают с использованием последовательной стратегии, которую нужно найти и понять.
Этапы реверс-разработки на примере исполняемого файла:
- 1. Запустить и протестировать исполняемый файл, ознакомиться с приложением и его возможностями.
- 2. Проанализировать взаимодействие файла с внешним миром: библиотеками, процессами, системными API, файловой системой, сетевыми взаимодействиями, физическими портами и т. д.
- 3. Детально изучить код. Для этого применяют трансляцию двоичного кода на язык ассемблера, чтобы затем извлечь структуры, инструкции и вызовы функций.
Преимущества
Обратный инжиниринг позволяет увидеть то, что уже есть: любые части, структуры или процессы, которые могли бы принести пользу для разработки. Изучение существующих продуктов приводит к инновациям и открытиям.
Также процесс помогает находить недостатки и уязвимости в продукте. Это необходимо, чтобы обеспечить безопасность пользователей. Лучше, чтобы проблема возникла на этапе исследования, а не на этапе распространения.
Кроме того, благодаря обратной разработке на рынок выходят менее дорогие продукты — затраты на создание снижаются.
Недостатки
Разработчик не сможет полностью вернуть приложение в исходное состояние перед компиляцией. Кроме того, сложно переиспользовать код из дизассемблированного приложения из-за обфускации критического и важного исходного кода. Иногда разработчики загружают в приложение нерелевантный код, чтобы сбить с толку реверс-инженера и еще больше усложнить реверсирование.
Законность реверс-инжиниринга
Коммерческие лицензионные соглашения запрещают реверс-инжиниринг, хотя метод законен.
В США было много судебных прецедентов о реверс-инжиниринге в попытках обойти защиту игровых консолей. Некоторые компании (SEGA, Nintendo и другие) хотели, чтобы у них покупали допуски к консолям и выпускали эксклюзивные игры. Разработчикам игр это не нравилось, ведь проще не покупать лицензию и выпускать игры для всех. Поэтому они находили способы обойти защиту игровых консолей: игры становились общедоступными и совместимыми с консолями.
В 1980-90-х гг. появились первые судебные разбирательства о реверс-инжиниринге и сформировались принципы: авторское право не защищает идеи, процессы и операции, для их защиты нужно использовать патентное право.
С тех пор обратная разработка — законна, если работа требует такого подхода для понимания идей и процессов. Но для этого следует использовать копию продукта, полученную легальным путем.
Если бы реверсную разработку запретили, владелец продукта и кода был бы монополистом на рынке.
