1с сервер linux hasp эмулятор

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Установка HASP License Manager в Linux (Debian / Ubuntu)

Установка HASP License Manager в Linux (Debian / Ubuntu)

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

Прежде всего подключим HASP-ключ к компьютеру и убедимся что он определился в системе, для этого выполните команду:

В выводе вы должны увидеть строки, содержащие Aladdin HASP.

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

Для работы с ключами и установки HASP License Manager для раздачи лицензий по сети мы будем использовать пакеты от российского разработчика Etersoft, найти их можно адресу http://download.etersoft.ru/pub/Etersoft/HASP/stable/x86_64/ (мы предполагаем что у вас 64-битная система), затем следует выбрать используемую вами ОС и скачать предлагаемые пакеты.

В нашем случае это будет Ubuntu 16.04, и мы будем скачивать их непосредственно на сервере, предварительно перейдя в домашнюю директорию:

Затем установим необходимые зависимости:

А после этого и сами пакеты:

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

На этом настройку можно считать законченной, но мы добавим некоторые настройки. Если вы сочетаете в своей сети аппаратные и программные лицензии, то может возникнуть потребность ограничить доступ к ключу отдельными узлами, диапазонами адресов или подсетями. Для этого откроем файл /etc/haspd/hasplm.conf и зададим опцию NHS_IP_LIMIT, файл содержит пример, в котором показано как можно указывать допустимые значения. Ниже мы разрешим доступ узлу 192.168.0.100 и диапазону 192.168.190-200:

После чего перезапустим службу:

На клиентах в большинстве случаев никаких настроек производить не надо, однако, если 1С:Предприятие не видит лицензии то следует внести изменения в файл С:\Program Files (x86)\1cv8\conf\nethasp.ini или С:\Program Files\1cv8\conf\nethasp.ini, для Linux систем — /opt/1C/v8.3/x86_64/conf/nethasp.ini:

Для контроля выданных ключом лицензий можно использовать утилиту Aladdin Monitor:

Как видим, использовать HASP-ключи в среде Linux совсем не сложно, а общие правила работы с ними ничем не отличаются от работы в Windows.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Настройка драйвера HASP ключа и раздачи HASPLM лицензий 1С линукс сервером по сети на CentOS_6.2_x64

Последние версии aksusbd, включающие в себя hasplm — не работают с 1С. Всё ставится на ура, но монитор не видит в сети ни лицензий, ни сервера. Единственно нормально заработавшей версией NetHASP оказалась 8.30…
После 2х дней шаманских плясок с бубном, перебором версий разных хаспов, курения тонн форумов и мануалов родилась эта статья. Выглядит как изобретение велосипеда, но на фоне леса различных версий софта и комбинаций вариантов конфигурации, думется целесообразным написать это:
Изначально нужно понимать, что мониторинг сети — дело не быстрое и нужно запастись терпением, ожидая результатов работы монитора «Aladdin AKS monitor».

Скачать с ftp.aladdin.com/pub/hasp/hl/linux соответствующие драйверы и скрипты:

ftp.aladdin.com/pub/hasp/hl/linux/hasplm_linux_8.30.tgz
ftp.aladdin.com/pub/hasp/hl/linux/HDD_Linux_dinst.tar.gz
ftp.aladdin.com/pub/hasp/hl/linux/HDD_RPM_RedHat_i386.tar.gz
всё распаковать и поставить:
1. распаковать и поставить aksusbd HDD_RPM_RedHat_i386.tar.gz, внутри папка HDD_RPM_RedHat_i386, в ней RPM — aksusbd-redhat-1.10-1.i386.rpm
выполняем от пользователя root:
#yum install ./aksusbd-redhat-1.10-1.i386.rpm
потом распаковываем HDD_Linux_dinst.tar.gz
заходим в папку HDD_Linux_dinst запускаем скрипт (с точкой в конце)
#./dinst.
Драйвер HASP ключа установлен.

HASPLM — менеджер лицензий:
распаковывать RPM, установить:

#yum install ./hasplm-redhat-8.30-1.i386.rpm
создаем файл /etc/hasplm/nethasp.ini
зайти в гноме Система->Администрирование->Cлужбы и включить/запустить
aksusbd и
если через 10-15 минут Aladdin AKS монитор не видит сервера лицензий нужно проверить наличи компонентов hasplm в etc/rc.d/init.d /usr/sbin
если сервер есть но в нем нет ключей HASP, то не подцепился aksusbd
вынуть ключ, подождать 15 сек, вставить обратно и дать команду:
#service aksusbd restart
#service hasplm restart
если не помогает — то нужно сделать следующее:
#yum remove ./aksusbd-redhat-1.10-1.i386.rpm
#yum install ./aksusbd-redhat-1.10-1.i386.rpm
зайти в папку HDD_Linux_dinst и запустить скрипт (с точкой в конце)
#./dinst.

