Программа для hasp ключа

Защита системы «1С:Предприятие» может быть построена на использовании сетевой системы защиты HASP4 Net. Подсчет пользователей при этом, может осуществляться либо серверной частью «1С:Предприятия», либо специальной программой — HASP License Manager. Эта статья посвящена установке HASP License Manager и настройке системы «1С:Предприятие» для работы с ним.

Ключи защиты и их маркировка

Аппаратные ключи защиты HASP4 Net подключаются к USB-портам компьютера. Общее количество пользователей, которые могут работать с системой «1С:Предприятие» равняется сумме доступных лицензий со всех компьютеров в сети, к которым подключены аппаратные ключи и настроен HASP License Manager.

Аппаратные ключи похожи на USB-флеш-накопитель и выглядят примерно вот так:

Многопользовательский клиентский ключ H4 NET5 ORGL8

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

• ORGL8 — Локальный клиентский ключ;
• NET5 ORGL8 — Многопользовательский клиентский ключ на 5 пользователей;
• NET10 ORGL8 — Многопользовательский клиентский ключ на 10 пользователей;
• NET20 ORGL8 — Многопользовательский клиентский ключ на 20 пользователей;
• NET50 ORGL8 — Многопользовательский клиентский ключ на 50 пользователей;
• NET100 ORGL8 — Многопользовательский клиентский ключ на 100 пользователей;
• NET250+ ORG8A — Многопользовательский клиентский ключ на 300 пользователей;
• NET250+ ORG8B — Многопользовательский клиентский ключ на 500 пользователей;
• ENSR8 — Локальный ключ 32-разрядного сервера;
• EN8SA — Локальный ключ 64-разрядного сервера.

Так, на фотографии выше представлен многопользовательский клиентский ключ на 5 пользователей.Нужно отметить, что на одном компьютере может работать только один ключ каждой серии (ORGL8, ORG8A и ORG8B). Если подключить к одному компьютеру несколько ключей одинаковой серии, то будет задействован только один из них, выбранный произвольно.

Установка драйвера защиты

HASP Device Driver требуется установить на тех компьютерах к которым непосредственно подключены аппаратные ключи защиты. Этот драйвер входит в комплект поставки «1С:Предприятия» и его можно установить из меню «Пуск»:

Установка драйвера защиты из меню «Пуск»

Или из командной строки:

C:>"Program Files1cv8commonhaspdinst.exe" -i

Для ОС Linux нужно скачать драйвер с сайта компании SafeNet. Скачанный архив содержит DEB-пакет для Ubuntu/Debian, RPM-пакет для RedHat/SuSE и скрипт для автоматической установки. Попробуем вариант со скриптом, для этого скачаем и распакуем нужный архив. Далее сделаем исполняемым файл dinst и запустим его:

sudo chmod +x ./dinst

Результат будет выглядеть примерно так:

Установка драйвера в ОС Linux

Установку драйвера в любой операционной системе рекомендуется производить с отсоединенным USB-ключом.

Установка HASP License Manager

Дистрибутив HASP License Manager можно найти на сайте компании SafeNet. При установке в ОС Windows нужно будет выбрать вариант установки — приложение или служба, обычно выбирают службу:

Установка HASP License Manager

В ОС Linux установка HASP LM выглядит немного сложнее. Архив с сайта SafeNet содержит два RPM-пакета для RedHat и SuSE (вероятно, для этих систем установка HASP LM достаточно проста) и запакованный файл hasplm для всего остального. Следуя инструкции с сайта ИТС у меня не получилось запустить файл hasplm на Ubuntu 16.04.

Поэтому пришлось воспользоваться решением от компании Etersoft. Идем на FTP компании и находим нужную версию. Для моей 64-х битной Ubuntu 16.04 я выбрал эту версию: http://ftp.etersoft.ru/pub/Etersoft/HASP/stable/x86_64/Ubuntu/16.04/. Скачиваем файлы и в начале устанавливаем необходимые пакеты, в моем случае потребовалось установить пакет make:

sudo apt-get install make

и пакет libc6-i386 (несмотря на то, что я скачал 64-х битную версию HASP LM, он, по сути, остается 32-х битным приложением и ему требуются 32-х битные библиотеки):

sudo apt-get install libc6-i386

после этого устанавливаем пакеты HASP LM:

sudo dpkg -i haspd_7.60-eter1ubuntu_amd64.deb

sudo dpkg -i haspd-modules_7.60-eter1ubuntu_amd64.deb

sudo service haspd restart

HASP LM на Ubuntu 16.04

Как видно из скриншота, файл с настройками находится тут: /etc/haspd/hasplm.conf .

Настройка

nhsrv.ini

В ОС Windows файл nhsrv.ini может располагаться в различных местах:

• каталог с установленным HASP LM (например, C:Program Files (x86)AladdinHASP LM );
• каталог Windows ( C:Windows );
• системный каталог Windows ( C:Windowssystem32 или C:Windowssystem ).

Для ОС Linux файл настроек указывается при помощи параметра «-c» и его название и местоположение по умолчанию не определено.

Настройка HASP LM задаются значениями параметров секции [NHS_SERVER] файла nhsrv.ini:

• NHS_IP_LIMIT — определяет диапазон IP-адресов, обслуживаемых HASP LM. Например: 192.168.*.*, 192.168.1.1/24.
• NHS_ADAPTER — определяет IP-адрес одной или более сетевых карт, которые будут обслуживать HASP LM. Применяется при использовании HASP LM с Win32. Например: 10.1.1.111, 255.255.0.0.
• NHS_USERLIST — определяет максимальное количество пользователей, одновременно подключенных к HASP LM Значение по умолчанию: 250 (важно для ключей на 300 и 500 пользователей).

nethasp.ini

Для настройки взаимодействия системы «1С:Предприятия» с HASP LM используется конфигурационный файл nethasp.ini. Несмотря на то, что в большинстве случаев никакая дополнительная настройка не требуется полезно иметь представление о возможностях предлагаемых этим файлом.

Файл nethasp.ini, в ОС Windows, обычно располагается в каталоге 1С (например C:Program Files1cv8conf ), а в ОС Linux он может находиться в домашнем каталоге пользователя или в каталоге /etc .

В примере ниже указывается, что сервер защиты находится по адресу 192.168.0.12 и запрещается широковещательный механизм TCP/IP.

[NH_COMMON]
NH_TCPIP=Enabled
[NH_TCPIP]
NH_SERVER_ADDR=192.168.0.12
NH_USE_BROADCAST=Disabled

Далее рассмотрим прочие параметры, доступные в файле nethasp.ini.

Секция [NH_COMMON]

• NH_IPX — использовать или не использовать протокол IPX для связи с HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
• NH_NETBIOS — использовать или не использовать протокол NetBIOS для связи с HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
• NH_TCPIP — использовать или не использовать протокол TCP/IP для связи с HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
• NH_SESSION — задает интервал в секундах, в течение которого программа пытается установить соединение с HASP LM (по умолчанию 2 секунды);
• NH_SEND_RCV — устанавливает для HASP LM максимальное время получения или отправки пакета (по умолчанию 1 секунда).

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

Секция [NH_IPX]

• NH_USE_SAP — использовать или не использовать службу SAP для поиска в сети HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
• NH_USE_BROADCAST — использовать только механизм Broadcast для поиска в сети HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
• NH_BC_SOCKET_NUM — определяет номер сокета (число в шестнадцатеричном виде) для широковещательного механизма (по умолчанию: 7483Н);
• NH_SERVER_NAME — определяет, будет ли приложение обмениваться данными только с HASP LM, находящимся в локальной сети, или с любыми другими HASP LM, варианты: localnet, Internet (по умолчанию Internet);
• NH_DATFILE_PATH — путь, по которому будет производиться поиск файлов haspaddr.dat и newhaddr.dat, содержащих сетевой адрес HASP LM.

Секция [NH_NETBIOS]

• NH_NBNAME — задает имя HASP LM (не более 8 символов);
• NH_USELANANUM — устанавливает номер коммуникационного канала.

Секция [NH_TCPIP]

