КОНЦЕПЦИЯ ПРЕДОСТАВЛЕНИЯ УСЛУГИ РЕВЕРС-ИНЖЕНЕРИИ ПО И АПК

+7 (953) 468-83-85 10 августа 2023 г.

no_reply@example.com
Андрей Паршин
Название компании
ул. Достоевского,
ул. Достоевского, д. 39,
д. 39,
г. Москва, 127473
г. Москва
127473
Здравствуйте,
представляем вашему вниманию презентацию услуг реверс-инженерии

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

Первым делом рассмотрим проблему восстановления исходных

кодов. Начнем с того, что они могут быть утрачены по разным причинам.
Ребрендинг компании, ее покупка или поглощение другой компанией - в
таких случаях, часть штата уходит за частую в другие места, по какой-то
причине в суматохе бумажной волокиты сотрудники не передают всех
своих работ начальству, кто-то не доглядел, кто-то плохо организовал
рабочие процессы и системы контроля версий. Продукт может быть
просто очень старым, его значимость не была оценена полностью, и для
него, как итог, не было сделано должным образом резервных копий.
Вторая частая причина - работа делалась на заказ третьей стороной, и
эта сторона больше не поддерживает эту разработку, а по условиям
договоренностей в контракт не входила передача исходных кодов. Как
итог, компании больше нет или она сменила свой профиль или
юридический статус, спросить больше не у кого. Конечно, выбор способа
решения этой ситуации остается на плечах риск-менеджмента и
руководства. Сделать новый проект с нуля, или же попытаться внести
необходимые правки в уже существующий код. Но сама возможность
восстановить читаемый и поддерживаемый исходный код почти всегда
сохраняется. Выбор решения должен определяться временными рамками
выбранной стратегии и стоимости работ, которые зависят от сложности
изначального проекта, выбранного ЯП (языка программирования) и
платформы (не только конкретная ОС - операционная система, но и
архитектура - то есть какой процессор, сопроцессор, виртуальная машина
или микроконтроллер исполняет бинарный код - код полученный как
конечный продукт из исходных кодов).

Какое основное отличие между исходными кодами и

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

Исходные коды (фрагмент):

void function1(void *param) {
// do work
function2(param, 1);
...
}

Бинарный (машинный) код:

40 5F 7A 80 17 D3 ...

Совершенно очевидно, что читаемость первого варианта выше. Второй

просто набор шестнадцатеричных цифр. Пример абстрактен. Бывают
разные ситуации, разные архитектуры и платформы кода. Для машинных
кодов может существовать в тех или иных случаях автоматизированные
системы интерпретации в мнемокоде (ассемблеры) или даже в
приближенном к исходному к ЯП виде (например, Java, .NET). Но почти
никогда не остается комментариев, редко остаются именования
внутренних объектов. Иногда интерпретация невероятна сложна даже на
читаемом альтернативном представлении. И уже совсем сложно
 развивать и продолжать, вносить правки в уже готовый продукт. Даже ЯП
для которых существуют автоматические декомпиляторы, такие как Java/
C#, если мы опустим ряд мер по обфускации (затруднению реверс-
инженерии) кода, которых может и не было сделано, не дает исходного
варианта кода. Они не способны восстановить комментарии (их не
остается почти ни в одном языке - хотя есть исключения), они не
справляются с кодом, создаваемым в процессе работы компилятора
(средства по изготовлению конечного или промежуточного продукта из
исходных кодов) - CompilerGenerated блоки даже нельзя снова
скомпилировать (надо выяснить, что было в коде, что заставило
компилятор поменять код на другой, еще до перевода в машинный язык).

Безусловно есть и такие гуру, которые могут почти спокойно читать

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

Реверс-инженерия с целью оптимизации может помочь выявить

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

Как происходит оценка задачи, ее выполнимости, трудовых затрат и стоимости