вообще, когда менеджер лицензий работает, то диагностика выглядит так:
#cat /var/log/syslog/messages | grep aks
aksusbd[11111]: loaded, daemon version: 1.8.1, key API (USB) version: 3.85 (parallel driver not available)
# netstat -anp | grep aks
unix 2 [ ACC ] STREAM LISTENING 12239 2050/aksusbd /tmp/.aksusb
unix 3 [ ] STREAM CONNECTED 120221 2050/aksusbd /tmp/.aksusb
unix 3 [ ] STREAM CONNECTED 99401 2050/aksusbd /tmp/.aksusb
unix 3 [ ] STREAM CONNECTED 19200 2050/aksusbd /tmp/.aksusb
unix 2 [ ] DGRAM 12238 2050/aksusbd

# netstat -anp | grep hasp
udp 0 0 0.0.0.0:475 0.0.0.0:* 2082/hasplm
unix 3 [ ] STREAM CONNECTED 120220 2082/hasplm
unix 2 [ ] DGRAM 12315 2082/hasplm

Источник

Установка 1C Server + Postgres PRO + Apache + Эмулятор HASP в Centos 8

1C Server + Postgres Pro + Apache + HASP

Подготовка

Обновляемся, добавляем репозиторий EPEL, устанавливаем софт

Изменим hostname сервера

На клиентской машине сервер должен отвечать на ping по доменному имени

Установка Postgres PRO

Добавляем репозиторий Postgres Pro

Устанавливаем PostgreSQL PRO std

Удаляем базу, которая создалась по-умолчанию

Инициализируем БД, модифицируем настройки под работу с 1с и добавляем поддержку русского языка

без —locale=… выскакивает ошибка: порядок сортировки не поддерживается базой данных

Добавляем сервис в автозагрузки и проверяем доступность порта 5432

Настройка Postgres PRO

Разрешим авторизовываться пользователям из нашей сети

Создадим пароль для пользователя postgres

Перезапускаем сервис postgrespro-std-12

Установка сервера 1C

Для начала необходимо скачать дистрибутив server 1c под linux в каталог /tmp
Сделать это можно с официального сайта, либо поискать в интернете

Распаковываем архив с дистрибутивом и устанавливаем

Меняем владельца и группу директории /opt/1C

Добавляем сервис srv1cv83 в автозагрузку, запускаем его и проверяем статус

Настройка сервера 1C

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

Редактируем конфигурационный файл сервера 1с srv1cv83, указываем путь к новому каталогу

Перезапускаем сервис srv1cv83 и проверяем статус

Установка и настройка драйвера HASP

Устанавливаем необходимую утилиту

В этой строчке перечислены сети и хосты, которые смогут видеть HASP-ключ

Перезапускаем сервис haspd, смотрим статус

Настройка Firewalld

Создание базы 1с (на windows-машине через консоль администрирования серверов 1С Предприятия)

Запускаем консоль администрирования серверов 1С Предприятия
Правой кнопкой мыши (ПКМ):

Кластер «Local cluster» при этом будет создан автоматически

Теперь создаем информационную базу

Установка шрифтов для подготовки к публикации web-сервера

Установка необходимых пакетов

Так же нам нужен пакет cabextract, но под Centos 8 в базовых репозиториях его нет. По-этому скачиваем его из стороннего источника и устанавливаем

Скачиваем файл спецификации для установки шрифтов microsoft

Подготавливаем пакет шрифтов

При выполнении команды rpmbuild … должны скачаться все шрифты, и собраться пакет. Если в процессе выполнения команды появится ошибка, например: «Connection timed out, не удалось разрешить адрес зеркала», нужно запустить команду еще раз.

Устанавливаем пакет шрифтов

Установка web-сервера Apache

Добавляем его в автозагрузку, запускаем и смотрим статус

Создадим каталог, он будет использован как путь публикации для web-сервера 1с

Создадим пустой файл, он будет указан в качестве конфигурационного файла web-сервера 1с

Далее публикуем базу 1С

Меняем владельца и группу созданного файла, перезапускаем Apache

Настройка SELinux

Создаем файл с описанием политик web 1с для Selinux

Cомпилируем и установим политику

Перезапустим сервер Apache

В моем случае верхнее правило не помогло, пришлось поступать следующим образом:

Анализируем лог, компилируем и устанавливаем еще одну политику

Проверяем в браузере:

Или через тонкий клиент 1С по тому же адресу.

На этом установка Сервера 1с с базой данных PostgreSQL и публикацией сервера в web завершена. Можно подключать USB-ключ с лицензией к серверу и работать.
Но, если вы разворачиваете ради тестирования, можно установить эмулятор HASP.

Установка эмулятора HASP в Centos 8 из исходников

Устанавливаем утилиты сборки

Устанавливаем заголовки ядра

Устанавливаем утилиты для сборки зависимостей

Скачиваем исходники VHCI_HCD, LIBUSB_VHCI и USB_HASP в каталог /usr/src

Распаковываем исходники VHCI_HCD и LIBUSB_VHCI

Загружаем модуль usb_vhci_hcd

Загружаем модуль usb_vhci_iocifc

Создаем директорию для дампов usb-ключей

Создаем системный unit usbhaspemul.service

Добавляем службу usbhaspemul в автозагрузку

Загружаем дампы usb-ключей в каталог /etc/usbhaspkey/ (дампы искать в интернете)

Пробуем запустить USB HASP Emulator, проверяем статус

Разное

Сервер разворачивался в VirtualBox, параметры:

Источник

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-пакеты. Здесь все уже зависит от конкретной версии ключа и защищаемой программы.

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

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

Источник