Аннотация
С.В. Демьяненко, Н.Н. Садовой Программное обеспечение защиты исполняемых файлов электронными ключами.
Описывается программно-аппаратный метод защиты программного обеспечения с электронными ключами на примере разработанной авторами системы защиты «Sg Protector».
Ключевые слова: программно-аппаратный метод защиты, система защиты ПО, электронный ключ, NTFS-поток.
Введение. Проблема несанкционированного использования и распространения программного обеспечения стала объектом исследований ещё в конце 70-х годов XX столетия и не теряет своей актуальности до сих пор.
Для решения данной проблемы было разработано достаточно большое количество средств и методов защиты программного обеспечения, но в последнее время всё большую популярность приобретает программно-аппаратный метод защиты с электронными ключами. Электронный ключ - это аппаратная часть системы защиты, представляющая собой плату с микросхемами памяти и микропроцессором, помещенную в корпус и предназначенную для установки в один из стандартных портов ПК (COM, LPT, USB и т.д.), или слот расширения материнской платы [1].
В данной статье авторы попытаются объяснить принцип действия таких систем защиты на примере разработанной им системы защиты «Sg Protector».
Постановка задачи. Перед авторами была поставлена задача - разработать программное обеспечение защиты исполняемых файлов в Windows электронными ключами.
Решение задачи. В общих чертах принцип работы систем защиты, основанных на использование электронных ключей, выглядит так:
- защищенное приложение обращается к электронному ключу, который должен быть подсоединен к компьютеру;
- ключ возвращает приложению некоторую информацию;
- приложение при помощи этой информации идентифицирует электронный ключ. Если ключ имеет верные параметры, приложение продолжает работать. Если же параметры в ключе неверные (не тот электронный ключ) либо ключ вообще не подсоединен, защищенное приложение прекращает свою работу.
Для решения поставленной задачи был выбран электронный ключ Guardant Stealth III от российского производителя компании «Актив». Данный ключ подключается к USB порту компьютера и относится к классу «локальный электронный ключ», построен на базе микроконтроллера, имеет 2048 байтов EEPROM-памяти. В Guardant Stealth III реализованы симметричный алгоритм GSII64 для кодирования и декодирования данных и алгоритм хеширования HASH64 [2]. В ключе хранится особое 4-байтовое число – идентификационный номер (ID) ключа. ID имеет уникальное значение. Он прошивается на этапе производства ключа и не может быть продублирован или изменен. Значение ID может использоваться для «жесткой» привязки защищенного приложения к данному конкретному ключу. В памяти ключа записаны также специальные коды доступа, которые служат «паролем», по которому защищенное приложение может найти нужный ему ключ и выполнить конкретную операцию. Коды доступа записываются в память ключа на этапе его предпродажной подготовки и не могут быть изменены [2].
Разработчиками электронного ключа для создания систем защиты на его основе, предоставляется интерфейс прикладного программирования API - набор функций, позволяющих производить различные операции с электронными ключами: поиск, чтение и запись памяти ключа, кодирование данных при помощи аппаратных алгоритмов и т.д. Чтобы организовать работу системы защиты, нужно подключить к ней специальную библиотеку, вставить вызовы функций API в исходные тексты системы и организовать анализ возвращаемых функцией значений и обработку ошибок. При вызове API функции происходит обращение к библиотеке, в которой находится код, реализующий вызванную функцию, которая в свою очередь посредством специального драйвера обращается к электронному ключу. Весь процесс взаимодействия системы защиты с электронным ключом можно представить в виде следующей схемы, изображенной на рис.1.
Рисунок 1 - Схема взаимодействия системы защиты с электронным ключом
Необходимость создания системы защиты исполняемых файлов (уже скомпилированных программных модулей) приводит к тому, что проектируемая система должна относиться к классу так называемых «навесных» систем защиты. В основном системы такого рода состоят из двух составных частей – подсистемы внедрения защитного модуля и самого защитного модуля.
Подсистема внедрения защитного модуля – программа, которая прикрепляет защитный модуль к защищаемому приложению.
Защитный модуль – программный модуль, основной задачей которого является противодействие несанкционированному запуску и использованию защищаемого приложения. Этот модуль может реализовывать разные методы защиты, например, запрашивать у пользователя пароль или выполнять проверку наличия, при запуске программы и во время ее выполнения, электронного ключа с определенными параметрами.
Основной функцией подсистемы внедрения защитного модуля является предоставление пользователю возможности защитить выбранное им приложение. Для этого необходимо каким-то образом прикрепить модуль защиты к выбранному приложению так, чтобы при запуске защищенного приложения сначала выполнял свою работу модуль защиты и только при выполнении необходимых условий запускалось бы защищаемое приложение. Существует несколько способов, как это можно сделать. В основном все эти способы связаны в той или иной степени с модификацией PE-заголовка исполняемого файла, но существует и еще один весьма интересный способ, не требующий модификации PE-заголовка – это создание нового NTFS-потока внутри файла.
Файловая система NTFS поддерживает множество потоков в рамках одного файла, иначе называемых расширенными атрибутами (Extended Attributes (EA)) или именованными разделами. Безымянный атрибут соответствует основному телу файла, атрибут $DATE – времени создания файла и т.д. [3]. Имя потока отделяется от имени файла знаком ":". Штатные средства Windows не позволяют просматривать список расширенных атрибутов файла и их содержимое, таким образом появляется возможность достаточно скрыто хранить в созданном потоке защищаемое приложение. Следовательно, можно предложить следующий алгоритм внедрения: создаем внутри защищаемого приложения дополнительный поток, копируем в него основное тело файла, а на его место помещаем код модуля защиты, который по окончанию своей работы будет передавать управление на созданный дополнительный поток. При использовании этого метода возникает проблема – где хранить имя созданного потока, что бы оно ни стало известно злоумышленнику, и он не извлек его содержимое? Выходом из этой ситуации является использование для этих целей электронного ключа, т.е. имя созданного потока можно хранить в памяти ключа, который используется модулем защиты для проверки условий запуска защищаемого приложения.
Для обеспечения большей надежности системы защиты целесообразно использовать возможность, предоставляемую ключом Guardant Stealth III – шифрование данных, т.е. используя аппаратный алгоритм шифрования данных GSII64, зашифровать код защищаемого приложения. Тем самым даже если злоумышленник сможет убрать модуль защиты, он не сможет запустить приложение, предварительно не расшифровав его код.
Необходимым условием работы защищенного приложения является наличие определенного электронного ключа, подсоединенного к компьютеру, что в свою очередь влечет к необходимости модулю защиты иметь коды доступа к электронному ключу. Работу модуля защиты можно организовать так, что при каждом запуске защищаемого приложения пользователь будет вынужден вводить коды доступа вручную или же можно сохранить где-нибудь коды доступа, и модуль защиты будет сам их читать из известного ему места. Очевидно, что второй вариант организации работы более удобен для пользователя. А для хранения кодов доступа подсистема установки защитного модуля может создать не только дополнительный атрибут, хранящий зашифрованный код защищаемого приложения, но и атрибут для хранения кодов доступа и другой необходимой модулю защиты информации о ключе.
Таким образом, в результате работы подсистемы внедрения мы получим защищенное приложение, которое будет состоять из одного файла, содержащего в себе сразу три файловых потока.
- Основной поток – содержит код модуля защиты.
- Первый дополнительный поток – содержит коды доступа и ID ключа.
- Второй дополнительный поток – содержит зашифрованный код защищаемого приложения.
Схематично формат выходного файла можно представить, как показано на рис.2.
Рисунок 2 - Формат файла защищенного приложения
В результате запуска защищенного приложения происходит запуск модуля защиты. Модуль защиты читает из дополнительного потока коды доступа и ID ключа. По полученным параметрам выполняется поиск ключа. Если ключ не найден, то модуль защиты завершает свою работу. Если же ключ найден, из его памяти модуль защиты читает имя дополнительного потока, в котором находится защищаемое приложение. Затем при помощи аппаратного алгоритма выполняется дешифрация защищаемого приложения и его запуск. Во время работы защищаемого приложения выполняется периодическая проверка наличия ключа, и если ключ не будет найден, модуль защиты принудительно завершит работу защищаемого приложения.
Описанные выше алгоритмы и принцип работы были реализованы авторами в системе защиты «Sg Protector». Система была написана на языке программирования Object Pascal в среде разработки Delphi 7.
Выводы. Использование программно-аппаратного метода защиты с электронными ключами предоставляет разработчикам систем защиты достаточно широкий арсенал для усовершенствования и модификации своих систем.
Список использованной литературы
- Оценка эффективности систем защиты программного обеспечения. [Электрон. ресурс]: / С.А.Середа. Режим доступа: http://www.citforum.ru/security/software/sereda1/
- Электронные ключи «Guardant». Руководство пользователя. Ч.1. – М.: Изд-во компании «Актив», 2007. – 240 с.
- Касперски К. Техника внедрения кода в PE-файлы и методы его удаления / К. Касперски // Хакер. – 2004. – №7. – С.62-81.