Как сделать эмулятор usb-ключа Guardant

Обновлено: 02.07.2024

Выбор языка:

    [25 мая 2009 г.]; ; (проверьте тип ключа по фото); ; .
    (последняя версия v3.12);
  • Полная эмуляция ключа HASP4 (HaspEncodeData, HaspDecodeData) [12 сентября 2003 г.];
  • Дампер памяти и дампер данных секретного алгоритма для ключей HASP3, HASP4, HASP HL, HASP SRM;
  • Удаление конверта HASP4 без оригинального ключа;
  • Снятие конверта HASP HL;
  • Удаление конверта HASP SRM; (новая версия v2.1); ; (список дампов/софта); ; ; ; .
  • Эмулятор/монитор ключей HardLock;
  • Полная эмуляция ключа HardLock (HL_CODE, HL_CRYPT) [23 сентября 2003 г.];
  • Снятие HardLock Envelope (Bistro) без оригинального ключа; (последняя версия v2.1); (дампы/список ПО).
    (последняя версия v0.92);
  • Полная эмуляция ключа Sentinel SuperPro (RNBOsproQuery — Standard/Enhanced) [26 сентября 2003 г.];
  • Удаление Sentinel SuperPro Envelope без оригинального ключа;
  • Дампер памяти для ключа Sentinel SuperPro; (последняя версия v1.2); (дампы/список ПО).
  • Эмулятор/монитор ключей Guardant;
  • Полная эмуляция ключа Guardant Stealth (nskTransform) [26 сентября 2003 г.];
  • Удаление Guardant Stealth Envelope без оригинального ключа;
  • Дампер памяти для ключа Guardant Stealth; (дампы/список ПО).
  • Эмулятор/монитор ключей MicroGuard;
  • Дампер памяти для ключа MicroGuard; (список дампов/софта); .
    (список данных/программ);
  • Генератор лицензий FLEXlm/FLEXnet; .
  • Генератор лицензий SentinelLM.
  • Активатор SSI [Удаление AEGIS — оболочка активатора],
  • WIBU (WIBU-KEY, WIBU-BOX, SecuriKey, CM-Stick) (системы WIBU),
  • DESkey (DK2) (системы шифрования данных),
  • KEY-LOK II (цифровая безопасность MAI),
  • CRYPTO-BOX, CrypToken (безопасность программного обеспечения MARX),
  • SmartKey (SmartKey3) (Eutron InfoSecurity),
  • Матрица (TechnoData Interware),
  • eToken (системы знаний Aladdin),
  • iKey (Rainbow Technologies/SafeNet),
  • iButton (сенсорная память) (Dallas Semiconductor / Maxim Integrated Products),
  • FLEX-ID (Globetrotter / MacroVision),
  • Микрофар,
  • Мозговой ключ,
  • Динки (1S, 2, Net) (Microcosm Ltd),
  • ROCKEY (ePass, ROCKEY4 Standard, ROCKEY4 Plus, NetROCKEY4, ROCKEY5, ROCKEY6) (Feitian Technologies),
  • SparKey (SparKey, Spark Keypro, Net-SparKey) (Beijing Spark Technologies),
  • iLok (борьба с пиратством PACE)
  • и многие другие.
  • Менеджер лицензий Elan (ElanLM, ELM)
  • КрипКлюч
  • и многие другие.
    ; ; ; .

Ключ эмулятора Guardant Stealth II для программы "Учеба Мономаха v4.5 R3" (отредактировано для 64-битной ОС).

Автоматический перевод от Google:

Ключ эмулятора Guardant Stealth II для программы "Учеба Мономаха v4.5 R3" (отредактировано для 64-битной ОС).

Перед установкой эмулятора на компьютер должна быть установлена ​​оригинальная версия драйверов ключа 5.х.х. Скачать последнюю версию оригинальных драйверов ключей Guardant Вы можете по этой ссылке:

- Для установки эмулятора запустить файл install.bat.

Установить эмулятор нужно только один раз (в дальнейшем после перезагрузки компьютера повторно проводить установку не нужно) под администратором вашей операционной системы.

