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

Протекторы призваны обеспечить защиту содержимого исполняемого файла от исследования и модификации. Но часто получается, что защищенная программа по некоторым характеристикам оказывается для пользователя хуже, чем та же программа, но без защиты. Прежде всего, протектор — это дополнительный объем кода. Если протектор не поддерживает упаковку защищаемых данных, размер файла на диске в процессе защиты увеличится на размер самого протектора. Правда, стоит отметить, что при использовании сжатия защищенный файл может оказаться меньше оригинального в несколько раз. Также код протектора требует и некоторого количества оперативной памяти. Но основной перерасход ресурсов оперативной памяти происходит по другой причине, связанной с особенностью загрузки исполняемых файлов в Win32. Практически все современные операционные системы имеют встроенную поддержку так называемых файлов страничной подкачки (Page File или Swap File). Вся логическая память, доступная выполняемым программам, разбивается на страницы, и некоторые редко используемые страницы могут оказаться не в оперативной памяти, а на диске в файле подкачки. При любом обращении к такой странице менеджер памяти выполняет операцию чтения данных с диска в оперативную память (подкачку). Если в оперативной памяти нет свободных страниц, одна из наиболее редко используемых страниц вытесняется из оперативной памяти на диск. В Win32 также существует механизм файлов, отображаемых в память (Memory Mapped Files), который позволяет отобразить в адресное пространство любой дисковый файл.

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

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

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

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

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

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

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

В некоторых ключах алгоритму могут сопутствовать дополнительные атрибуты. Так, например, в ключах Sentinel SuperPro алгоритм может быть защищен паролем и начинает работать только после того, как будет выполнена активация, в ходе которой правильный пароль должен быть передан ключу. Активация позволяет разработчику предусмотреть возможность изменения функциональности ключа на стороне пользователя. То есть программа может иметь несколько версий (например базовую, расширенную и профессиональную), и в ключе изначально активированы только те алгоритмы, которые необходимы для функционирования базовой версии. Если же пользователь решит перейти к более полной версии, разработчик пришлет ему инструкции по активации алгоритмов, соответствующих расширенной или профессиональной версии. Однако все достоинства алгоритмов, активируемых по паролю, опираются на секретность пароля, а не на свойства аппаратного ключа. Следовательно, аналогичная защита может быть реализована чисто программными средствами.