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

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

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

Основные стратегии защиты

Едва ли не самое простое, что приходит в голову, это привязать программу к конечному пользователю, который её покупает. Это годится и для сравнительно небольших утилит, которые стоят порядка двадцати долларов, и для более серьёзных продуктов, которые имеют более высокую стоимость. По имени пользователя (или каким-то другим его данным, таким, как телефон, адрес электронной почты, девичья фамилия матери) генерируется серийный номер, который пользователь должен получить в обмен на некоторое количество "условно зелёных". Решение, изящное в своей простоте, однако сталкивающееся с одной существенной проблемой: никто не может помешать пользователю ввести свои данные для регистрации не одной, а ста копий программы (скажем, в своём офисе) или послать эти регистрационные данные другу, а то и вовсе опубликовать их на каком-нибудь "варезнике"¹. Каким образом можно защититься от подобных действий пользователя? Здесь мы приходим к ещё двум стратегиям защиты.

Первая из них заключается в том, чтобы привязать программу не столько к самому пользователю, сколько к его компьютеру. Для этого используется вместо или вместе с именем пользователя ещё один вспомогательный (активационный) код, который генерируется исходя из особенностей "железа" и операционной системы покупателя программы. Этот код отсылается им продавцу вместе с деньгами, и уже исходя из этого кода генерируется и регистрационный номер, высылаемый пользователю. Всё, вроде бы, в ажуре, но что будет, если пользователь поменяет какой-то из компонентов системы, по которому вычисляется активационный код? Правильно: регистрационный код перестанет соответствовать активационному, и программа перестаёт быть купленной. Нужно ли пользователю покупать программу по-новому? Здесь каждый разработчик, что называется, как хочет, так и вертит. Хотя с большинством можно договориться насчёт получения нового ключа бесплатно.

Ещё один вариант защиты от распространения ключей в Интернете - это онлайновая активация продукта. Когда пользователь вводит регистрационный ключ, программа лезет на сайт разработчика и проверяет, есть ли этот ключ в базе данных. Если его там нет, то всё хорошо, и программа просто добавляет ещё один ключ в базу. Если есть, то... Как говорят французы, c'est la vie. Здесь, правда, тоже есть свои подводные камни: без доступа к Интернету программу не зарегистрируешь. Сейчас это, конечно, перестало быть такой серьёзной проблемой, как некоторое время назад, но, например, если программу, пытающуюся достучаться до сервера активации, не пропускает файрвол, настроенный администратором локальной сети, то пользователь вспомнит создателя программы не одним добрым словом, пока разыщет администратора, пока с ним договорится и пока зарегистрируется. Если вообще не передумает регистрироваться.

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

Техника защиты

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

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

Что касается первой половины задачи, то здесь всё достаточно просто (на словах, конечно, а не на деле): тот участок программного кода, который отвечает за проверку правильности ключа (то есть, фактически, за генерацию нового и сравнение введённого пользователем значения с эталоном) шифруется. Шифруется, конечно, по-разному в разных продуктах: в одних будет достаточно обычного XOR'а, в других не хватит и AES. Помимо защиты от создателей генераторов ключей, шифрование защищает и от менее "джентльменских" способов взлома - например, от патчей. Конечно, при желании можно сделать патч и для зашифрованного кода, но, согласитесь, это сложнее, чем просто поменять местами пару команд под отладчиком, а потом выпустить программу, делающую то же самое, только автоматически.

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

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

Резюме

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

Для того, чтобы разобраться в защите программ, порекомендую, в первую очередь, статьи на сайте www.dotfix.net. Они там, конечно, не самые новые, однако с их помощью можно понять, как проверять целостность файла по контрольной сумме, какие основные ошибки допускают начинающие разработчики защит и многое другое. Конечно, в Сети можно найти гораздо больше статей по данной теме, чем предлагает этот сайт - как говорится, Google вам в руки!

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

Вадим СТАНКЕВИЧ,
[email protected]

1 От "хакерского" warez - видоизменённого слова software. "Варезниками" называют сайты, с которых можно скачать массу полезных программ вместе со взломами. Взломщики, как правило, делятся ими с пользователями совершенно безвозмездно.