При установке система обнаружит устройство "Guardant Stealth II USB dongle" и попросит указать тип установки:

– Автоматическая установка.
– Установка из определенного места.

Сначала попробуйте автоматически. Если Windows не находит драйверы автоматически, укажите расположение файлов «grdkey.inf», «grdusb.inf», «grdusb.sys» и «grdkey.sys».

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

- Для удаления эмулятора с ПК необходимо запустить файл 'uninstall.bat'.

Для установки эмулятора ключа в автоматическом режиме в Windows Vista и Windows 7 необходимо отключить контроль учетных записей (UAC). Это можно сделать в панели управления апплета «Учетные записи пользователей».

Для установки эмулятора в Windows Vista/7 перед установкой эмулятора необходимо получить ключ для загрузки и установки 'ReadyDriver Plus v1.2', который можно скачать по адресу:

Эта утилита автоматически запускает драйверы устройств проверки цифровой подписи Windows 7 x64 в режиме завершения работы. Настройки безопасности Windows 7 не позволят установить драйвера без цифровой подписи от Microsoft. Разумеется, что эмулятор драйвера ключа Microsoft не подпишет.

После установки утилит ReadyDriver Plus v1.2' необходимо перезагрузить компьютер, а затем установить ключ эмулятора.

При работе с защитным ключом Guardant (независимо от модели) разработчик использует соответствующие API, при этом от него скрыт механизм работы с устройством, не говоря уже о протоколе обмена. У него на руках нет валидного дескриптора устройства, используется только адрес шлюза (так называемый GuardantHandle), через который и идет вся работа. Если в системе есть эмулятор ключа (особенно актуально для моделей до Guardant Stealth II включительно), использующий этот шлюз, разработчик не сможет определить, работает ли он с реальным физическим ключом или его эмуляцией.

Задав в свое время вопрос: «как определить наличие физического ключа?», пришлось немного изучить отличный материал, представленный Павлом Агуровым в книге «Интерфейс USB. Практика использования и программирования». После этого потратьте время на анализ вызовов функций API из трехмегабайтного объекта, ссылающегося на приложение, в котором фактически скрыта вся «магия» работы с ключом.

В результате появилось достаточно простое решение этой проблемы, не требующее использования оригинальных API Guardant.
Единственный минус - все жутко недокументировано и техподдержка активов компании даже не будет рассматривать ваши вопросы связанные с использованием ключей Guardant.
И конечно, в какой-то момент весь этот код может просто остановить ведомого вора из-за изменений в драйверах Guardant.
А пока, на 27 апреля 2013 года, весь этот материал актуален и проверен на работоспособность на драйверах от версии 5.31.78, до текущей даты 6.00.101.

  1. Через SetupDiGetClassDevsA() мы получаем список всех присутствующих устройств.
  2. Проверьте, связано ли устройство с ключами Guardant, проверив GUID устройства. (Для Guardant это параметр )
  3. Мы получаем символическую ссылку на каждое устройство, вызывая SetupDiGetDeviceRegistryPropertyA() с параметром SPDRP_PHYSICAL_DEVICE_OBJECT_NAME.
  4. Откроем устройство с помощью ZwOpenFile() (CreateFile() здесь к сожалению не сработает, т.к. будут сложности при работе с символическими ссылками).

Начиная с Guardant Stealth III и выше изменился протокол работы с ключом, как следствие изменились константы IOCTL-запроса и содержимое входящего и исходящего буферов. Для нормальной работы алгоритма желательно поддерживать возможности как старых, так и новых ключей, поэтому опишу отличия:

Начнем с того, что константы IOCTL выглядят так:


Первый для ключей от Guardant Stealth I/II
Второй для ключей от Guardant Stealth III и выше (Sign/Time/Flash/Code)

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


В случае более новых ключей и с учетом того, что протокол изменился, отправка первого запроса ничего нам не даст. Точнее, запрос, конечно, выполнится, но буфер придет пустой (nullified). Поэтому отправляем повторный запрос на новые ключи, который вернет данные немного в другом формате:


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

Общий код для получения данных об установленных ключах выглядит так:


Эта процедура перебирает все ключи и заносит информацию о них в массив структур TDongleQueryRecord, после чего вы можете отобразить эти данные пользователю, ну или использовать их каким-либо образом прямо в вашем приложении.< /p>

image< бр />

Как видите, все достаточно просто, но в объектных модулях API Guardant этот код размещен под достаточно серьезной стекированной виртуальной машиной и практически недоступен для анализа рядовому разработчику. В принципе, ничего секретного тут нет, как видите, вызовы даже не используют шифрование передаваемых и принимаемых буферов, но почему-то разработчики Guardant SDK не сочли нужным публиковать эту информацию (правда мне все же удалось получить разрешение опубликовать этот код, потому что в результате здесь не затрагиваются некоторые критические аспекты протокола обмена ключами).

Но не будем отвлекаться, вы наверняка заметили в приведенной выше процедуре вызов функции GetPnP_ParentPath(). Эта функция возвращает полный путь к устройству от корня. Его реализация выглядит следующим образом:


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


В нем будет присутствовать как минимум текст NTPNP_PCI или USBPDO.
Тех. Шина PCI или концентратор HCD будет как минимум одним из предков.
Поскольку эмулятор по-прежнему является виртуальным устройством, путь к нему будет выглядеть примерно так:

Соответственно, на основе этой информации можно реализовать простую функцию:


