Защита приложений

 МИХАИЛ УШАКОВ, разработчик электронной аппаратуры и программного обеспечения для ядерной гамма-резонансной спектроскопии, Уральский федеральный университет, um.nix.user@gmail.com

Защита приложений

Как защитить программный код? Этому не учат на университетских курсах. Однако эта задача рано или поздно встает перед любым разработчиком!

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

Можно выделить два основных направления: защита программ от несанкционированной установки/копирования и защита исходного кода приложений и библиотек от кражи/копирования.

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

Существует достаточно большой набор коммерческих решений для защиты программ, например, StarForce, система защиты DVD CSS, система защиты Blu-ray дисков Advanced Access Content System, привязка к электронному ключу HASP и другие. Готовые решения позволяют относительно быстро вывести продукт на рынок, но в большинстве случаев их использование имеет ряд недостатков:

• Популярные готовые решения, вероятно, были неоднократно взломаны при снятии лицензии с программных продуктов, поэтому набор их защитных механизмов хорошо известен специалистам по взлому.
• Использование DRM-продуктов (Digital Rights/Restrictions Management), приводящих к модификации PE-файлов (про ELF мы говорить не будем, поскольку по понятным причинам механизмы защиты не получили широкого распространения в мире Linux), и динамических библиотек автоматически приводит к увеличению числа ошибок в программе за счет ошибок в DRM-модуле (см. [1]).
• Механизмы DRM нарушают права пользователей и ограничивают их свободы. Ричард Столлман в книге «Право читать» так охарактеризовал DRM: «…DRM is an example of a malicious feature – a feature designed to hurt the user of the software, and therefore, it’s something for which there can never be toleration…» («...DRM – пример вредоносного ПО. Оно призвано нанести вред пользователю, и, таким образом, с его существованием нельзя мириться ни при каких обстоятельствах».) DRM также может нарушить работу других программ, что негативно скажется на репутации защищаемого программного продукта.

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

Это:

• Использование обфусцированного кода в библиотеках и программах и минимальной защиты лицензией, то есть такой защиты, которая позволит оградить продукт от копирования опытными пользователями.
• Если планируется распространять демо-версию программы, то в ней должна быть удалена функциональность, которая будет в полной версии программы.
• Использование приложения как сервиса на сервере приложений (например, JBoss Geronimo и т.д.) с предоставлением доступа через, например, тонкий клиент или REST API (см. рис. 1).

Рисунок 1. Современный подход: использование приложения как сервиса

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

Если программа не имеет никакой защиты...

Компиляция программ, написанных на управляемых языках, таких как С#, Java и им подобных, происходит дважды: в промежуточный код (байт-код Java или MSIL для платформы NET) и в машинные инструкции (последнее не обязательно).

Для того чтобы JIT (just in time compilation) смог правильно обработать сгенерированный код, компилятор генерирует метаданные для описания интерфейсов, классов и методов. Без наличия метаданных компиляция байт-кода или MSIL-инструкций невозможна.

Работа с метаданными производится через пространство имен System.Reflection в .NET (начиная с версии 1.1) или через пакет java.lang.reflect в Java.

Статью целиком читайте в журнале «Системный администратор», №12 за 2013 г. на страницах 86-91.

Комментарии могут оставлять только зарегистрированные пользователи