<< Предыдущая

стр. 16
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

рого периода времени.
По истечении тестового периода потенциальный покупатель должен при-
нять решение о приобретении программы. Если решено отказаться от по-
купки, то надо прекратить использовать программу и удалить ее с компью-
тера. В противном случае, необходимо оплатить лицензию на программу,
после чего продавец предоставит возможность получения полнофункцио-
нальной версии программы.
Обычно условно бесплатные программы доставляются через Интернет и
имеют небольшой размер (единицы мегабайтов). Также очень часто для
превращения ограниченной версии в полнофункциональную не требуются
никакие дополнительные файлы — достаточно ввести правильный регист-
рационный код, полученный от продавца.
На период бесплатного использования накладываются ограничения, схо-
жие с ограничениями на оценочные версии коммерческих программных
продуктов. Точные ограничения оценочного периода, как правило, оговари-
ваются в лицензионном соглашении на использование каждого конкретного
продукта.
Условно бесплатные продукты очень популярны. Многие крупные разработ-
чики берут на вооружение концепцию "try before you buy", чтобы заинтере-
совать покупателей. По сути, ограниченные ознакомительные версии ком-
мерческих продуктов являются всего лишь одной из модификаций идеи
Shareware. Даже корпорация Microsoft бесплатно распространяет 120-дневные
версии Windows 2003 Server и Visual Studio .NET. Правда, небольшое отли-
чие заключается в том, что для превращения 120-дневной версии в полно-
Ценную придется получить диск с новой версией и выполнить процедуру
обновления, а для "классических" условно бесплатных программ переход
к полной версии происходит сразу же после ввода правильного регистраци-
онного кода.
104 Часть III. Как не надо защищать программы


9.2. От чего защищают программы
Коммерческие программы обычно защищают от несанкционированного ти-
ражирования.
Наличие доступа только к носителю информации с дистрибутивом (набором
инсталляционных файлов) программного продукта не должно давать воз-
можности установить работоспособную копию программы. То есть данных
дистрибутива, который можно скопировать или незаметно взять на несколь-
ко дней, не должно хватать для создания работоспособной копии програм-
мы. Подобные ограничения могут быть реализованы разными способами.
Например, очень многие коммерческие программы при инсталляции требу-
ют ввести серийный номер, напечатанный на коробке или указанный в од-
ном из прилагаемых к программному продукту документов (у Microsoft — |
в сертификате аутентичности). |
Также часто возникает потребность ограничить число пользователей, одновре-
менно работающих с программой. То есть человек, который приобрел лицен-
зию на одно рабочее место, не должен иметь возможности создать 2 рабочих
места, функционирующих одновременно. Это достигается за счет использова-
ния аппаратных ключей, менеджеров лицензий и процедуры активации.
Для некоторых программных продуктов (в частности игр) часто использует-
ся привязка к носителю информации, например компакт-диску. То есть для
запуска игры требуется наличие в приводе оригинального компакт-диска,
который защищен от копирования стандартными средствами.
Для оценочных версий, ограниченных по времени или числу запусков, не-
обходимо правильно реализовать хранение счетчиков, чтобы злоумышлен-
ник не смог заставить работать программу, просто переведя часы или удалив
файл, в который записывается количество запусков программы или число
обработанных файлов.
Условно бесплатные продукты, в отличие от ограниченных по функ-
циональности оценочных версий коммерческих программ, после ввода
регистрационного кода должны предоставлять доступ ко всем функциям,
предусмотренным в полной версии программы. То есть в бесплатно распро-
страняемой версии программы должны быть реализованы все функции полной
версии. Следовательно, желательно так организовать защиту, чтобы зло-
умышленник не смог добраться до функций, присущих только полной вер-4
сии, пока в его распоряжении не будет правильного регистрационного кода.!
Процедуры проверки правильности серийных номеров, а также регистраци-*
онных кодов и кодов активации должны строиться таким образом, чтобы
злоумышленник не мог самостоятельно генерировать правильные коды и,
в то же время, длина кодовой строки не была очень большой.
Глава 9. Актуальные задачи защиты программ 105

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


