Защита программ от взлома

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

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

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


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

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

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

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

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


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

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

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

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

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

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


Резюме

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

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

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

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by


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

Версия для печатиВерсия для печати

Номер: 

06 за 2009 год

Рубрика: 

Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Комментарии

Страницы

Аватар пользователя mike
>зарегю я сотню ников...

Да-да, и компы меняй.

Аватар пользователя mike
И ещё одна особенность иксов. Они никогда реально не помогут. Мне помогли многие, среди них - Savely, Питон и другие, но только не иксы.
Аватар пользователя Инкогнито
>>Они никогда реально не помогут

Майк, я стараюсь. Но тебе уже не помочь.

>>Старикам форума, имелось в виду. Ну, Инет-возраст у меня достаточный, лет 10. Это просто опыт

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

Аватар пользователя Savely
>Не пора ли кончить попытки кого-то построить по своему разумению

Нет. Переустройство окружающей меня среды (а так же понедельника, вторника и т.п.) по своему разумению - есть моя основная жизненная задача. :-)

>Вон у Вас сабж есть...

А что такое сабж, по-Вашему? :))

Аватар пользователя Инкогнито
>>А что такое сабж, по-Вашему?

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

Аватар пользователя Инкогнито
И специально для "Ушаков Александр".

>>статьи от Станкевича всегда на должном уровне

Ошибка. Не всегда. На форуме КВ уже не раз это обсуждалось.

>>комменты всяких м@даков игнорировать

Потренируйтесь на родителях: они не всегда говорят приятное Вам лично.

>>Станкевич пишет около 60- 70% всех статей в газете, это тоже стоит учитывать

Боюсь, что главред не понимает ужаса этих цифр. Но ему виднее.

Аватар пользователя Savely
Если Вам незачем - не читайте. И тем более - не отвечайте. :-) А границы оффтопика определит модератор.
Аватар пользователя 93
Станкевич, вероятно, штатный журналист, наверно работает в редакции, поэтому и пишет так много статей.
Аватар пользователя Инкогнито
>>тем более - не отвечайте. :-) А границы оффтопика определит модератор

Так зачем отвечали?

Аватар пользователя Savely
> Так зачем отвечали?

Это кто? Новый Инкогнито? Или еще старый?

Страницы