Ну и в завершение опишу еще несколько нюансов, которые можно увидеть на приложенном к статье демо-примере:

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

  1. Безопасный обмен сеансовыми ключами. При выполнении функции GrdLogin происходит взаимная аутентификация ключа и Guardant API, а также безопасный обмен сеансовыми ключами. Слово «обмен» — это просто термин. На самом деле API и ключ вычисляют это значение независимо друг от друга на основе безопасной асимметричной схемы. Вы не можете перехватить его в протоколе обмена. Поэтому выполнение команды GrdLogin занимает значительно больше времени, чем другие.
  2. Регулярная смена сеансовых ключей. Если хакеру удастся получить сессионный ключ, защищенный псевдокодом Guardant API, он все равно не принесет ему особой пользы. Ключ разработан таким образом, что он не работает с любым сеансовым ключом более нескольких минут. Ключ начинает возвращать специальный код ошибки в ответ на любую команду, полученную с использованием устаревшего сеансового ключа, после истечения срока действия этого сеансового ключа, пока такая копия API не пройдет взаимную аутентификацию и не сгенерирует ключ. Соответственно, при разработке системы защиты необходимо учитывать тот факт, что такая регенерация может потребовать некоторого времени. А если приложение запрещает такие задержки в работе, то рекомендуется организовать обращения к ключу из параллельно работающих потоков.
  3. Использование GrdSign и GrdVerifySign. Это очень мощный инструмент, который при правильном использовании дает возможность создать защиту беспрецедентно высокого уровня. Для этого необходимо аппаратно подписать (GrdSign) и проверить на программном уровне (GrdVerifySign) защищенное приложение в процессе его работы по каким-то случайным данным. Проверка подписи целенаправленно реализована на программном уровне, так как избавляет хакера даже от гипотетической возможности ее перехвата в эмуляторе на уровне драйвера или шины USB. И он использует общедоступный ключ шифрования, который невозможно скомпрометировать.
  4. Атака генератора случайных чисел. Если хакер сможет делать вызовы ключа не случайными, а постоянными, у него появится возможность создать эмулятор стола, который будет знать все ответы на все вопросы, заданные программой. Чтобы убедиться, что отправляемые данные действительно случайны, мы настоятельно рекомендуем использовать какой-нибудь хеш (например, SHA-256) от действительно случайных данных, который программа использует и без которого она теряет смысл и значительную часть своего функционала. Например, введенные пользователем данные, ID созданных потоков, выделенные адреса памяти и т. д. В противном случае хакер сможет предоставить любые значения по своему выбору в ответ на любые вызовы Guardant API.
  5. Атака с подменой открытого ключа. Несмотря на то, что открытый ключ асимметричного алгоритма не является секретным, тем не менее, необходимо принять все необходимые меры предосторожности, чтобы противостоять его модификации и/или подмене.
    1. Не храните его инициализированным в сегменте данных (в C это инициализированная глобальная или статическая переменная или константа), так как это самый простой способ заменить его.
    2. Рассчитывайте его значение непосредственно перед использованием и удаляйте или стирайте его сразу после использования.
    3. Контролируйте целостность кода, который с ним работает.
      1. Вызовите GrdVerifySign, чтобы он возвращал в качестве выходных данных другие коды ошибок, которые также требуют проверки. Например, вы можете указать случайные данные в сообщении, подписи или неправильном открытом ключе ECC.
      2. Среди этих вызовов очень полезен время от времени вызов GrdVerifySign с запросом на проверку валидности подписи одного из валидных сообщений, подписанных тем же ключом, не во время выполнения программы, а на этапе защиты. Для этого вам нужно сохранить несколько подписанных случайных сообщений с подписями во время защиты. Аналогично тому, как это делается с различными массивами вопросов и ответов, используемыми при работе с симметричными алгоритмами.
      3. Результат проверки подписи GrdVerifySign по существу состоит из одного бита. Вместо того, чтобы ставить явную проверку кода возврата, можно из нескольких вызовов сформировать одну константу, которая в дальнейшем будет использоваться в вычислениях. Благодаря тому, что скорость работы подписи в ключе достаточно высокая.

      Использование алгоритмов однонаправленного симметричного шифрования AES и GSII64.Можно организовать защиту так, чтобы какой-нибудь алгоритм AES или GSII64, используемый для защиты приложений, работал в обе стороны в ключе, а в ключе, который выдается конечному пользователю, мог только расшифровывать. Тогда вы могли бы хранить в каком-то защищенном элементе (или файле) некоторую информацию о конфигурации или лицензии, зашифрованную с использованием этого алгоритма, при продаже программного обеспечения, не опасаясь, что хакер может заменить его. Потому что для замены вам нужно будет записать в этот элемент информацию, зашифрованную с помощью этого алгоритма. И хакер не сможет зашифровать его на пользовательском ключе по тому же алгоритму из-за его однонаправленности. Аналогичные механизмы могут быть использованы для распространения зашифрованных обновлений, которые хакер, имеющий ключ конечного пользователя с однонаправленным алгоритмом, не сможет зашифровать, изменить или передать программе.

      Однонаправленные алгоритмы AES128 можно использовать в блочных режимах ECB и CBC. Вы не можете использовать потоковые режимы CFB и OFB.

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

      Рейтинг 4,5 на основе 198 пользователей
      Доступно в Windows 7/8/10, Server 2008 R2/2012/2016/2019, Windows 10 на ARM.

      Donglify

      Теперь вы можете поделиться доступом к своей учетной записи с другими, не указывая свой адрес электронной почты и пароль. Просто создайте токены входа и отправьте их другим пользователям Donglify.

      Зачем делиться ключами?

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

      Программное обеспечение для обмена ключами

      Donglify - оптимальное решение

      Donglify - оптимальное решение

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

      Donglify предлагает комплексное программное решение, которое устраняет необходимость в дополнительном оборудовании для совместного использования USB-ключей по сети.

      Оптимальное решение для совместного использования USB-ключей

      Дни переноса ключа с машины на машину прошли. Теперь вы можете поделиться USB-ключом с компьютером, на котором даже нет USB-порта.

      Подключение USB-ключей к виртуальной машине

      Если USB-ключ, подключенный к вашему компьютеру, не распознается виртуальной машиной, на которой вы работаете, не беспокойтесь. Просто установите Donglify как в основной, так и в гостевой операционных системах и перенаправьте свое устройство в виртуальную среду без каких-либо ограничений.

      Защита на весь срок службы устройства

      Перемещение ключа для подключения к разным компьютерам, безусловно, приводит к износу и впоследствии сокращает срок службы устройства. С Donglify ваш аппаратный USB-ключ практически не перемещается (если вообще перемещается), поэтому он прослужит вам дольше. Вы можете просто поделиться своим ключом через Интернет и получить к нему удаленный доступ с любого подключенного к сети ПК. Прочтите статью о защите срока службы ключа.

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