Эмулятор ключа защиты hasp что это сделать

Эмулятор ключа защиты

Как собрать эмулятор ключа защиты — инструкция по снятию дампа и эмуляции аппаратных ключей, используя эмулятор Multikey

1) Для снятия дампа с ключа нужно знать MODAD — параметр, который можно узнать при помощи (А) Toro Aladdin Dongles Monitor или (Б) брутфорсом, то есть перебором

А) распаковываем архив haspmon32.zip
запускаем Toro Aladdin Dongles Monitor.exe
запускаем вашу программу, которая проверяет ключ
Toro Aladdin Dongles Monitor показывает нам MODAD

Б) распаковываем в C:\dumper архив hl-dump.zip
открываем командную строку (Пуск — Выполнить — cmd)
пишем в ней
C:
cd C:\dumper
hl-dump.exe /BF

дампер подбирает MODAD и выплевывает два файла xxxx.dat и xxxx.reg где xxxx — это MODAD
Внимание, это процесс небыстрый, иногда до 9 часов, так что ждите

2) Если мы узнали MODAD первым способом, то снимаем дамп, если вторым, то дамп уже снят.
для этого выполняем пункт 1.Б, но вместо команды hl-dump.exe /BF вбиваем hl-dump.exe /DUMP 0xMODAD где MODAD заменяем на найденное нами значение, например
HL-DUMP.EXE /DUMP 0x409

