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);
>

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

Length = IoSL->Parameters.Read.Length;
if (Length == sizeof(IRP_DATA) && idlHead)
RtlCopyMemory(Irp->UserBuffer, &idlHead->IrpData, Length);
else if ( > IrpData.InputLength + idlHead-> IrpData.OutputLength))
<
RtlCopyMemory(Irp->UserBuffer, idlHead-> InputBuffer, idlHead->IrpData.InputLength);
RtlCopyMemory((PVOID)((ULONG)Irp->UserBuffer + idlHead->IrpData.InputLength), idlHead-> OutputBuffer, idlHead->IrpData.OutputLength);
>
else if (Length == 1 && idlHead)
<
if (idlHead->InputBuffer)
ExFreePool(idlHead->InputBuffer);
if (idlHead->OutputBuffer)
ExFreePool(idlHead->OutputBuffer);

>ldlNext;
ExFreePool(idlHead);
> if (!idlTemp)
> >

Когда перехватчик готов, запускаем сначала его, а затем — защищенное приложение с ключами и без. Из полученных логов становится видно, какие управляющие коды посылаются и их результаты. Также можно видеть, что запросы и ответы на два различных кода (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-пакеты. Здесь все уже зависит от конкретной версии ключа и защищаемой программы.

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

PIO_STACK_LOCATION Stack = Irp-> Tail.Overlay.CurrentStackLocation;
ULONG IoControlCode;
if (Stack->MajorFunction == 14)
<
IoControlCode = Stack.DeviceIoControl.IoControlCode;
If (IoControlCode != 0x9c402458)
<
Return gDeviceControl(DeviceObject, Irp);
>
else
<
Encrypt(Irp->AssociatedIrp.SystemBuffer);
Crypt(Irp->AssociatedIrp.SystemBuffer, Key, DumpMemory);
>
>

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

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);

if (Ver) <
for (int i = 0xFE; i > 0xBD; i–) <
Seed -= (WORD)(Buffer + i) ^ i;
Seed = (Seed > 1);
(WORD)(Buffer + i) += Seed;
>

for (int i = 0xB8; i >= 0; i–) <
Seed += (WORD)(Buffer + i) ^ i;
Seed = (Seed > 1);
(WORD)(Buffer + i) -= Seed;
>

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

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

Заключение

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

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

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

1С поддерживает работу как с программными, так и с аппаратными ключами. Разберемся подробнее с каждым из этих видов:

Программный ключ защиты 1С

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

Условно программную лицензию 1С можно поделить на 2 вида:

• однопользовательская,
• многопользовательская.

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

Многопользовательская лицензия чаще всего устанавливается на сервер (1С:Предприятие, сервер терминалов, WEB-сервер). При обращении 1С-клиента к 1С-серверу программное обеспечение само отслеживает количество свободных лицензий и позволяет (или не позволяет, если количество лицензий исчерпано) работать с 1С. При этом стоит отметить, что многопользовательская лицензия до 50 пользователей может быть активирована не только на сервере, как общая, её можно активировать на 50 разных клиентских компьютерах как 50 однопользовательских лицензий. Но если хотя бы одна лицензия из комплекта многопользовательской активирована как однопользовательская, то дальнейшее использование лицензий как “комплекта” уже невозможно.

Аппаратный ключ защиты 1С

Более надежным, но вместе с тем, и более дорогим способом защиты 1С являются аппаратные ключи. Аппаратные ключи защиты (HASP-ключ) выглядят как флешка и отмечают 1С, как прошедшую лицензирование. В данном случае, в отличие от программной лицензии, ПИН хранится на HASP, а не в файле на компьютере/сервере.

Существуют 4 вида аппаратных ключей, каждый имеет отличительный цвет и маркировку:

• Ключ для одного пользователя (локальный). Ключ имеет синий цвет и маркировку H4 M1 ORGL8. Данный ключ поставляется вместе с продуктами, у которых есть лицензия на один персональный компьютер.
• Сетевой ключ. Ключ красного цвета. HASP-ключ вставляется в один компьютер и виден всем компьютерам в сети. Маркируется как NETXX ORGL8. где ХХ – это количество лицензий. Есть разновидности на 5, 10, 20, 50, 100, 300, 500 лицензий.
• Серверный ключ для 32-битного сервера. Имеет фиолетовый цвет и маркировку ENSR8. Всегда поставляется вместе с лицензией на сервер.
• Серверный ключ для 64-битного сервера. Имеет зеленый цвет и маркировку EN8SA. Может работать также и с 32-разрядными серверами.

