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

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

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

Существует распространённое мнение о том, что защищать программы якобы бессмысленно. В тех странах, где уровень жизни низок, их никто купить просто не сможет, а в тех, где высок, - не захочет пользоваться взломанным, то есть, фактически, украденным продуктом. На самом деле всё обстоит несколько иначе, и потому исследования, проводимые различными компаниями, занимающимися продажей софта (например, широко известной 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!
 

Комментарии

Страницы

Аватар пользователя Леонид
Статья Станкевича, обсуждаемая тут, годится разве что для издания "Компьютерные вести для первоклассников" - если бы такая газета издавалась. А в целом по изданию подобные опусы только понижают общий уровень.
Аватар пользователя Вадим Станкевич
Леонид, может, будут какие-то конкретные предложения по улучшению статьи?
Аватар пользователя Леонид
Консультации денег стоят. А я не нанимался улучшать газету и поднимать уровень писателей-плагиаторов. Если Станкевич не способен писать лучше - пусть пишет в более нетребовательное к качеству статей место. А на его место придут другие. Естественный отбор никто не отменял.
Аватар пользователя Al
Леонид, а к то сказал, что КВ - это только для профи? В конце концов, профи на самом деле учатся не по КВ, однозначно. :) А для тех, кто хочет начать, кто хочет учиться, статья - само то. А мы здесь обуждаем прфессионализЬм автора, а не качество статьи, похоже. Так что, Леонид, ты не прав!

Это одно. Второе: критика без советов - удел светловолосых представителей прекрасного пола. Не нравится - скажи об этом. И по возможности укажи путь во мраке.

Аватар пользователя Инкогнито
Почему кто-то должен Станкевичу указывать путь во мраке? Тем более если этого не делает главный редактор. Пусть во мраке и остается. небось не заскучает - в компании с майком-то....
Аватар пользователя Al
Потому что на форумах сидят неравнодушные люди. Пофигисты до сих пор сидят в пещерах или тянутся в хвосте очереди за лучшей жизнью. :)

А главный редактор тоже может быть пофигистом. Или у него своих проблем хватает. Мне пофиг. :) Но помогать людям надо, если есть возможность и средства.

Аватар пользователя Инкогнито
>>Но помогать людям надо, если есть возможность и средства.

Правильно. Но разве это уже не помощь -- просто сказать: "Аффтар, ты ВО МРАКЕ, редактор, твой аффтор во мраке (дескать, крутитесь как хотите, но похороны завтра в 12)"? Крутиться -- их проблема.

>>критика без советов - удел светловолосых представителей прекрасного пола

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

Страницы