Для начала требуется оценить конкретику задачи, и это прежде всего
определение типа работ. Реверс-инженерия может быть программной,
аппаратно-программной или только аппаратной. Аппаратная требует
всегда хорошего и опытного специалиста-инженера, как правило КИП-
овца с навыками реверс-инженерии, навыками ремонта бытовой и
промышленной аппаратуры и отличными знаниями в микроэлектронике и
смежных областях. Это всегда дорогие и сложные проекты, наукоемкие,
рентабельность обычно актуальна для крупных промышленных задач.
Дефицит кадров в этой области, к сожалению наиболее высокий. Далее
по популярности задач идут программные продукты и следом смежные
задачи - АПК. При изучении АПК все сводится к определению аппаратных
барьеров, преодоление которых отделяет исследователей от прошивки
комплекса (микропрограммы управления техническим процессом).
Программная реверс-инженерия сначала определяет тип архитектуры и
 платформы, исследует совместно с заказчиков и обозначает конкретную
цель, требующую изучения. Сложности создают обфускации,
использование ненативных ЯП (нативные программы - исполняющиеся на
процессоре/микроконтроллере физически, а не под управлением
виртуального процессора, программный код которого уже исполняется
сам на процессоре физическом, виртуализация может быть в
несколько слоев) и комбинации разных ЯП и архитектур в одном
продукте. Мы помогаем определить ТЗ (техническое задание) для каждого
конкретного случая, первый этап изучения черновой, включает
ориентировочные сроки решения задачи, ее сложность и рентабельность
всей затеи. Второй этап включает уже первичный анализ и выставление
КП (коммерческое предложение). Диагностики проблемы и первичный
анализ могут быть как платной услугой, так и не имеющей стоимости. Мы
идем на встречу, чтобы риск-менеджмент лучше представлял себе эту
работу и смог оценить ее финальное качество (не в полной мере - об этом
ниже). Если диагностика проблемы сама по себе представляет сложный
процесс (особенно в случаях намеренно затрудненного анализа со
стороны разработчиков и инженеров, а также в случае АПК и чисто
аппаратных комплексов), такая услуга по вынужденным причинам уже
имеет стоимость.

Важно понимать, что в силу специфики процесса реверс-инженерии,

качество примера работы может быть определено не в полной мере -
хороший пример работы, например, в виде фрагмента кода, требует
анализа такого уровня, какой по сложности определяет до 80%
сложности всей работы. Пример. Если в некотором алгоритме
переменной X задается значение 5, это неинформативно. 5 рабочих дней
в неделю? 5 пальцев на руке? Что имел в виду разработчик? Далее
выясняется, что этот алгоритм отвечает за криптографические
манипуляции, и число 5 выбрано публичной экспонентой алгоритма RSA.
Логично, что переменную X следует назвать public_exp, а функцию где ей
задается значение 5 (если это ее единственный или самы значимый
фрагмент), например, как setRSAPublicExponent.

Какие работы уже были проделаны

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

* работа по изучению и отладке медицинского и косметологического

оборудования

* исследование и разработка ПО для задач геодезии и аудит/ремонт

оборудования для геодезических работ

* исследование автомобилей, промышленных станков и линий, аудит

безопасности, диагностика и исправление неисправностей,
восстановление работы после сбоев
* исследование компьютерных игр, создание серверов для сетевой игры,
проекты на основе частных серверов

* исследование ПО работающего с компьютерной графикой (CG/CGI),

видео и аудио транскодеры, фильтры, потоковые форматы

* восстановление исходных кодов для малых (модули измеряемые в

килобайтах - до 500 КБ) и больших программных продуктов (10-ки
мегабайт реального кода)

* импортозамещение, включая такие тонкие проблемы как продление

незаконно отозванных лицензий у правовых пользователей, адаптация
оборудования, не предназначенного для работы на территории РФ,
изучение проприетарных (закрытых) протоколов работы ПО/АПК для
адаптации оборудования и ПО, и переключению к работе с другим
оборудованием и ПО, не предназначенным изначально для этого
(замена элементов сложных логических цепей в комплексах на
отечественные или даже собственного производства - как
самостоятельная услуга или совместная работа с заказчиком)

В последнем пункте не раскрываются конкретные примеры ПО и АПК в

силу ряда причин, обозначенных выше.

С уважением,

команда компании Название компании