• NH_SERVER_ADDR — устанавливает IP-адреса серверов HASP LM (количество адресов не ограниченно);
• NH_SERVER_NAME — обменивается данными с HASP LM с определенным именем (максимум 6 имен, каждое не более 7-ми символов);
• NH_PORT_NUMBER — устанавливает номер сетевого порта (по умолчанию 475);
• NH_TCPIP_METHOD — посылает пакет TCP или UDP, обращение к HASP LM всегда выполняется по UDP, независимо от значения этого параметра;
• NH_USE_BROADCAST — использовать широковещательный механизм UDP, варианты: Enabled, Disabled (по умолчанию Enabled).

На этом все, надеюсь, что данная статья была Вам полезна.

Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Программные продукты «1С:Предприятие» версии 8 помимо системы программного лицензирования могут быть защищены от копирования аппаратными LPT или USB ключами типа HASP4 Net от фирмы Aladdin. В данной статье приведена информации о типе, маркировке и назначении различных ключей HASP4 Net от «1С:Предприятие». А также обзор программных продуктов от фирмы Aladdin, служащих для установки, настройки и администрировании этих ключей (для ОС семейства Windows).

0. Оглавление

1. Маркировка и назначение ключей

Все ключи HASP4 Net условно можно разделить на 2 типа «Клиентские» и «Серверные»:

• Клиентские служат для выдачи лицензий пользователям Windows при запуске «1С:Предприятие» 8. Данные ключи могут быть установлены на любой компьютер в локальной сети. Обслуживанием ключей в данном случае занимается программа HASP HL License Manager.
• Серверный ключ необходим для того, чтобы запускалась служба сервера «1С:Предприятие». Он должен быть установлен непосредственно на тот же самый компьютер, где и запущена данная служба. Служба может иметь разрядность x86 или x64.

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

Таблица видов ключей HASP 1С:Предприятие 8

Тип / цвет	Маркировка / серия	Назначение
ОДНОПОЛЬЗОВАТЕЛЬСКИЕ ВЕРСИИ ОСНОВНЫХ ПОСТАВОК И КЛИЕНТСКИХ КЛЮЧЕЙ

H4 M1 ORGL8

• 1C:Бухгалтерия 8 ПРОФ
• 1С:Бухгалтерия 8 ПРОФ. Поставка для розничного распространения
• 1С:Бухгалтерия 8 КОРП
• 1С:Бухгалтерия бюджетного учреждения 8
• 1С:Бухгалтерия автономного учреждения 8 ПРОФ
• 1С:Бухгалтерия автономного учреждения 8 КОРП
• 1С:Управление торговлей 8
• 1С:Зарплата и Управление Персоналом 8
• 1С:Зарплата и кадры бюджетного учреждения 8
• 1С:Управление небольшой фирмой 8
• 1С:Комплексная автоматизация 8
• 1С:Предприятие 8. Управление производственным предприятием
• 1С:Документооборот 8
• 1С:Предприятие 8. Клиентская лицензия на 1 рабочее место

СЕТЕВЫЕ ВЕРСИИ ОСНОВНЫХ ПОСТАВОК И МНОГОПОЛЬЗОВАТЕЛЬСКИЕ КЛЮЧИ

USB HASP HL Net

H4 NET5 ORGL8

• 1С:Бухгалтерия 8. Комплект на 5 пользователей
• 1С:Бухгалтерия 8 ПРОФ на 5 пользователей. Поставка для розничного распространения
• 1С:Предприятие 8. Комплект прикладных решений на 5 пользователей

H4 NET5 ORGL8

• 1С:Предприятие 8. Клиентская лицензия на 5 рабочих мест

H4 NET10 ORGL8

• 1С:Предприятие 8. Клиентская лицензия на 10 рабочих мест

H4 NET20 ORGL8

• 1С:Предприятие 8. Клиентская лицензия на 20 рабочих мест

H4 NET50 ORGL8

• 1С:Предприятие 8. Клиентская лицензия на 50 рабочих мест

H4 NET100 ORGL8

• 1С:Предприятие 8. Клиентская лицензия на 100 рабочих мест

NET250+ ORG8A

• 1С:Предприятие 8. Клиентская лицензия на 300 рабочих мест

NET250+ ORG8B

• 1С:Предприятие 8. Клиентская лицензия на 500 рабочих мест

КЛЮЧИ НА СЕРВЕР 1С:ПРЕДПРИЯТИЕ 8.*