. Стоит подчеркнуть, что специалисты 1С не рекомендуют использование локального ключа и сетевого ключа на одной машине. При запуске 1С будет идентифицирован локальный ключ, а сетевой использоваться не будет, при этом все остальные пользователи сети не смогут “видеть” сетевой ключ и, как следствие, не смогут работать в 1С.

Менеджер лицензий 1С

В случае работы с многопользовательской лицензией необходимо, чтобы 1С знала о наличии такой лицензии в сети. За это отвечает Менеджер лицензий 1С (Hasp License Manager). Менеджер лицензий 1С является дополнительным программным обеспечением (входит в комплект поставки), без которого многопользовательская лицензия не будет корректно работать.

Ответы на часто задаваемые вопросы по ключам защиты 1С

№1. 1С не видит лицензии

В случае использования аппаратных ключей, если 1С не видит лицензий, в первую очередь необходимо удостовериться, что на HASP-ключе мигает индикатор. Это показатель того, что устройство определено и драйвер HASP-ключа установлен. Если лампочка не горит, попробуйте подключить ключ-флешку в другой порт USB, либо обратитесь к системному администратору, возможно у пользователя не хватает прав доступа для установки драйвера.

Также, в первую очередь убедитесь, что к компьютеру подключен ключ нужной серии. помните, что ключи могут блокировать друг-друга.

№2. Драйвер ключа защиты HASP устанавливается с ошибкой.

1. Возможно несовместимы операционная система и драйвер ключа. Попробуйте скачать более новую версию драйвера.
2. Файлы драйвера могут быть заблокированы из-за того, что заняты другим процессом. Попробуйте перезагрузить компьютер и сразу после загрузки установить драйвер. Либо примените консольную версию утилиты установки с параметрами командной строки: hinstall -i -kp

№3. Ошибка: HASP not Found (-3), (Error 7), (H0007)

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

№4. HASP Device Driver not installed (-100)

Распространенная ошибка Windows XP. Драйвер защиты загружается медленее, чем сервер защиты из автозагрузки. Вместо сервера защиты используйте Менеджер лицензий LMSETUP, который устанавливается, внимание, в качестве службы (Service) Windows!

В дополнение скажем, что при работе с 1С могут одновременно функционировать два и более менеджеров лицензий, но для предотвращения появления ошибок каждому менеджеру должно быть присвоено свое уникальное имя. Для этого используют файл nhsrv.ini, нужно изменить значение параметра NHS_SERVERNAMES в секции NHS_SERVER. Более того, необходимо сообщить эти имена каждой копии запущенной программы. Для этого используют nethasp.ini: в параметре NH_SERVER_ADDR указывают ip-адреса серверов, в параметре NH_SERVER_NAME указывают их имена в том же порядке, в котором были указаны адреса.

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

Что такое серия разработчика (или код ключей) и что такое Vendor ID?

Серия разработчика = Batch code = код разработчика = серия ключей – равнозначные понятия.

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

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

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

Batch code нанесён на корпус каждого ключа (как пользовательского, так и служебного) и выглядит как последовательность из нескольких латинских символов, вида: "CDQDR", "DEMOMA" и т.д.

DEMOMA – серия разработчика, присвоенная демонстрационным ключам. Серия DEMOMA интегрирована в комплект разработчика и предназначена для тестирования функционала комплекта разработчика. Для работы с ключами серии DEMOMA не требуется наличие Sentinel (HASP) HL Master ключа.

Vendor ID – числовой эквивалент серии разработчика, отображается в Sentinel Admin Control Center на вкладке Sentinel Keys в столбце Vendor для подключенного ключа. Исключение – служебные ключи Sentinel (HASP) HL Master и Sentinel (HASP) HL Developer. Для этих ключей Vendor ID всегда одинаковый – "64294" и отличен от Vendor ID серии разработчика клиента.

