Shareware

Часть II: Защита программы

В прошлой части мы рассмотрели процесс создания программы, которую сейчас начнем превращать в полноценный shareware-продукт. В этой части мы займемся защитой.

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

По моему глубокому убеждению, защита shareware-продукта должна выполнить две основные функции:

"подтолкнуть" пользователя к покупке программы;
не допустить снятие ограничений без оплаты регистрации;

За первую функцию защиты целиком и полностью отвечают ограничения, накладываемые разработчиком на незарегистрированного пользователя. Сейчас среди shareware-разработчиков популярны следующие ограничения:

Ограничение времени работы программы

Суть этого ограничения можно изложить таким образом: программа дает возможность тестировать себя только в течение некоторого периода, который исчисляется либо в днях, либо в запусках. Ассоциация профессионалов shareware (ASP, www.asp-shareware.org) рекомендует использовать 30-дневный испытательный срок.

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

Ограничение функциональности

Данное ограничение не дает доступ пользователю ко всем возможностям программы. Это выражается в том, что некоторые функции работают только частично либо не работают вообще. Например, пользователю в самых искренних выражениях может рассказываться, что программа имеет некую крутую "фичу", но эта "фича" будет работать только после оплаты регистрации. А может случиться и другое: пользователь скачал, скажем, классную программу для назначения горячих клавиш на всякие действия, сделал одну комбинацию на выключение компьютера, вторую - на перезагрузку, третью - на запуск Winamp'a, делает четвертую... и тут бац!.. вылазит сообщение, что для того, чтобы опробовать программу, четвертая комбинация вовсе не обязательна и доступна будет только в зарегистрированной версии.

Nag-screen

"Экран ворчания" время от времени появляется перед пользователем и напоминает о том, что данная копия не зарегистрирована, и объясняет, как и за сколько можно это упущение исправить. Следуют заметить, что на некоторых soft-каталогах не принимаются программы, которые показывают nag-screen (например, www.NoNags.com).

Теперь перейдем ко второй функции защиты: не допустить снятие ограничений без оплаты регистрации.

Через некоторое время после появления shareware-программы в популярных soft-каталогах на нее обязательно обращает свой взор какой-нибудь "крякер". Именно "крякеры" занимаются взломом программ, и, не будучи эгоистами, дают всем желающим возможность бесплатно пользоваться взломанной ими программой. Так вот, после попадания shareware-продукта в руки "крякера" через день-два "кряк" (продукт деятельности "крякера") к программе будет распространен по всему интернету. Так случилось и с моей пробной "софтиной": через неделю после ее появления в мировой паутине мне любезно сообщили, что "крякерская" группа ORiON сделала к моей замечательной программе не менее замечательный keygen (это такая штука, которая генерирует регистрационный код). Сразу после этого события посещаемость моего сайта возросла в десятки раз. И вот тут-то я всерьез пожалел, что не уделил должного внимания защите...

Ну а теперь давайте посмотрим, как же "крякеры" ломают shareware-программы.

Во многих shareware-продуктах, чтобы зарегистрироваться, нужно ввести имя пользователя и пароль. При этом программы довольно часто по имени пользователя генерируют пароль и сравнивают его с введенным. Такая защита - просто находка для "крякера", потому что код для генерации пароля можно просто вырезать из программы и сделать на его основе keygen. А еще можно при помощи отладчика "поймать" момент, когда сравниваются два пароля, и посмотреть на верный пароль.
Если сделать keygen для "крякера" проблематично, то далее следует попытка подобрать регистрационный код хотя бы для своего имени. Для этого при помощи отладчика "крякер" смотрит, каким условиям должен удовлетворять пароль для программы, после чего "крякеру" останется "подогнать" пароль под эти условия и поместить связку "имя_крякера + пароль" в интернете. И через некоторое время в разделе "О программе..." у некоторого числа пользователей будет красоваться имя "крякера", ради чего, в принципе, все это дело и затевалось.
Если же пароль подобрать не получается, приходится заниматься изменением самой программы. Эти изменения, как правило, направлены на то, чтобы программа постоянно считала себя зарегистрированной. Например, при запуске программа проверяет регистрационный код, хранящийся в файле key.reg. Если этот код существует и он правильный, то переменной IsReg присваивается значение "Истина", иначе - значение "Ложь". А умный "крякер", внимательно изучив эту схему, взял и изменил программу так, что переменная IsReg в любом случае будет хранить значение "Истина". После чего эта программа будет работать так же, как и зарегистрированная.
Разумеется, не все программы можно "сломать" без особых усилий и, конечно же, не все "крякеры" одинаково хороши, поэтому иногда делается попытка снять хотя бы некоторые ограничения с программы. Например, ограничение по времени в абсолютном большинстве случаев может обойти практически любой пользователь. Для этого понадобятся только программы для слежения за обращениями к реестру и к файлам. Вполне подойдут бесплатные утилиты File Monitor и Registry Monitor (взять их можно на www.sysinternals.com). Эти мониторы должны быть запущены перед первым запуском программы, чтобы оперативно нам сообщать, где она "наследила". Ну а дальнейшие действия целиком и полностью зависят от квалификации пользователя: можно просто удалять время от времени эти "следы" либо потрудиться и "пропатчить" программу, чтобы она и не думала о прекращении работы. В итоге программой можно пользоваться бесконечно долго, хотя и не совсем легально. Также можно попытаться запретить появление "экрана ворчания". Для этого в отладчике ищем вызовы этого вредного окна и делаем необходимые изменения в программе.

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