USB HASP HL Pro

H4 M1 ENSR8

• 1С:Предприятие 8. Лицензия на сервер (х32).

USB HASP HL Max

Max EN8SA

• 1С:Предприятие 8. Лицензия на сервер (x86-64).

КОМПЛЕКТЫ

USB HASP HL Net

USB HASP HL Pro

• 1С:Предприятие 8. Управление производственным предприятием для 10 пользователей + клиент-сервер. В комплект поставки входит два ключа: Многопользовательский на 10 рабочих мест и на сервер 1С:Предприятия 8.* (х32)

• 1С:Комплексная автоматизация 8 для 10 пользователей + клиент-сервер. В комплект поставки входит два ключа: Многопользовательский на 10 рабочих мест и на сервер 1С:Предприятия 8.* (х32)

• 1С:Предприятие 8. Комплект для обучения в высших и средних учебных заведениях. В комплект поставки входит два ключа: Многопользовательский на 20 рабочих мест и на сервер 1С:Предприятия 8.* (х32)

Размер USB-ключей может отличаться от размера ключей изображенных на рисунках. Программные продукты системы «1С:Предприятие» выпускавшиеся до 2009 г. комплектовались USB-ключами в более длинном форм-факторе — 52 мм. Цветовая схема и маркировка ключей осталась без изменений.

2. Что нужно знать при установке ключей

Есть несколько особенностей, которые следует принять во внимание перед установкой ключей HASP, а именно:

1. Общее число пользователей, которые могут работать с системой «1С:Предприятие» равно сумме лицензий, доступных в каждом из клиентских ключей.
2. На одном физическом компьютере не могут работать 2 и более ключа одной Серии, т. к. эти ключи неразличимы и фактически будет задействован только один из них (выбранный произвольно). Серию ключа можно определить по последним 5 символов в маркировке (ORGL8, ORGL8A, ENSR8 и т.д.). Ключи разных серий без проблем могут быть установлены на один компьютер.
3. Клиентские ключи могут быть установлены на любой компьютер в сети (если запущен HASP License Manager).
4. При наличии нескольких ключей, лицензии выдаются в следующем порядке:
5. в ключе серии ORGL8
6. в ключе серии ORGL8A
7. в ключе серии ORGL8B
8. Действует также «запоминание ключа», т. е. при повторном обращении сначала будет выполнена попытка получении лицензии из ключа, чья лицензия была получена пользователем при последнем подключении.
9. Серверный ключ должен быть установлен непосредственно на тот же самый компьютер, который используется в качестве сервера кластера «1С:Предприятия» . По сети он работать не будет.
10. Серверные 64-битные ключи также можно использовать и в 32-битных системах.
11. Есть определенные проблемы с пробросом серверного ключа из физической среды в виртуальную на некоторых гипервизорах. Например, мне так и не удалось штатными средствами пробросить серверный ключ в виртуальную машину в Hyper-V на Windows Server 2008 R2.
12. COM-соединение также требует лицензию.
13. Для работы Web-сервисов не требуется клиентских лицензий.
14. Полный алгоритм поиска лицензии при старте «1С:Предприятие» для версии 8.3 описан здесь, для версии 8.2 — здесь.

3. Особенности учета клиентских лицензий

Клиент «1С:Предприятие» при запуске может использовать для получения лицензий:

• Локальный ключ — ключ установленный на физический компьютер, с которого запускается «1С:Предприятие». Дает право запуска на компьютере c ключом из под одной сессии Windows произвольного количества экземпляров системы в режиме 1С:Предприятие или Конфигуратор. При работе в терминальном режиме позволяет работать только одному пользователю, который подключился к терминальной сессии с идентификатором 0.
• Многопользовательский ключ, доступный по сети через HASP License Manager — Обеспечивает одновременную работу стольких компьютеров, на сколько пользователей имеется ключ. Аналогично локальному ключу на одном компьютере в одной сессии Windows возможен запуск произвольного количества экземпляров системы в любом режиме в рамках одной лицензии. При работе в терминальном режиме также требуется установка HASP License Manager.
• Сервер «1С:Предприятие» или модуль расширения веб-сервера — Помимо программы HASP License Manager лицензии также могут выдаваться и сервером «1С:Предприятие» или модулем расширения веб-сервера (только в случае работы с файловой базой через Web-клиент). При этом подсчетом лицензий занимается непосредственно сервер «1С:Предприятие» или модуль расширения веб-сервера. В этом случае, в отличии от двух предыдущих вариантов, лицензии расходуются из расчета «один сеанс — одна лицензия». Таким образом, если на одном компьютере запущено два экземпляра «1С:Предприятие», то будет затрачено две лицензии.