Vendor ID содержится в именах всех кастомизированных под данную конкретную серию разработчика библиотек Sentinel LDK Licensing API из комплекта разработчика.

Обновление прошивки (firmware) ключа HASP HL до версии 3.25

Обновление микропрошивки в стандартном режиме производится автоматически при соблюдении двух условий:

1. Наличия на ПК актуальной версии установленного драйвера для ключей Sentinel (HASP);
2. Наличия на ПК активного интернет соединения.

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

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

*Файл применяется к ключу с помощью: стандартной утилиты RUS под данную серию разработчика, либо через интерфейс драйвера – Sentinel Admin Control Center.

Процедура установки/удаления драйвера ключа

Для OS Windows Vista и ниже необходимо выполнять оба раздела инструкции, для Windows 7 и выше только "Раздел II".

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

Раздел I. Удаление драйверов версии 4.116 и ниже.

1. Войти в систему как администратор.
2. Если возможно, следует временно отключить любое защитное ПО (антивирус, брандмауэр).
3. Отключить все локальные Sentinel (HASP) ключи.
4. Загрузить драйвер 4.116: http://safenet-sentinel.ru/files/hasp4_driver_cmdline.zip для проверки, не установлено ли старых версий драйверов.
5. Распаковать загруженный архив на диск и в командной строке перейти в директорию с файлами из архива.
6. Запустить «hinstall –r –alldrv» для удаления версий, установленных ранее.
7. Если возникли проблемы с удалением, обратитесь к пункту настоящей инструкции «ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА».

Раздел II. Установка/удаление драйверов версии 5.х и выше.

1. Войти в систему как администратор.
2. Если возможно, следует временно отключить любое защитное ПО (антивирус, брандмауэр).
3. Скачать свежую консольную версию драйвера: http://safenet-sentinel.ru/files/sentinel_ldk_run-time_cmd.zip
4. Отключить все локальные Sentinel (HASP) ключи.
5. Разархивировать драйвер.
6. Выполнить из командной строки «haspdinst.exe –fr –kp –purge» для удаления версий, установленных ранее.
7. Выполнить «haspdinst.exe –i» для установки драйвера.
8. Если возникли проблемы с удалением, следует обратиться к пункту инструкции «ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА».
9. Открыть браузер и перейти по адресу http://localhost:1947; проверить, что ключ отображается на странице «Sentinel Keys».
10. Проверить, что приложение работает. Если нет:

• Использовать «MsConfig» для остановки всех служб, которые не относятся к Microsoft, перезагрузите компьютер и проверить снова.
• В случае отказа системы необходимо сохранить «дамп памяти ядра». Для его создания см. инструкцию: http://msdn.microsoft.com/en-us/library/cc266505.aspx
• В случае отказа Менеджера лицензий (HASP License Manager) необходимо сохранить лог (event log: Пуск -> Панель управления -> Администрирование -> Просмотр событий) и сохранить скриншот возникающей ошибки.
• Удалить файл "C:Windowsaksdrvsetup.log", запустить «haspdinst –i –v», сохранить созданный файл aksdrvsetup.log
• Запустить «MsInfo32» (Пуск -> выполнить -> msinfo32 -> Ввод), создать .NFO log и выслать его.

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

ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА

• Удалить все компоненты HASP через «Установка/удаление программ».
• Остановить все службы, которые содержат в названии «Hasp» или «HLServer».
• Удалить все файлы aks*.*, «hardlock.sys» и «haspnt.sys» из папки c:windowssystem32drivers» (если они не используются другими приложениями).
• Удаление драйверов в «Диспетчере устройств»:

o Зайти в «Панель управления»«Система».

o Перейти на вкладку «Оборудование» и откройте «Диспетчер устройств».

o Выбрать в меню «Показать скрытые устройства».

o Раскрыть пункт «Драйверы устройств не Plug and Play».

o Удалить каждый из следующих пунктов, если они присутствуют: «Hardlock», «Haspnt», «HASP fridge».

• Еще раз удалить драйверы с помощью команды «haspdinst –purge», а затем установить с помощью «haspdinst –i».

Работа с ключом на виртуальных машинах

Работа на виртуальных машинах ограничивается двумя факторами:

1. Используемой системой защиты.
2. Используемой платформой виртуализации.

