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

Краткое содержание предыдущих серий

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

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

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

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

Как действует взломщик

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

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

Для программных продуктов, ограничивающих время пользования своей пробной версией, взломщики зачастую модифицируют создаваемую продуктом пометку о старте испытательного срока, продляя его с обычных 30 до 100500 дней. Нужно, впрочем, заметить, что это сегодня делают реже, чем "патчи", убирающие ограничение испытательного срока, поскольку даже его продление практически до бесконечности не избавляет пользователей от лицезрения nag screen'ов, настойчиво напоминающих о необходимости приобрести лицензионную копию понравившегося им программного продукта. Но, тем не менее, метки в реестре или в файлах "вычисляются" взломщиками с помощью замечательных программ Registry Monitor (RegMon) и File Monitor (FileMon) и затем старательно подправляются. Справедливости ради надо сказать, что эти программы помогают взломщикам и в сборе другой нужной им информации о приложениях, но, думаю, мы еще поговорим о них достаточно подробно дальше.

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

Как действует "антивзлом"

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

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

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

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

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