Теперь нужно узнать seed`ы и переконвертировать дамп в формат, понятный эмулятору.

3) распаковываем hl-solver.zip корень диска C:
копируем xxxx.dat полученный ранее в папку C:\trial_solver_directory_demo_version_only
запускаем C:\hl_solver.exe
ВМЕСТО НУЛЕЙ вводим MODAD
жмем Find seeds
прога долго переваривает и выдает три значения сидов
записываем их куда-нибудь, потом пригодятся

4) распаковываем UniDumpToReg.rar
запускаем UniDumpToReg.exe
жмем Open
выбираем xxxx.dat
ставим галочку на vUSBbus Hardlock
жмем Go
прога выплевывает 0000xxxx.reg

Если прога не запускается и выдает ошибку, что приложение не настроено, установите vcredist_x86.exe

теперь отредактируем 0000xxxx.reg и всё, дело сделано
Внимание! все изменения вносятся в 0000xxxx.reg

5) открываем в текстовом редакторе 0000xxxx.reg и xxxx.reg
заменяем
Services\Emulator\Hardlock\Dumpна
на
MultiKey\Dumps

заменяем нули в «ID»=dword:00000000 на значение такого же параметра из xxxx.reg
дописываем в 0000xxxx.reg три строчки
«Name»=»имя проги»
«Created»=»дата создания дампа»
«Copyright»=»© 2018 UseHelp.org»

Обратите внимание на строчки

сравните их значения с теми значениями, которые получили на 3 этапе, если эмулятор не будет работать — попробуйте заменить сиды.

Источник

Установка и настройка 1С 8.2 эмулятор HASP-драйвера для Windows x64. Настройка конфигураций 1С

Установка и настройка 1С 8.2 эмулятор HASP-драйвера для Windows x64

Работоспособность гарантируется при полностью чистой лицензионной Windows системе (Windows Vista x64, Windows Server 2008 x64, Windows 7 x64, Windows Server 2008 R2 x64 включая с установленным Service Pack 1)
Установку выполнять под локальным администратором!

Скачать Драйвер HASP с поддержкой х64:

4) Вносим дампы (ветка реестра с дампами изменилась) — папка «Dumps», запустить и добавить в реестр файл «v8 50 user.reg» для рабочей станции, для сервера необходимо добавить все файлы в папке «Dumps» — архив для скачивания внизу статьи.

5) Запустить install_sertif.cmd (установка личного сертификата и включение тестового режима Windows), если не хотите нажимать F8 каждый раз при запуске.

При этом ваша ОС должна загрузиться в тестовом режиме — если так не произошло то нужно при перезагрузке нажать на кнопку F8 и выбрать Тестовый режим с возможностью установки драйверов с неподписанными сертификатами. Тестовая версия служит для установки в систему неподписанных сертификатом драйверов устройств. Сертификат выдает Майкрософт после отправку, соответствующего драйвера, изготовителем устройства (оборудования), для тестирования в лабораторию Майкрософт. Абсурд в том, что на драйвер-эмулятор никто сертификат не выдаст и соответственно избежать тестовой версии не возможно.

Также необходимо повторить удалением все патчи, эмуляторы HASP, найденные в системе, и запустить повторно пункт 5.
Тестовый режим может не включаться, если Windows уже находится в другом режиме, например «Защищенный режим».
Некоторые активаторы Windows, переводят систему в защищенный режим, чтобы обойти механизм активации.
В таком случае Вам необходимо удалить данный активатор и/или обновить активатор и/или приобрести лицензионный продукт.

Не забудьте отключить антивирус, его компоненты зачастую блокируют установку драйверов.

Отвечаем «Yes», когда выводится запрос о продолжении установки неподписанных драйверов.

Проверка. На значке устройства «Virtual Usb Bus Enumerator» не должен стоять восклицательный знак. Устройство должно работать нормально.

9) Установка HASP LM driver (ТОЛЬКО для установки на платформу Windows Server). В архиве — внизу статьи.

9) Для отключения вывода сообщения на рабочий стол «Тестовая версия» необходимо установить «RemoveWatermarkX64.exe». В архиве — внизу статьи.

Источник

Защита компьютера эмуляторами Hasp и Sable

Эмулятор – это программа, которая имитирует работу различных физических устройств или других программ.

Например, виртуальные диски, эмуляторы игровых приставок, игр и т.д. В статье рассматривается эмулятор ключа защиты HASP.

HASP – аппаратно программный комплекс защиты ПО от незаконного (несанкционированного) использования и распространения.

Ключи выпускаются для различных ОС – Windows, Linux, Android и 32- и 64-разрядных компьютеров.

Система разработана компанией Aladdin KS, в защиту которой входит:

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

Существуют различные исполнения ключа HASP:

– брелок USB;
– ключ LPT;
– карта PCMCIA, внутренняя карта PCI.

Наибольшее распространение имеет брелок USB. В настоящее время применяются несколько вариантов ключей:

1) HASP 4 (первая версия защиты), HASP HL (HardLock – современный вариант) – это аппаратные ключи.

2) HASP SL (Soft Lock) – программный ключ. Этот ключ более удобен для распространения приложений, но имеет меньший уровень защиты, чем у HL.

3) HASP SRM комбинированное решение, в нем есть выбор – что использовать: аппаратный HL или программный SL ключ.

Защитой HASP пользуются такие пакеты программ как 1С, Консультант Плюс. Порядок защиты примерно такой. Ключ присоединен к определенному порту компьютера. Устанавливается специальный драйвер защиты.

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

Эмуляция ключей используется в следующих случаях:

– взлом защиты программ (хакерство, нелегальное использование — к сожалению.);
– неустойчивая работа HASP ключей;
– выход из строя или потеря ключа;
– неудобство использования ключа на различных компьютерах.

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

Это значит, что для установки любого эмулятора, у вас должна быть лицензионная версия ПО.

Если по какой-то причине необходим эмулятор ключа, нужно иметь в виду следующее – вариантов эмуляторов, это зависит от:

– числа пользователей программы;
– версии программы – сетевая или для локальных пользователей;
– для какого сервера нужен эмулятор – Server 2003, 2008 и др.

Создано много программ эмуляции, среди них комплекс Sable. Далее два конкретных примера.

Установка эмулятора Hasp HL

Распаковать и запустить HASPHL2007.exe

Должны быть установлены драйвера и оригинальный ключ подключения.

В программе DRIVER нажать INSTALL – установка драйвера.

Запустиь программу edgehasp.exe – генерация ключа. Полученный ключ ввести в закладку “EMULATOR”. Нажать “StartService”.

Запустить программу EDGEHASP.EXE для преобразования файла.

Открыть файл «DONGLES» в окне «HASP/Hardlock Emulator» и указать имя файла.

Очистить дамп – кнопка CLEAN.

Можно пользоваться. 🙂

Установка эмулятора Sable

Информацию можно найти по адресу:

Запустить Sable и дождаться перезагрузки.

Удалить ярлык эмулятора – C:\Documents Settings\All users\StartМenu\Programs\Startup

Запустить C:\ProgramFiles\SABLE\. Запустить delnt.bat – удаление Hasp из реестра.

Установить эмулятор Hasp — C:\ProgramFiles\SABLE – запустить instnt.bat.

Cвойства (Propetries – hasp Automatic.) Ok.

Копировать patch77. exe из C:\ProgramFiles\sable в папку 1С.

Запустить patch77.exe /F1cv7.exe.

Удалить patch77.exe. Перезагрузка.

Здесь вы можете Скачать HASP эмулятор совершенно бесплатно.

На сегодня у меня все, следите за блогом по электронной почте. Жду ваших отзывов в комментариях. Пока!

Источник

AntiHASP: эмулируем ключ аппаратной защиты HASP

Содержание статьи

В этой статье описаны способы обхода аппаратных систем защиты. В качестве примера рассмотрена технология HASP (Hardware Against Software Piracy), разработанная компанией Aladdin Knowledge Systems Ltd. В прошлом данная технология являлась одной из самых популярных аппаратных систем защиты ПО.

Мощью аппаратной защиты HASP пользуются многие серьезные разработчики софта, которые не хотят, чтобы их продукт несанкционированно распространялся. Хаспом, например, защищаются пакеты «1С.Бухгалтерия» или «1С.Предприятие», без которых не может прожить ни одно более или менее организованное дело. Популярный юридический справочник «КонсультантПлюс» также защищает доступ к данным с помощью электронных ключиков. Чтобы воспользоваться вышеупомянутым или другим не менее дорогостоящим софтом, не платя никому ни копейки, недостаточно просто полазить по Сети в поисках txt’шника с ключиками. Однако хакер всегда разберется, что делать с защитой, пусть и аппаратной. И паяльник ему для этого не понадобится.

Взглянем

Утрируя, можно сказать, что HASP состоит из двух частей: аппаратной и программной. Аппаратная часть — это электронный ключик в виде USB-брелка, PCMCIA-карты, LTP-девайса или вообще внутренней PCI-карты. Установленный софт будет работать только на той машине, в которую воткнут электронный ключ. Собственно, неплохо было бы отучить софт от такой неприятной для кошелька привычки.

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

Механизм системы защиты

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

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

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

Перехват и эмуляция

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

NTSTATUS HookDevice(LPWSTR lpDevice)

UNICODE_STRING DeviceName;
PDEVICE_OBJECT DeviceObject;
PFILE_OBJECT FileObject;

Получив указатель на структуру DEVICE_OBJECT, имеем указатель на DRIVER_OBJECT. Теперь заменим адреса обработчиков и функций выгрузки драйвера на свои:

NTSTATUS HookDevice(LPWSTR lpDevice)

gDriverObject = DeviceObject-> DriverObject;

gDeviceControl = gDriverObject-> MajorFunction[IRP_MJ_DEVICE_CONTROL];
gDriverObject-> MajorFunction[IRP_MJ_DEVICE_CONTROL] = HookDispatch;

gInternalDeviceControl = gDriverObject-> MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL];
gDriverObject-> MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = HookDispatch;

gDriverUnload = gDriverObject->DriverUnload;
gDriverObject->DriverUnload = HookUnload;

В последней строчке вызывается функция ObfDereferenceObject, которая уменьшает количество ссылок на файловый объект. Это необходимо делать для корректной выгрузки драйвера, чтобы не было утечки ресурсов и аналогичных ошибок.

Так как указатель на объект драйвера защиты сохранeн, то чтобы снять ловушку, нужно просто восстановить прежние обработчики IRP-пакетов:

gDriverObject-> MajorFunction[IRP_MJ_DEVICE_CONTROL] = gDeviceControl;
gDriverObject-> MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = gInternalDeviceControl;
gDriverObject->DriverUnload = gDriverUnload;

Конечно, надо добавить соответствующие проверки на валидность указателей и прочее.

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

void HookUnload(PDRIVER_OBJECT DrvObj)

Здесь происходит восстановление полей структуры DRIVER_OBJECT, и передаeтся управление на оригинальный код выгрузки драйвера перехваченного устройства.

Аналогично поступаем, если наш драйвер завершает работу раньше системы защиты. Только нужно высвободить захваченные ресурсы и не вызывать сохранeнный gHookUnload.

Принцип работы эмулятора

Перехватчик

Зная основные принципы простейшего перехвата IRP-пакетов, приступим к реализации пока только самого перехватчика для дальнейшего анализа. Для этого создадим объект драйвера, который содержит символьное имя (например DosDevicesHook) и точки входа CREATE, CLOSE, READ.

DriverObject->MajorFunction[IRP_MJ_CREATE] = DriverDispatch;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = DriverDispatch;
DriverObject->MajorFunction[IRP_MJ_READ] = DriverDispatch;
DriverObject->DriverUnload = DriverUnload;

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

if (idlTail->IrpData.InputLength)
<
idlTail->InputBuffer = ExAllocatePool(NonPagedPool, idlTail->IrpData.InputLength);
RtlCopyMemory(idlTail->InputBuffer, Irp->AssociatedIrp.SystemBuffer, idlTail->IrpData.InputLength);
>

if (IoSL->MajorFunction == IRP_MJ_DEVICE_CONTROL)
Status = pHookedDriverDispatch[IRP_MJ_DEVICE_CONTROL]( DeviceObject, Irp);

if (idlTail->IrpData.OutputLength)
<
idlTail->OutputBuffer = ExAllocatePool(NonPagedPool, idlTail-> IrpData.OutputLength);
RtlCopyMemory(idlTail->OutputBuffer, lpBuffer, idlTail->IrpData.OutputLength);
>

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

idlTemp = idlHead->ldlNext;
ExFreePool(idlHead);
idlHead = idlTemp;
if (!idlTemp)
idlTail = NULL;
>

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

Перехваченные пакеты без ключа

Перехваченные пакеты с ключом

Затем возможны несколько вариантов дальнейших действий:

Оба варианта дают необходимую информацию. Итак, оказывается, содержимое пакетов шифруется публичным симметричным алгоритмом AES (Advanced Encryption Standard). Логичной целью является получение ключа шифрования.

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

Пример дампа ключа

Поэтому первое, что нужно сделать, это получить ключ. Поставленную задачу может решить обычный брутфорс:

unsigned short Key;
unsigned char RefKey[8], VerKey[8];

for (Key = 0; Key WORD HL_LOGIN(WORD ModAd, Word Access, Byte *RefKey, Byt *VerKey);
WORD HL_LOGOUT(void);

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

Новый API мало отличается от старого, и это никак не сказывается на принципе работы брутфорса. Подробную документацию Hasp API, готовые реализации брутфорса и дампера ключей можно найти на диске.

Обработчик

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

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

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

void Encrypt(BYTE * Buffer)
<
WORD Seed = ((WORD)Buffer + 0x5e);
WORD Ver = ((WORD)Buffer + 0xba);

if (Ver)
<
for (int i = 0; i > 15) | (Seed > 15) | (Seed void Decrypt(BYTE* Buffer)
<
WORD Seed = ((WORD)Buffer + 0x5e);
WORD Ver = ((WORD)Buffer + 0xba);

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

В заключение отмечу, что построение табличного эмулятора, основанного на перехвате DeviceIoControl, — достаточно трудная задача. Но такой принцип эмулятора можно использовать и на другом уровне взаимодействия: создать виртуальную USB-шину.

Заключение

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

Источник

Эмулирование электронных ключей (HASP)

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

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

Эмулирование данного типа устройств осуществляется так же, как и для CD, если не проще. Вызовы к электронному ключу проще (относительно) перехватить и построить эмулятор.

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

Взлом программного модуля

Взлом программ осуществляется двумя основными способами. Это отладка (или пошаговое исполнение) и дизассемблирование.

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

Теперь рассмотрим основные методы взлома и противодействия ему.

Отладка

Способов противодействия отладке существует не меньше чем отладчиков. Это именно способы противодействия, поскольку основная их задача сделать работу отладчика либо совсем невозможной, либо максимально трудоемкой. Опишем основные способы противодействия:

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

Изменение определенных регистров процессора, на которые отладчики неадекватно реагируют. Также как и со средой. Отладчик тоже программа и тоже пользуется и операционной системой и процессором, который один на всех. Так, если менять определенные регистры микропроцессора, которые отладчик не может эмулировать, то можно существенно «подорвать» его здоровье.

Дизассемблеры и дамперы

Про дизассемблер было сказано выше, а вот про дампер можно добавить то, что это практически тот же дизассемблер, только транслирует он не файл, находящийся на диске в Ассемблерный код, а содержимое оперативной памяти на тот момент, когда приложение начало нормально исполняться (то есть, пройдены все защиты). Это один из коварных средств взлома, при котором хакеру не надо бороться с механизмами, противодействующими отладке, он лишь ждет, когда приложение закончит все проверки на легальность запуска, проверяя метки на диске, и начинает нормальную работу. В этот момент дампер и снимает «чистенький» код без примесей. К всеобщей радости не все защиты могут просто так себя раскрыть! Об этом поподробнее:

Шифрование. Самый простой и эффективный способ противодействия. Подразумевает, что определенная часть кода никогда не появляется в свободном виде. Код дешифруется только перед передачей ему управления. То есть вся программа или ее часть находится в зашифрованном виде, а расшифровывается только перед тем как исполниться. Соответственно, чтобы проанализировать ее код надо воспользоваться отладчиком, а его работу можно очень и очень осложнить (см. выше)!

Шифрование и дешифрование (динамическое изменение кода). Более продвинутый способ шифрования, который не просто дешифрует часть кода при исполнении, но и шифрует его обратно, как только он был исполнен. При такой защите хакеру придется проводить все время с отладчиком, и взлом защиты затянется на очень и очень долгое время.

CD-COPS

Производитель этого продукта, датская компания Link Data Security, была основана в 1982 году. Выпуском коммерческих продуктов, предназначенных для защиты информации от несанкционированного копирования, она занимается уже почти 20 лет: в 1984 году вышла первая версия программы Cop’s Copylock для DOS. В настоящее время Link Data Security предлагает полную линейку защитных систем для программ, работающих под управлением операционных систем DOS и Windows. Защищенные приложения могут распространяться на дискетах, компакт-дисках, DVD или через Интернет. В каждом случае применяется свой способ защиты.

CD-Cops умеет распознавать «родной» компакт-диск и в то же время четко отсекать копии, сделанные как на записываемых и перезаписываемых носителях, так и заводским способом. Работает этот продукт следующим образом. Применив защиту, вы производите партию дисков; при получении готовых CD, отпечатанных с одной и той же матрицы, необходимо запустить утилиту, которая считает один из дисков и выдаст код доступа (для разных партий дисков этот код будет разным). Этот код наносится на коробку либо непосредственно на диск. При установке программы пользователю необходимо ввести код, после чего программа будет установлена на его компьютер и сможет запускаться только при наличии оригинального диска в приводе CD-ROM. При этом не имеет значения, скопированы необходимые для работы приложения компоненты на жесткий диск или используются непосредственно с компакт-диска. При попытке подменить оригинальный диск на его копию приложение запускаться не будет.

CD-Cops довольно надежно защищает диски от копирования, но эту защиту можно обойти путем взлома защищенных файлов.

Star Force

Данная программа так же, как CD-COPS и TAGES, пользуется самой эффективной системой защитой от копирования, основанной на способе измерения специфических характеристик CD\DVD-ROM. Поскольку защита не вскрыта, то не известен и способ, которым производителям удается идентифицировать различные диски. Заявленная 100% совместимость с любой аппаратурой и 100% идентификация дисков подтверждается независимыми сайтами.

Защита эффективно противодействует отладчикам и дизассемблерам. Эффективность защиты подтверждает тот факт, что за год существования не нашелся способ ее нейтрализации. Дополнительный лоск защите придает возможность защиты мелких партий дисков (CD-R\RW) и наличие SDK, при помощи которого разработчики игр могут шифровать отдельные фрагменты кода и данных. Отдельно можно воспользоваться функцией шифрования игровых данных от несанкционированного «перевода» или «адаптации».

TAGES

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

Aladdin

Подведение итогов. Выбор защиты

Из сравнительной таблицы и так видно кто есть кто.

Из имеющихся на данное время систем защит мы имеем две системы:

Коммерческий аспект

Давайте ответим на простой вопрос: а зачем нужна защита для создаваемого ПО, если она в итоге ломается?

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

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

Что же позволит сделать эффективная защита для выпускаемого ПО?

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

Во-вторых, устойчивая защита позволяет производителю программного обеспечения гарантировать возврат инвестиций. Говоря простым языком, если защита вскрывается за 4-5 месяцев, то компания-производитель может продать достаточное количество копий своего продукта, чтобы покрыть все расходы на разработку и производство и получить прибыль. А если новая версия продукта выходит через 7-8 месяцев, то коммерческий успех можно повторять до бесконечности.

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

Об эффективности защиты

Оба варианта защит предусматривают два способа внедрения в тело программного обеспечения:

Вариант использования готовой защиты.Использование SDK.

Использование готовой защиты позволит наиболее быстро установить (внедрить) защиту в свой программных продукт, но здесь есть одно «но». Встроенная защита, обычно, очень легко ломается. К сожалению, многие компании идут как раз по пути наименьшего сопротивления, то есть по пути стандартной защиты, получая, в итоге, сломанный пиратами свой программный продукт. Причем, сломанный в кратчайшие сроки. В итоге ломается не только продукт, но и дискредитируется компания, которая производит данную защиту. Хотя компания ни в чем и не виновата.

Использование SDK позволит встроить защиту в разрабатываемое ПО наиболее эффективным образом (так называемый способ размазанной защиты). Этот способ требует некоторых дополнительных издержек на обучение специалистов и написание дополнительного кода в тело имеющегося ПО. Но игра стоит свеч.

Цена вопроса

Давайте рассмотрим во что обойдется внедрение защиты.

Сравнение с конкурентами

Если обратиться к ценам (зарубежных) конкурентов, то можно получить следующую картину относительно объема партии 5000 CD и с учетом того, что данными системами можно защищать только печатные диски, а не CD\r\rw:

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

Считаем, что цена SF является приемлемой и даже низкой.

Цена защиты делает ее наиболее эффективной для рынка индивидуальных пользователей.

Разброс цен следующий: от 13,5 у.е. (самый дешевый ключ+большой объем поставки) до 270 у.е. (самый дорогой в кол-ве 1 штуки). Все зависит от модели ключа; сетевой он / не сетевой; размера поставки). В отличии от SF, у «Алладина» имеются сетевые ключи, что позволяет организовать доступ по принципу клиент-сервер.

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

Схема внедрения защиты

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

Разработчики должны изучить функции SDK, представляемого SF и Аладдин, на уровне достаточном для реализации функций и задач интеграции защиты в новой или разрабатываемое ПО.

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

По независимой оценки, специалистов использовавших SDK от SF следует отметить, что сам SDK можно отнести к среднему уровню сложности для понимания разработчиками (к примеру, SDK Алладина на порядок проще), но она укладывается в разумные рамки по времени, необходимому на изучение (порядка 1 человек осваивает систему за 3-4 дня).

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

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

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

Рисунок 1. Схема внедрения защит Star-Force или «Аладдин»

Рекомендации по выбору защиты

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

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

LSHead SDK

Самый сложный, с точки зрения защиты программный продукт, так как представляет собой не отдельный исполняемый модуль, а отдельную библиотеку. Защитить полностью без потерь в производительности не представляется возможным. Если заказчик будет поставлять SDK в открытом, виде, то защитить его невозможно совсем. В этом случае можно эффективно организовать защиту рекомендуя компании-производителю программы (использующей данный SDK) пользоваться максимально эффективным способом защиты от взлома и копирования.

LSHead и LSHead Pro

Поскольку ноу-хау заказчика составляет оригинальность модуля расчета мимики персонажа в реальном времени, то защитить сразу весь продукт невозможно. Здесь основную роль играет фактор времени… Любая эффективная защита вынуждена определенным образом шифровать области исполняемого модуля, а это дополнительные издержки в производительности. Соответственно, защитив продукт «в лоб» теряется скорость работы. И здесь на помощь приходит SDK. Разработчики заказчика должны сами определить модули, которые необходимо защитить.

LSHead WWW

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

PsyTest

Рекомендации, такие же, как и выше. Необходимо использовать SDK защиты. Здесь еще нужно учитывать также не только защиту кода от взлома, но и защиту данных от нелегальных «дополнений» и изменений.

Game

Рекомендации, такие же, как и выше. Необходимо использовать SDK защиты. Особенно, в игровой программе необходимо защищать ресурсы от несанкционированных действий, таких как изменений ресурсов (нелегальный перевод картинок и звуков), вывод ресурсов из состава игры.

Приведенные выше рекомендации были общими, без привязки к конкретной реализации защиты. Напомню, что мы выбираем из двух защит, принципиально отличающихся по цене и типу привязки. Это Star-force (привязка к компакт диску и характеристикам компьютера, отсутствие сетевых лицензий) и «Аладдин» (привязка к электронным ключам, наличие сетевых лицензий). Рекомендации также учитывали такой немаловажный критерий как традиционность защиты для данного сегмента рынка. Данный критерий, даже, некоторым образом отодвинул на второй план такой главенствующий фактор, как эффективность защиты. Также во внимание принимался такой фактор, как планируемый тираж программного продукта и его ориентация (не только по шкале корпоративный-частный, но и по шкале отечественный-зарубежный).

Таблица 5. Рекомендации по выбору защиты

Подведем некоторый итог. Каждая из защит эффективна только для своего сегмента рынка.

Защита не только кода, но и данных;

Привязка к компакт-диску и характеристикам компьютера;

Не слишком большое удорожание стоимости продукта;

Недорогая защита мелких партий (на cd-r\rw);

Надежные электронные ключи;

Быстрое в изучении SDK;

Защита не только кода но и данных;

Возможности реализации различных маркетинговых схем.

Сложность тех. Поддержки защищенных продуктов

Ранее основной проблемой всех систем, включая SF, была несовместимость защиты с некоторыми видами приводов CD\DVD (продукцией No-name, и рядом устройств для ноутбуков). SF успешно решила данную проблему двумя способами. Во-первых, список совместимость с приводами постоянно растет. Во-вторых, в системе имеется возможность введения универсального кода, который позволит запустить приложение, если диск не аутентифицируется.

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

В случае использования данной функции необходимо организовать службу поддержки, регистрирующей запросы от пользователей и создающей Rescue ключи (служба получает запросы от пользователей и генерирует ключи через сервер SF). В случае выбора защиты «Алладин» технической поддержке придется отвечать на вопросы об установке драйверов и о работе с портами.

Источник