Реверс инжиниринг
на примере торта

Всё следует упрощать до тех пор, пока это возможно, но не более того.
Альберт Эйнштейн

Для меня тема обратной разработки стала очень важна. Она полезна в проектировании собственных устройств и написании кода. Все в мире подвергалось и подвергается обратной разработке.

К примеру, бомбардировщик b-29 или персональный компьютер IBM. Без обратной разработки не было бы возможно создать столько unix подобных операционных систем для стационарных и портативных устройств. А зачем реверс инжиниринг вам? Давайте разберемся.

Начнем с понятия, что такое “реверс инжиниринг”. Реверс инжиниринг - это исследование готового проекта или документации, при котором воссоздается документация и появляется возможность изготовления копии.

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

Почему в качестве примера я беру торт?

Торты вкусные. Особенно те, которые я ем.

Если без шуток, то тут есть, что скопировать и тортов великое множество. Наличие разнообразия в выборе торта говорит нам о том, что когда-то был проведен реверс инжиниринг, и не один раз.

cake

Я буду описывать процесс обратной разработки. Для начала определим внешний вид. Торт снаружи покрыт матовым веществом черного цвета и красной блестящей глазурью. Понять, как сделана матовость торта, невозможно. Внутренняя структура также не видна.

Отрежем кусочек.

slice_of_cake

Видны внутренние слои, а также стала ясна основа торта. Это не бисквитные коржи, а мусс. Это значит, что, скорее всего, торт изначально складывали слоями, постепенно заполняя муссом.

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

Проблемы

И здесь мы переходим проблемам, с которыми мы можем столкнуться при реверс инжиниринге.

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

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

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

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

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

Есть еще один выявленный мной подводный камень. Это избыточность производимых исследований. Она в чем-то коррелирует с наукоемкостью, но не всегда. Иногда изделие может быть совсем не наукоемким, но при этом для него потребуются избыточные исследования. Яркий тому пример это торт. Чтобы узнать, как сделан определенный ингредиент торта, надо произвести реверс инжиниринг, целью которого будет только этот самый ингредиент. Хотя тот, кто проектировал торт изначально, мог не производить больших временных или денежных затрат, не достигая наукоемкости и избыточности.

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

На этом все. Спасибо, что читаете мой блог.