Защита разработанного бессонными ночами собственного программного продукта... Сколько программистов, уставших работать "на дядю" и решившихся попробовать свои силы в создании собственного коммерческого программного продукта, сталкивались с этой задачей... Как решать её сегодня?

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

Немного философии

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

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

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

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

Общая теория защиты

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

Регистрация и активация

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

Программные ключи могут быть как просто какими-то сгенерированными по известному одному разработчику (в идеале; в реальности еще и взломщику) алгоритму последовательностями символов (что-то наподобие FI2W38-DNFUE3NF-W432DS-3FDFKJ-34DGF3), так и настоящими открытыми криптографическими ключами различной длины. Использование криптографических ключей для регистрации продукта обусловлено особенностями реализации системы защиты от взлома, в которой как раз достаточно удобно использовать шифрование. Длинные ключи обычно пересылаются пользователю в виде файлов, которые, по традиции, называются LIC-файлами (сокращение от license).

Для выдачи пользователю ключа его нужно каким-то образом "привязать" к данному конкретному покупателю вашего программного продукта. Привязку можно осуществлять либо к каким-то личным данным пользователя (для организации - к названию), либо, скажем, к e-mail'у, на который при покупке программы высылается ключ. Но это, скажем прямо, не самые надежные методы привязки, потому что никто не мешает Джону Смиту назваться Васей Ивановым и выложить от избытка альтруизма в Интернет ключ, купленный им за деньги с украденной через все тот же Интернет кредитки. Поэтому достаточно многие разработчики предпочитают использовать привязку ключа к аппаратной "начинке" компьютера. Иногда для этого используются буквально все возможные параметры, начиная с серийного номера "винчестера" и заканчивая номером Service Pack'а для Windows, иногда же разработчики ограничиваются MAC-адресом сетевой карты. С учетом того, что сейчас для большинства компьютеров сетевая карта интегрирована в материнскую плату, можно считать, что её MAC-адрес в достаточной степени позволяет идентифицировать данный компьютер среди множества его железных "собратьев" и при этом избавляет пользователя от необходимости просить у разработчика обновленный ключ при замене винчестера или установке следующего "сервис-пака".

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

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

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