Для каждой системы защиты есть свой список официально поддерживаемых платформ виртуализации, посмотреть который можно либо на сайте http://sentinelcustomer.safenet-inc.com/platformsupport/, либо в документации к используемому комплекту разработчика.

Некоторые платформы виртуализации не поддерживают проброс USB устройств с реальной машины в виртуальную, например Microsoft Virtual Server + Hyper-V.

При использовании виртуальных сред с балансировкой нагрузки может происходить блокировка работы программных ключей Sentinel (HASP) SL, так как при балансировке нагрузки виртуальная машина фактически "перемещается" с одного физического ПК на другой, вследствие чего изменяется параметр привязки CPU ID, подробнее см. "Ошибка SL Clone detected".

Ошибка: «HASP not found (-10), (-11), (Error 27), (H0027), Terminal services detected»

Возникновение данной ошибки возможно в следующих случаях.

1. При обнаружении программ терминального доступа типа Microsoft Terminal Server (в т.ч. служба RDP – Remote Desktop), Citrix Winframe/Metaframe и т.д. драйвер ключа блокирует доступ к ключу. Т.е. ключ не должен находиться на одной машине с активным терминальным ПО. Для систем защиты HASP HL и Sentinel HASP* разработчик защищенного приложения имеет возможность контролировать данную опцию, разрешая или запрещая работу на терминальном сервере. Для ключей HASP4 она задана жестко и не может быть отключена. Если вы являетесь пользователем защищенного ПО, то варианты решения данного вопроса следующие:
2. Остановить работу терминального сервера.
3. Разместить ключ на любом другом компьютере в сети, если ключ сетевой.
4. Обратиться к разработчику защищенного ПО.
5. Ошибка «HASP not found (-10)» также может возникать при запуске приложений, защищенных с помощью HASP4 под Windows Vista/Windows 7.

* Для стандартной Feature 0, которая есть во всех ключах по умолчанию, лицензионные ограничения изменять нельзя. При этом для всех локальных ключей Sentinel HL для Feature 0 запрещена работа в терминальном режиме, а для сетевых ключей Sentinel (HASP) HL Net и сетевых ключей Sentinel (HASP) HL NetTime – разрешена. Соответственно, если защита программ осуществляется через Sentinel LDK Envelope на Feature 0 (например, используется DataHASP, который для своей работы использует Feature 0), то защищённое таким образом ПО может работать на терминальном сервере только с сетевым ключом, в котором для Feature 0 разрешён терминальный режим. С локальными ключами ПО будет выдавать ошибку «HASP_TS_DETECTED = 27».

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

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

!Update!: в системе защиты Sentinel LDK (в актуальной версии SDK LDK), для локальных моделей ключей Sentinel HL, работающих в Driverless режиме (для всех моделей кроме Sentinel HL Basic), есть возможность записывать сетевые лицензии с разрешённой / запрещённой работой RDP и с подсчётом подключений: по станциям, по процессам и по логинам. Благодаря чему любую, изначально локальную модель ключа можно превратить в сетевую. Но этот функционал требует приобретения дополнительных лицензий (HL seats) на Ваш Мастер ключ.

Ошибка «HASP not Found (-3), (Error 7), (H0007)»

Возникновение данной ошибки возможно в следующих случаях.

• Ключ Sentinel (HASP) не подсоединен к компьютеру. Необходимо подсоединить ключ защиты.
• Подсоединен ключ Sentinel (HASP) другой серии (ключ от другого ПО). Необходимо подсоединить ключ требуемой серии (ключ от данного приложения).
• Сетевой ключ, подсоединенный к компьютеру в сети, на самом деле не является сетевым (сетевой ключ должен содержать в себе сетевую лицензию). Следует проверить установленный ключ и, в случае ошибки, подключить требуемый сетевой ключ Sentinel (HASP).
• На компьютере, где установлен сетевой ключ Sentinel (HASP), не запущен менеджер лицензий. Следует установить и запустить менеджер лицензий.
• На компьютере, где установлен ключ, или на компьютере, где запускается защищенное приложение, блокируется передача трафика по 475 или 1947 порту (активен firewall, брандмауэр windows, антивирусные программы также могут блокировать передачу по сети). Необходимо отключить все ПО, которое может блокировать доступ к ключу.