No Image

Что такое эмулятор ключа

СОДЕРЖАНИЕ
1 просмотров
22 января 2020

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

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

Читайте также:  Телефон bq next music

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

Читайте также:  120 Гб ssd накопитель kingston a400 обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:  Титанфалл 2 обзор видео

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

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

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

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

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

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

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

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

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

Запустить защищенную программу, проверить ее работу, далее, если все работает, открыть окно «DUMPER». В окне отображаются пароли. Для создания копии нажать «DUMP». Результат – файл типа .dmp.

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

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

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

Можно пользоваться. &#128578;

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

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

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

Удалить ярлык эмулятора – C:Documents SettingsAll usersStartМenuProgramsStartup

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

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

Запустить startnt.bat. ПУ – система – Оборудование -ДУ

Меню View-ShowHiddenDevice – Нажать NonPlag… -Scan for hardware …

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

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

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

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

Замечание . Приведенные инструкции – это примеры, на которые нужно ориентироваться в реальной обстановке.

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

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

What one person has done, another can break always.

MultiKey

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

  • Hasp3/4 , Hasp HL , Hasp SRM
  • Hardlock
  • Sentinel superpro , ultrapro
  • Guardant Stealth I , Stealth II
  • Dinkey

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

Лицензирование

Эмулятор MultiKey можно свободно скачать на странице загрузок.

Для возможности использования эмулятора необходимо иметь рабочий дамп вашего ключа в виде рег-файла, а также

. Запущен онлайн сервис для генерации лицензий для Multikey 19.1.8 x 32 >>> get license.

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

Внимание! Все решения эмулятора MultiKey антивирусные компании постоянно относят к вирусам и троянам. Это происходит из-за высокой защиты эмулятора протектором и антивирусы не в состоянии анализировать файл.

Лицензирование бесплатно для таких типов ключей :

  • Все типы ключей (кроме Hasp SRM) для 32-битных ОС без привязки к оборудованию.

Лицензирование ключей HASP SRM а также версий под 64-бит ОС производится по договоренности.

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

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

Комментировать
1 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
No Image Компьютеры
0 комментариев
No Image Компьютеры
0 комментариев
No Image Компьютеры
0 комментариев
No Image Компьютеры
0 комментариев
Adblock detector