9.3. Основные форматы
исполняемых файлов
За время существования персональных компьютеров на процессорах семей-
ства х86 (начиная от IBM PC XT на процессоре Intel 8086) успело смениться
несколько форматов двоичных файлов, предназначенных для хранения от-
компилированного кода программы.
В операционной системе DOS (Disk Operating System) поддерживалось два
основных формата исполняемых файлов: СОМ и ЕХЕ. СОМ-файлы загру-
жались в оперативную память без каких-либо дополнительных настроек, и
их размер не должен был превышать 64 Кбайта. ЕХЕ-файлы не имели таких
жестких ограничений на размер и состояли из заголовка, включающего всю
необходимую информацию для правильной загрузки программы в память, и
собственно кода программы. Заголовок DOS-овских ЕХЕ-файлов начинался
с символов 'MZ' или 'ZM', и до сих пор его так и называют — MZ Header
(MZ-заголовок). Буквы MZ являются инициалами Марка Збыковски (Mark
Zbikowski), являвшегося разработчиком данного формата. Сейчас все испол-
няемые файлы содержат MZ-заголовок, за которым может следовать ин-
формация о другом формате.
С появлением 16-битовой версии Windows возникла потребность в расши-
ренном формате исполняемых файлов. В Windows была реализована под-
держка динамически подсоединяемых библиотек (dynamic-link library. DLL),
поэтому новый формат должен был обеспечить возможность хранения,
в частности, таблиц экспортируемых (находящихся в DLL и доступных
Другим модулям) и импортируемых (находящихся во внешних библиотеках)
функций. Кроме этого в Windows широко используются ресурсы — двоич-
ные данные, содержащие иконки, курсоры, описания диалогов и т. д., кото-
рые желательно хранить внутри исполняемых файлов. Все актуальные на тот
Момент требования были учтены при разработке формата, получившего на-
звание New Executable (NE, новый исполняемый файл). Заголовок такого
файла начинается с символов 'NE'.
Для хранения драйверов виртуальных устройств Windows (Virtual device
driver, VxD) применялся формат Linear Executable (LE, линейный исполняе-
мый файл). Его модификация под названием Linear executable (LX) исполь-
зовалась для хранения исполняемых файлов, используемых в операционной
системе OS/2 начиная с версии 2.0.
106 Часть III. Как не надо защищать программы

В связи с появлением 32-битовой операционной системы Windows NT
в Microsoft был разработан формат Portable Executable (РЕ, переносимый
исполняемый файл). Точнее, был доработан до своих нужд взятый за прото-
тип формат объектных файлов COFF (Common Object File Format), исполь-
зуемый в Unix. Слово "переносимый" в названии, скорее всего, было при-
звано отражать тот факт, что один и тот же формат файла использовался как
во всех 32-битовых операционных системах Microsoft на платформе х8б, так
и в Windows NT на других платформах (MIPS, Alpha и Power PC). Этот
формат является основным для всех современных версий Windows, и имен-
но ему в книге будет уделено наибольшее внимание.


9.4. Особенности внутреннего устройства
исполняемых файлов
в 32-битовых версиях Windows
Не вдаваясь слишком глубоко в детали формата Portable Executable, отметим
только те элементы, которые наиболее часто подвергаются воздействию
в процессе защиты.
Заголовок РЕ-файла содержит очень большое число различных полей и таб-
лиц. Одно из полей определяет так называемую точку входа (Entry Point) —
то место в программе, куда будет передано управление после загрузки про-
граммы в память. В DLL управление передается на точку входа не только
при загрузке библиотеки, но и при ее выгрузке из памяти, а также при соз-
дании и уничтожении потоков выполнения внутри программы.
Обычно исполняемый файл состоит из нескольких секций (точное количест-
во секций указано в РЕ-заголовке). Редактор связей (Linker), как правило,
объединяет в одну секцию однотипную информацию.
Типичный исполняемый файл содержит секции кода, статических и дина-
мических данных и секцию ресурсов. Каждая секция описывается именем,
размером и положением в файле и в памяти, а также набором атрибутов
(двоичных флагов): код или данные в секции, данные инициализированы
или нет, разрешено ли исполнение, чтение или запись и т. д.
В секции кода помещаются собственно команды процессора, исполняемые
в ходе работы программы. Эта секция имеет атрибуты, разрешающие испол-
нение кода и запрещающие запись.
Статические данные не изменяются после загрузки программы в память.
поэтому для секции статических данных обычно не устанавливается атрибут.
разрешающий запись. Попытка записи в эту секцию в момент выполнения
Глава 9. Актуальные задачи защиты программ 107


