Как сделать копию электронного ключа guardant

Обновлено: 05.07.2024

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

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

Взглянем

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

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

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

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

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

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

Как уже отмечалось, идея перехвата состоит в перезаписи обработчиков 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;

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

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Господа! Возникла необходимость использовать эмуляторы USB ключей. Сразу хочу оговориться, что сами ключи в наличии, метод их получения совершенно валиден, но по определенным обстоятельствам хотелось бы их не использовать, что бы оптимизировать их замену, без прибегания к физическому "втыканию" и "вытыканию" в USB порт. Для этого необходиом ПО для анализа ключа, и снятия дампа в файл. Так же необходим универсальный эмулятор который будет эмулировать под виндой USB ключ, с подпихнутым в него соответсвующим дампом. У кого-то есть практическое понимание этого вопроса?

Советую поинтересоваться у производителя ключа либо у распространителя (у производителя продукта, использующего ключ)
Это раз.
Два: что за ключ?

раз. производитель не заинтересован в том что бы давать рекомендации относительно того как ключ можно скопировать и избежать его физическое использование.
два. Ключи USB, один определяется виндоусом как SmartKey iKey 1000 Rainbow, а другой вообще не известно что, в системе никак не анонсируется, а софтина работающая с ним видит его напрямую.

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

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

производитель свистка или производитель софтины = заказчик свистка и технологии у производителя свистка ?

Для обновления ключа защиты Guardant, используется утилита gsremote.exe.

"Обновление ключа защиты Guardant.zip"

1) Согласовать обновления локального ключа защиты с технической

поддержкой по программному обеспечению.

2) Сформировать файл-вопрос через утилиту gsremote.exe;

4) Получить в ответном письме файл-ответ;

5) Загрузить файл-ответ в утилиту gsremote.exe;

6) Завершить процедуру удаленного программирования ключа.

1) Свяжитесь с технической поддержкой по программному обеспечению "Топаз-АЗС", "Топаз-Нефтебаза", "Топаз-офис" по телефонам:

Добавочный номер "2". Звонить по будням, с 8:00 до 12:00, с 12:45 до 16:45 по московскому времени;

Согласуйте время обновления и электронную почту для связи.

2) Сообщите номер ключа защиты Guardant и номер счёта, по которому приобретено программное обеспечение;

3) Убедитесь, что подключен ТОЛЬКО тот ключ защиты, который

необходимо прошить (уберите другие ключи).




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

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

Пример текста письма:


7) Дождитесь ответного письма и сохраните файл-ответ из вложения *.

Время ответа составляет не более 20 минут.


* Если сетевой ключ защиты Guardant, используется совместно с ПО "Топаз-Офис", в ответном письме будет прислан файл-ответ и файл лицензии TopazAZS.lic.

Замените файл \RemoteServer\TopazAZS.lic из каталога TopazOffice на присланный

Вам файл-лицензию. Предварительно сделайте резервную копию заменяемого файла.

* Если сетевой ключ защиты Guardant, используется совместно с ПО "Топаз-Автономный налив" , в ответном письме будет прислан файл-ответ и файл лицензии Lic00ХХХХ.xml, где ХХХХ - номер лицензии. Остановите Сервер 186 и поместите данный файл в каталог с Сервером 186. Старый файл Lic00ХХХХ.xml уберите из каталога, но сохраните резервную копию.

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

Зачем копировать сертификаты ЭЦП

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

Перенос ключа эцп на рабочий стол

Способы копирования ЭЦП

Существует несколько способов, как выгрузить сертификаты ЭЦП на рабочий стол. Для этого можно использовать программу КриптоПро, проводник Windows или консоль.

Извлечение сертификата из контейнера

Как извлечь сертификат из контейнера закрытого ключа:

Просмотр ключей в контейнере

Обзор контейнеров

Выбор закрытого ключа

Продолжение переноса ключа эцп

Введение пин-кода

Свойства закрытого ключа

Копирование закрытого ключа

Мастер экспорта ключей

  • В следующем рабочем окне выбирают первый пункт кодировки.

Кодировка закрытого ключа

Сохранение файла закрытого ключа

Копирование закрытого ключа в реестр

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

Копирование в КриптоПро

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

Выбор ключевого контейнера

Копирование контейнера закрытого ключа эцп

Переход в реестр эцп

Для установки скопированного сертификата нужно:

Просмотр ключа эцп в контейнере

Выбор нужного контейнера эцп

  • Проверить данные сертификата, срок действия и фио или иные данные.

Проверка данных

Экспорт сертификата с закрытым ключом прошел успешно, и теперь для работы с ЭЦП не нужно больше подключать носитель.

Копирование при помощи мастера экспорта ключей

Есть еще один способ переноса электронной подписи на компьютер. Для этого необходимо проделать следующие действия:

Свойства обозревателя закрытых ключей эцп

Экспорт ключа эцп

Мастер экспорта эцп

Выбор опций экспорта ключа эцп

  • Выбрать первый пункт (файлам с расширением Х.509).

Выбор расширения

Перенос эцп

Имя экспортируемого файла

Завершение переноса ключа эцп

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

Массовое копирование

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

Для копирования необходимо узнать SID пользователя. Сделать это можно при помощи команды wmic useraccount where name=’zerox’ get sid.

Для копирования контейнеров в файл нужно открыть редактор реестра и перейти в ветку: \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Crypto Pro\Settings\Users\S-1-5-21-4126079715-2548991747-1835893097-1000\Keys.

Затем пользователь выбирает и экспортирует папку Keys.

Папка закрытых ключей эцп

Ветку с закрытыми ключами сохраняют в отдельный файл. Теперь нужно скопировать все сертификаты. В OS Windows 7 и старше они находятся в директории C:\Users\zerox\AppData\Roaming\Microsoft\SystemCertificates\My. Для переноса ветку реестра копируют, затем открывают в текстовом редакторе и меняют значение SID для нового ПК или пользователя.

Остается лишь запустить файл с расширением .reg и загрузить данные в реестр. После этого пользователь копирует папку с сертификатами на другой компьютер.

Как привязать сертификат к контейнеру

Для привязки сертификата ключа электронной подписи к контейнеру нужно:

Установка личного ключа эцп

Выбор файла личного ключа

Расположение файла ключа эцп

Выбор файла для переноса

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

Выбор ключевого контейнера эцп

  • При необходимости сертификат можно поместить в личное хранилище или любое другое место на ПК.

Выбор хранилища для закрытого ключа эцп

Привязка к контейнеру завершена

На этом привязка сертификата к контейнеру завершена.

Ошибка при копировании контейнера

Если при создании ключа электронной подписи он не был помечен как экспортируемый, то скопировать или скачать его на ПК с токена не получится. Система выдаст ошибку копирования (0x8009000B (-2146893813)).

Перенос эцп с токена

Выбор эцп для переноса

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

Эскпорт закрытого ключа

При правильной последовательности появляются два файла: .pfx и .cer.

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

Копирование закрытого ключа электронной подписи нужно в нескольких случаях: при частых путешествиях и в работе с нескольких ПК. Также перенести ключ ЭЦП на рабочий стол можно и для того, чтобы избежать порчи и потери USB-носителя. Процесс копирования проходит в несколько последовательных шагов, а выбрать можно для этого любой удобный способ. Это может быть простое извлечение ключа из закрытого контейнера, копирование при помощи КриптоПро или системный проводник. Ошибки при работе могут возникнуть только в случае защищенного от экспорта сертификата. Тогда пользователю придется произвести копирование при помощи браузера Internet Explorer.

Читайте также: