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

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

Для того чтобы заставить программу работать так, как она работала бы с ключом, можно или внести исправления в программу, или эмулировать наличие ключа. Модификация программы, как правило, возможна лишь в тех случаях, когда ответы, полученные от ключа, просто проверяются, но не являются математически необходимыми для обеспечения работоспособности программы. Но это значит, что ключ, по большому счету, не требуется для достижения полной функциональности. Такое случается, когда программа не использует всех возможностей ключа или когда возможности ключа очень ограничены. При эмуляции никакого воздействия на программу не происходит, т. е., например, не нарушается контрольная сумма исполняемых модулей. И полный эмулятор, если его удается построить, просто повторяет все поведение реального ключа.

Про StarForce (SF), систему защиты программного обеспечения, распространяемого на дисках CD-ROM, от несанкционированного тиражирования, пока написано не очень много. В основном это информация рекламного характера, исходящая от разработчиков, но попадаются высказывания и тех,
кто эту защиту пытался обойти. На официальном интернет-сайте приводится следующее описание характеристик системы защиты StarForce Professional:
• SF Professional не позволит запустить программный продукт, если компакт-диск идентифицирован как скопированный. Вне зависимости от того, где и как была сделана копия диска (в домашних условиях или на заводском оборудовании), система определит, что данный диск — нелегальный;
• компакт-диски, защищенные SF Professional, не копируются такими программами, как CloneCD, CDRWin, BlindWrite и им подобными. Защищенны приложения не запускаются на эмуляторах компактдисков, к которым относятся Daemon Tools, Virtual CD-ROM и т. п.;
• используя комплект разработчика на этапе создания программного кода, можно значительно усилить защиту приложения против самых эффективных методов взлома;
• для встраивания защиты SF Professional не требуется специального технологического оборудования, нужен только компьютер и доступ на один из серверов StarForce;
• компакт-диски, защищенные SF Professional, максимально совместимы с разнообразными моделями существующих устройств CD/DVD-ROM. Это обусловлено тем, что в SF Professional используется уникальный метод определения подлинности диска без вмешательства в его физическую структуру;
• система защиты использует алфавитно-цифровой 24-значный ключ, который вводится пользователем защищенного программного приложения в процессе эксплуатации только один раз — в момент первого запуска. Ключ будет работать исключительно с дисками данной партии программного обеспечения.

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

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

Все методы проверки правильности кодов можно, условно, разделить на три категории:
• алгоритмические, основанные на принципе "черного ящика";
• алгоритмические, основанные на математически сложной задаче;
• табличные.
Любые алгоритмические методы позволяют связать код с именем пользователя или информацией о его компьютере, тем самым усложнив получение
нескольких копий программы, выглядящих как легальные. При использовании "черного ящика" разработчик старается запутать алгоритм проверки, чтобы его было труднее понять и обратить. Такой подход, наверное, используется чаще всех остальных вместе взятых. Причем его применяют не только неопытные разработчики. Так, например, именно в надежде на то, что противник не сможет разобраться, что к чему, изначально строилась система лицензирования FLEXlm, разрабатываемая компанией Globetrotter, а теперь принадлежащая Macrovision. Но противник, зачастую, оказывается одареннее, упорнее и лучше подготовлен в своей профессиональной области, чем разработчик защиты. Возможно, именно поэтому на очень многие продукты, защищенные FLEXlm, в Интернете нетрудно найти поддельные лицензии. А начиная с версии 7.2, FLEXlm поддерживает лицензии на основе эллиптических кривых, поделка которых
сводится к решению сложной математической задачи.

Программа должна содержать некоторый механизм, позволяющий проверить, является ли введенный пользователем серийный номер (или регистра-] ционный/активационный код) правильным, а возможность вычислять правильные коды должна всегда оставаться только в руках разработчика. Для того чтобы противник, исправив несколько байт, не смог заставить программу работать так, как будто она была корректно зарегистрирована активирована, необходимо те фрагменты кода или данных, доступ к которым разрешен только легальным пользователям, зашифровать стойким алгоритмом, а ключ шифрования вычислять, используя регистрационный код. Тогда без знания регистрационного кода получить полноценную версию программы не удастся. Подобную функциональность обеспечивают, например, программы ASProtect (ASPack Software) и EXECryptor (Soft-Complete Development).

Программа должна содержать некоторый механизм, позволяющий проверить, является ли введенный пользователем серийный номер (или регистра-]
ционный/активационный код) правильным, а возможность вычислять правильные коды должна всегда оставаться только в руках разработчика. Для того чтобы противник, исправив несколько байт, не смог заставитпрограмму работать так, как будто она была корректно зарегистрирована активирована, необходимо те фрагменты кода или данных, доступ к которым разрешен только легальным пользователям, зашифровать стойким алгоритмом, а ключ шифрования вычислять, используя регистрационный код. Тогда без знания регистрационного кода получить полноценную версию программы не удастся. Подобную функциональность обеспечивают, например, программы ASProtect (ASPack Software) и EXECryptor (Soft-Complete Development).

За время существования персональных компьютеров на процессорах семейства х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'.