программы приведет к выработке исключительной ситуации (exception).
Атрибуты секции динамических данных, напротив, разрешают запись в нее.
Секция ресурсов также не должна изменяться в процессе выполнения про-
граммы, и поэтому она не имеет атрибута, разрешающего запись.
Разумеется, выше была приведена лишь одна из возможных схем разбиения
содержимого исполняемого файла по секциям, и каждое средство разработ-
ки, создающее РЕ-файльг, вправе самостоятельно решать, какая информа-
ция в какой секции окажется. Более того, вся программа может размещаться
в одной секции и быть при этом вполне работоспособной.
Кроме описания секций в заголовке РЕ-файла присутствует специальный
каталог (РЕ Directory), описывающий размер и положение служебных
структур, необходимых для правильной загрузки программы в память. Эти
структуры определяют, в каком месте программы хранятся ресурсы, как ис-
кать адреса экспортируемых функций, как настраивать ссылки на импорти-
руемые функции и т. д.


Каталог импорта


Запись для DLL1
Запись для DLL 2


Запись для DLLN
0



Адрес табл. адресов ф-ции
Ссылки на имена


Ссылка на имя 1
Ссылка на имя 2


Ссылка на имя N
0


Описатель имени


Номер функции (hint)
Имя функции "CreateFileA'

Рис. 9 . 1 . Таблицы импорта
108 Часть III. Как не надо защищать программы

Импортируемые функции, т. е. функции, код которых находится в других ис-
полняемых модулях, но используется во время работы программы, описы-
ваются посредством таблиц импорта. Это четыре связанных между собой
таблицы: каталог импорта (Import Directory Table), таблица ссылок на имена
функций (Lookup Table), таблица имен функций (Hint-Name Table) и табли-
ца адресов импортированных функций (Import Address Table, IAT).
Таблицы импорта предназначены для того, чтобы правильно заполнить все
значения в таблице адресов импортированных функций. Каждое из этих
значений представляет собой адрес определенной функции во внешней биб-
лиотеке после ее загрузки в адресное пространство процесса (рис. 9.1).
РЕ-файлы содержат еще много разных таблиц и атрибутов. Более подробная
информация может быть найдена в технической документации на этот формат.
Глава 10


Регистрационные коды
для программ
Процедура регистрации приобретаемой продукции существует в мире до-
вольно давно. После совершения покупки потребитель заносит некоторые
сведения о себе в регистрационную карточку и отправляет ее производите-
лю. Таким образом, потребитель становится зарегистрированным пользова-
телем и получает все причитающиеся ему привилегии, например техниче-
скую поддержку и гарантийное обслуживание, а производитель пополняет
статистическую информацию о своих клиентах. Многие "коробочные" про-
граммные продукты также содержат регистрационные карточки, а в послед-
нее время даже позволяют отсылать регистрационную информацию через
Интернет.
Так как имя пользователя не является уникальным, каждый экземпляр про-
даваемой продукции целесообразно связывать с некоторым неповторяю-
щимся значением, называемым серийным номером. Этот номер указывается
пользователем при заполнении регистрационной карточки и в дальнейшем
используется при общении с производителем. А в приложении к программ-
ным продуктам серийный номер вполне может выполнять и вспомогатель-
ную функцию — ограничивать нелегальное копирование. Если программа
при установке требует ввести правильный серийный номер, украв (скопиро-
вав) носитель с дистрибутивом программы, который одинаковый у всех
пользователей, получить рабочую копию программы не удастся. А распро-
странение серийного номера позволяет найти и наказать ассоциированного
с этим номером пользователя.
В некоторых случаях после установки программы (неважно, с вводом се-
рийного номера или без) для получения доступа ко всем функциям про-
граммы пользователю необходимо выполнить еще одну процедуру — реги-
страцию или, как это теперь называет Microsoft, активацию. Такое
поведение характерно для большинства Shareware-продуктов, а также для
программ, разработчики которых считают, что пользователь не имеет права
работать, пока не сообщит о себе все необходимые сведения, даже если он
уже приобрел лицензию.
110 Часть III. Как не надо защищать программы <

I
Иногда серийный номер передается пользователю не в явном виде, а как|
часть кода активации/регистрации.


10.1. Требования и классификация
Программа должна содержать некоторый механизм, позволяющий прове-1
рить, является ли введенный пользователем серийный номер (или регистра-]
ционный/активационный код) правильным, а возможность вычислять пра-|
вильные коды должна всегда оставаться только в руках разработчика.
Для того чтобы противник, исправив несколько байт, не смог заставит^
программу работать так, как будто она была корректно зарегистрирована
активирована, необходимо те фрагменты кода или данных, доступ к кото-"1
рым разрешен только легальным пользователям, зашифровать стойким ал-
горитмом, а ключ шифрования вычислять, используя регистрационный код.
Тогда без знания регистрационного кода получить полноценную версию
программы не удастся. Подобную функциональность обеспечивают, напри-

<< Предыдущая

стр. 16
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>