Кроме того очень важно знать и учитывать следующую особенность: если в сети будет обнаружено несколько многопользовательских клиентских ключей серии ORGL8, то сервером будет выбран один произвольный ключ. После исчерпания лицензий этого ключа возможно использование одного многопользовательского ключа ORG8A, и затем возможно использование одного многопользовательского ключа ORG8B.

4. Программы для администрирования ключей HASP

4.1 HASP Device Driver

На момент написания статьи актуальной была версия 6.62.1. Скачать можно с официального сайта или с текущего.

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

4.2 HASP HL License Manager

На момент написания статьи актуальной была версия 8.32.5. Скачать можно с официального сайта или с текущего.

Менеджер лицензий — это утилита, которая служит связующим звеном между сетевым ключом и «1C», запускаемой на удаленной машине. При установке HASP License Manager автоматически создает правило в Брандмауэре Windows. Однако, для работы защищенного приложения на удаленной рабочей станции необходимо проверить, что осуществляется беспрепятственный проход UDP- и TCP-пакетов по 475 порту в обе стороны. Устанавливать менеджер желательно как службу, выбрав «Service (nhsrvice.exe)» во время установки.

Ну а после установки должна появиться соответствующая служба.

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

4.3 Aladdin HASP Monitor

На момент написания статьи актуальной была версия 8.32.5. Скачать можно с официального сайта или с текущего.

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

Следует понимать, что сам по себе монитор может показать только наличие менеджера лицензий на том или ином адресе. Ключ он сможет увидеть только после того, как защищенное приложение успешно откроет хотя бы одну сессию с ключом. Кроме того, следует учитывать, что Aladdin Monitor работает только по протоколу UDP, порт 475, так что для работы программы необходимо добавить соответствующее правило в брандмауэр Windows. Таким образом, отсутствие данных о ключе в мониторе еще не означает, что ключ недоступен для приложения.

5. Просмотр полученной лицензии в 1С

Перечень всех видимых ключей, а также место получение текущей лицензии можно посмотреть и непосредственно из «1С:Предприятие». Достаточно запустить 1С в режиме 1С:Предприятие, в меню выбрать «Справка» — «О программе…» или нажать пиктограмму с изображением восклицательного знака на панели.

В открывшемся окне информацию о лицензиях можно просмотреть в пункте «Лицензия».

Здесь мы увидим ключ выдавший лицензию данному пользователю, а также все видимые ключи сети. Информация о выданных лицензиях присутствует также и в Консоли Администрирования Серверов «1С:Предприятие» в списке сеансов информационной базы (начиная с версии платформы 8.2.15).

Смотрите также:

Ниже будет подробно описан процесс установки типовой конфигурации в системе «1С:Предприятие» 8.3 (в версиях 8.2 и 8.1 действия аналогичны) в ОС семейства Windows, на примере решения «Бухгалтерия предприятия, редакция 3.0».…

В данной статье будет подробно рассмотрен алгоритм установки клиентской части системы «1С:Предприятия» 8.3 (для версий 8.2, 8.1 и 8.0 алгоритм установки аналогичен, об установке системы «1С:Предприятия» 7.7 я писал здесь) в операционных системах семейства…

При запуске клиент «1С:Предприятие» выполняет поиск клиентской лицензии. Алгоритм поиска лицензии не столь тривиален. Ниже приведен данный алгоритм для различных режимов запуска «1С:Предприятие», а также алгоритм поиска лицензии при запуске сервера «1С:Предприятие», для версии «1С:Предприятие»…

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

В этой статье описаны способы обхода аппаратных систем защиты. В качестве примера рассмотрена технология 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-пакеты. Таким образом можно добавить неплохой инструмент в свой сделанный на коленке набор. Удачи!