Храните дату первого запуска (или количество запусков) в неочевидном формате. А сам файл-хранилище должен быть достаточно "популярным", чтобы ваше обращение к файлу затерялось среди чужих.
Если вы проверяете срок использования программы примерно так: "Текущая_Дата - Начальная_Дата < 30 дней", то считайте абсолютные значения, чтобы нельзя было перевести дату далеко назад и бесплатно пользоваться программой: "|Текущая_Дата - Начальная_Дата| < 30 дней".
Не генерируйте правильный пароль в своей программе, чтобы уменьшить возможность создания keygen'a.
Проверяйте CRC (Cyclic Redundancy Code - "циклический избыточный код") всех связанных с защитой файлов. Это делается для того, чтобы можно было обнаружить попытки изменения этих файлов. Если вкратце, то CRC вычисляется так: весь файл представляется в виде последовательности бит, которая делится на некоторое число. Остаток после деления и есть CRC. Но, разумеется, работать с битами напрямую довольно не рационально, поэтому придумано много способов для быстрого вычисления CRC. Про эти способы можно почитать в статье huizen.dds.nl/-noway66/programming/crc.htm.
Проверяйте, зарегистрирована ли программа, не только при ее запуске, но и во время работы. С таким подходом "крякеру" будет сложнее "пропатчить" программу, т.е. изменить ее таким образом, чтобы она безо всякой регистрации работала так же, как и легальная копия.
Используйте несколько ступеней проверки регистрационных кодов. Например, так: если первые три цифры кода дают в сумме простое число, то переходим к следующему уровню контроля - число, составленное из последних двух цифр, должно быть совершенным... При этом не используйте все уровни проверки сразу, т.е., скажем, по нечетным дням делайте первую проверку, а по четным - вторую. Это дает "крякеру" возможность за один день преодолеть только один уровень контроля. Конечно, "крякеры" - тоже не дураки, а потому очень часто после взлома очередной программы они изменяют дату на своем компьютере и смотрят, будет ли работать "жертва" после этого. Если нам повезет, и дата изменится на четное количество дней, то второй уровень защиты останется незамеченным (конечно, при условии, что он не был обнаружен ранее в отладчике или дизассемблере). Также несколько уровней защиты подходят для тех разработчиков, у которых регистрация на программу должна действовать в течение нескольких последующих версий (т.е. если пользователь купил версию 1.1, то все версии программы до 2.0 предоставляются ему бесплатно). Таким образом, можно в версии 1.0 использовать только один уровень защиты, в 1.1 - два и т.д., при этом отпадает необходимость рассылать новые пароли старым пользователям.
Не стоит проверять дату при помощи стандартных функций, ведь, как ни странно, "крякеры" умеют изменять системную дату... Лучше проверять ее по дате изменения какого-нибудь часто изменяемого системного файла (вполне подойдут файлы реестра).
Не показывайте "крякерам", какие функции в программе отвечают за защиту, т.е. не нужно давать им [функциям] названия типа "IsRegCodeValid".
Даже при успешной регистрации пользователя все равно нужно хотя бы при каждом запуске проверять регистрационный код. Т.е., когда пользователь ввел пароль, сохраните его в каком-нибудь файле, а затем постоянно проверяйте его. Некоторые программы действуют иначе: после регистрации программа ставит где-нибудь в системе метку, что пользователь зарегистрировался. В таком случае "крякеру" проще написать программу, которая сама ставит такую метку, чем пытаться подобрать пароль.
После ввода регистрационного кода делайте небольшую паузу, чтобы исключить возможность подбора пароля при помощи перебора.
Проводите "отвлекающие маневры": используйте полученный от пользователя регистрационный код в функциях с названиями типа "RegCheck", храните где-нибудь параметр "FirstDate=16.08.2003", сравнивайте друг с другом различные переменные и т.д.

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

Иван ШИРКО,
FDC@tut.by