Изучение механизмов защиты HASP/Sentinel: дампы ключей и программные эмуляторы

Дата: 2026-02-10
Контекст: Образовательный обзор для понимания механизмов защиты лицензий (1С, NetHASP и др.). Документ не содержит инструкций по обходу лицензий и предназначен для оценки рисков и изучения архитектуры защиты.

1. Назначение документа

Документ даёт подробное описание вариантов в контексте изучения механизмов защиты:

  • что понимают под дампом ключа HASP и какими способами он теоретически может быть получен;
  • что такое программный эмулятор ключа и как он соотносится с различными программами (в т.ч. 1С, продукты под Sentinel LDK);
  • какие варианты существуют в литературе и практике (концептуально), без пошаговых инструкций по обходу лицензий.

Использование дампов и эмуляторов для обхода лицензий нарушает лицензионные соглашения и может подпадать под законодательство об охране технических средств защиты (в т.ч. ст. 1299 ГК РФ и аналоги).

2. Кратко о семействе HASP/Sentinel

Термин Описание
HASP Аппаратная защита (USB-донгл): хранение лицензий, крипто-операции, память. Изначально Aladdin, затем SafeNet, Gemalto, ныне Thales.
Sentinel HASP HL Аппаратный ключ (Hardware Lock), обновления прошивки через UpdateOnChip.
Sentinel HASP SL Программно-аппаратная защита: виртуальный донгл, SSL-канал, анти-клонирование (клонирование VM/образов может отключать ключ).
Sentinel LDK Комплексное решение Thales: ключи (аппаратные/программные/облачные), API лицензирования, Envelope (обфускация, шифрование исполняемых файлов).
NetHASP / HASP LM Сетевой менеджер лицензий: один сервер с подключённым ключом обслуживает клиентов по UDP (порт 475). Используется 1С и др.

Приложение вызывает API лицензирования (например, hasp_login, чтение памяти ключа, encrypt/decrypt). Драйвер общается с ключом по проприетарному протоколу; при сетевой схеме — с демоном LM, который уже общается с локальным ключом.

3. Варианты получения «дампов» ключей HASP (концептуально)

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

3.1. Аппаратные методы (при физическом доступе к ключу)

  • Снятие дампа памяти ключа: ключ содержит энергозависимую и/или защищённую память (лицензии, секреты). В исследованиях и отчётах об уязвимостях упоминаются методы, требующие физического доступа к чипу (например, зондирование, извлечение после декapsуляции). Для старых или слабо защищённых моделей такие методы в прошлом применялись в анализе безопасности.
  • Side-channel атаки: по потреблению питания, электромагнитному излучению, времени отклика можно пытаться извлекать ключевой материал или параметры протокола. В открытой литературе описаны атаки на различные крипто-устройства (в т.ч. TPM, смарт-карты); применимость к конкретным HASP-ключам зависит от реализации.
  • Fault injection (инъекция сбоев): намеренное нарушение питания или тактирования с целью получить ошибочное поведение и вывести секреты. Требует спецоборудования и физического доступа.
  • JTAG/интерфейсы отладки: если ключ имеет открытые или не до конца отключённые отладочные интерфейсы, теоретически возможен доступ к памяти или состоянию. Современные ключи обычно защищают или отключают такие интерфейсы.

Итог: «дамп» в узком смысле — это данные, считанные с ключа (память, ключевой материал, прошивка). На практике для старых моделей в ряде случаев упоминается возможность снятия дампа и последующей эмуляции; для новых ключей и виртуальных донглов (HASP SL) производитель заявляет анти-клонирование и усложнение таких сценариев.

3.2. Программные и протокольные методы

  • Перехват трафика приложение–драйвер–ключ: на хосте, где ключ подключён, можно перехватывать обмен между приложением и драйвером или между драйвером и ключом (если интерфейс доступен). Это даёт последовательности запросов/ответов протокола, а не обязательно «сырой» дамп памяти ключа.
  • Обратная разработка драйвера и протокола: драйверы HASP (в т.ч. часть Sentinel LDK) в прошлом становились объектом анализа; из драйвера можно выносить структуру протокола, форматы пакетов, типы команд. Это не даёт сам по себе дамп секретов ключа, но позволяет понимать, что запрашивается и в каком виде должен быть ответ.
  • Анализ API приложения: приложение вызывает hasp_login, hasp_get_size, hasp_read и т.д. Анализ бинарника или обёрток позволяет выяснить, какие Feature ID, типы памяти и объёмы данных используются — то есть «контракт» между приложением и ключом.

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

4. Варианты программных эмуляторов ключей HASP

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

4.1. Уровни эмуляции

  • Эмуляция на уровне протокола (сетевой LM): приложение настроено на NetHASP (nethasp.ini) и общается по UDP с демоном LM. «Эмулятор» в этом случае — сервис, слушающий порт 475 и отвечающий пакетами в формате HASP. Для этого нужны знания о формате и последовательности запросов/ответов (из реверса или перехвата). Такой вариант применим ко всем программам, использующим только сетевой ключ (в т.ч. 1С при работе через HASP LM).
  • Эмуляция на уровне локального ключа: приложение или драйвер ожидают локальный USB-ключ. Эмулятор может подменять драйвер или перехватывать вызовы API и подставлять ответы (на основе заранее снятых дампов или перехваченных сессий). Применимость зависит от того, как приложение проверяет ключ (только ли ответ по протоколу или ещё проверка подлинности драйвера/среды).
  • Комбинированный вариант: локальный «фейковый» LM с подставными ответами, либо драйвер-замена, эмулирующий ключ на одной машине; остальные клиенты подключаются к этой машине как к NetHASP.

4.2. Зависимость от конкретных программ

  • 1С:Предприятие: использует либо файловые лицензии (.lic), либо сетевой HASP LM (UDP 475). В схеме с LM приложение не видит ключ напрямую — только ответы от сервера лицензий. Поэтому «эмулятор» для 1С в сетевой конфигурации — это по сути эмулятор сервера LM (ответы по протоколу HASP на порту 475). Подробнее: 1c-hasp-license-manager-expected-parameters.md.
  • Продукты под Sentinel LDK (Envelope или API): могут проверять локальный ключ (USB) или сетевой. Эмуляция зависит от того, какой тип ключа и какой протокол использует конкретный продукт (локальный драйвер vs сетевой LM).
  • Разные версии HASP: старые модели (например, часть HASP4) в отчётах и литературе упоминаются как более уязвимые к дампированию и эмуляции; новые ключи и виртуальные донглы (HASP SL) используют дополнительные механизмы (в т.ч. анти-клонирование, привязка к среде).

4.3. Сборка эмулятора (концептуально)

В обзоре для изучения механизмов можно говорить о следующих вариантах (без инструкций по реализации):

  1. Перехват и воспроизведение: записать трафик «приложение ↔ LM» или «приложение ↔ ключ» при легальном ключе и воспроизводить ответы в нужный момент. Ограничения: привязка к времени, nonce, сессии в зависимости от протокола.
  2. Реверс протокола и генерация ответов: разобрать формат пакетов и алгоритмы (по драйверу или по перехвату) и реализовать сервис/драйвер, формирующий валидные ответы. Требует крипто-ключей или их эквивалента (которые могут быть получены из дампа ключа или из уязвимости).
  3. Использование готовых нелегальных решений: в сети существуют неофициальные «кряки» и эмуляторы. Их использование нарушает лицензии и закон; с точки зрения изучения защиты они показывают, что для части продуктов и версий ключей эмуляция практически реализована.

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

5. Сводная таблица вариантов (для изучения)

Вариант Описание Относится к
Дамп памяти ключа (аппаратный) Физический доступ к чипу, считывание памяти/прошивки Локальный USB-ключ
Side-channel / fault injection Извлечение секретов через побочные каналы или сбои Ключ, чип
Перехват протокола приложение–LM Анализ UDP-трафика к порту 475 NetHASP, 1С и др.
Реверс драйвера HASP Анализ формата и логики протокола Все схемы с HASP
Эмулятор сетевого LM Сервис на порту 475, ответы в формате HASP Программы с NetHASP (1С и др.)
Эмулятор локального ключа Подмена драйвера/ответов API для USB-ключа Программы с локальным ключом
Готовые неофициальные эмуляторы Сторонние «кряки»; использование незаконно Разные программы

5.1. Наиболее уязвимые методы (с точки зрения защиты)

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

Уязвимость Почему уязвимо Что усиливает защиту
Старые аппаратные ключи (HASP4 и др.) Слабее крипто- и физическая защита чипа; известны случаи дампирования и появления эмуляторов. Переход на актуальные ключи и прошивки (UpdateOnChip); учёт и замена устаревших ключей.
Сетевой LM без изоляции (UDP 475) Трафик приложение–LM можно перехватывать в сегменте; протокол проприетарный, но не засекречен — реверс и эмуляция сервера на порту 475 реалистичны. Ограничение доступа к порту 475 только доверенными хостами; сегментация сети; не выносить LM в общие/ненадёжные подсети.
Один сервер LM без резерва Единая точка отказа; при компрометации или простое LM все зависимые приложения теряют лицензии; удобная цель для атак. Резервирование LM (по документации Thales); мониторинг доступности; план восстановления.
Перехват трафика приложение–драйвер На хосте с ключом обмен между приложением и драйвером даёт запросы/ответы протокола; при отсутствии привязки к nonce/времени возможно воспроизведение. Минимизация числа хостов с ключом; контроль целостности ПО и прав доступа; актуальные версии драйвера.
Файловые лицензии .lic без привязки к «железу» Файл можно скопировать и использовать на других системах; при слабых настройках активации привязка к оборудованию нежёсткая. Жёсткая привязка к железу при активации; ограничение доступа к каталогам с .lic; не дублировать один .lic в несколько мест.
Физический доступ к ключу Даёт возможность аппаратного дампа, side-channel или fault injection; для старых ключей — критично. Учёт и хранение ключей; ограничение физического доступа к серверу LM; использование ключей с усиленной физической защитой.
Уязвимости драйвера/установщика (CVE) RCE и повышение привилегий (напр. CVE-2017-11496, CVE-2024-0197) расширяют возможности атакующего на хосте с HASP. Только официальные дистрибутивы; своевременные обновления и патчи; ограничение сетевого доступа к порту 1947 и к хостам с HASP.

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

5.2. Уязвимости драйвера и установщика (CVE): принцип и механика RCE и повышения привилегий

Ниже описаны принцип и механика реализации уязвимостей в компонентах HASP/Sentinel (драйвер, службы лицензирования, установщик), приводящих к удалённому выполнению кода (RCE) или к повышению привилегий на хосте с установленным HASP. Понимание механики нужно для оценки рисков и выбора мер защиты (обновления, изоляция сети, мониторинг).

Почему именно драйвер и установщик опасны

  • Драйвер и службы лицензирования работают с повышенными привилегиями: в режиме ядра (драйвер) или от учётной записи системы (служба hasplms / Sentinel LDK RTE). Выполнение произвольного кода в таком контексте даёт полный контроль над хостом (RCE с правами SYSTEM или ядра).
  • Установщик часто запускается с правами администратора (для установки драйвера и служб). Если установщик уязвим к подмене DLL или к запуску кода из пользовательских каталогов, злоумышленник с обычными правами может подставить свой код и получить выполнение уже с правами установщика — то есть повышение привилегий (Local Privilege Escalation, LPE).
  • Порт 1947 используется средой выполнения Sentinel HASP (RTE) для обмена между защищённым ПО и локальными/удалёнными компонентами лицензирования. При установке HASP этот порт нередко добавляется в исключения брандмауэра без явного запроса пользователя. В результате служба, слушающая порт 1947, остаётся доступна по сети даже после извлечения ключа — формируется устойчивая удалённая поверхность атаки.

Таким образом, уязвимость в коде, обрабатывающем входящие данные по сети или загружаемом установщиком, превращается в RCE или LPE на критичном хосте (в т.ч. на сервере с ключом HASP/NetHASP).

Механика удалённого выполнения кода (RCE) на примере CVE-2017-11496 и родственных

Уязвимый компонент: служба hasplms (Sentinel LDK RTE, в т.ч. HASP SRM, Admin Control Center). Версии до 7.55/7.60 (конкретно hasplms до 19.3.1.66130 по CVE-2017-11496).

Цепочка атаки:

  1. Служба hasplms слушает порт 1947 (TCP/UDP) и принимает соединения для управления лицензиями и обработки служебных данных.
  2. В коде обработки входящих данных предусмотрена работа с файлами/потоками в форматах V2C (Vendor to Customer) и подобных, содержащих структуры ASN.1 (кодирование лицензий и т.п.).
  3. При разборе входящего потока не проверяется размер копируемых данных в буфер фиксированного размера на стеке (классический stack buffer overflow). Злонамеренно сформированный ASN.1-поток (или файл V2C, передаваемый по протоколу службы) переполняет буфер и затирает адрес возврата (return address) на стеке.
  4. Атакующий подставляет в переполнение адрес своего кода (shellcode или вызов существующей библиотеки). При выходе из уязвимой функции управление передаётся по этому адресу.
  5. Код выполняется в контексте процесса hasplms — то есть с правами системы (SYSTEM на Windows). Итог: удалённое выполнение кода без аутентификации и без взаимодействия пользователя (CVSS 9.8, AV:N/AC:L/PR:N/UI:N).

Аналогичная механика у CVE-2017-11497: переполнение буфера при обработке языковых пакетов, в которых имена файлов длиннее 1024 символов. Итог тот же — RCE через отправку специально сформированных данных на порт 1947.

Почему атака удалённая: порт 1947 открыт в брандмауэре установщиком HASP; атакующий из той же сети (или из интернета, если хост выставлен) может отправлять пакеты на этот порт и вызывать разбор злонамеренных данных в hasplms.

Смежные CVE того же класса: CVE-2017-12821 (повреждение памяти в RTE → RCE), CVE-2017-12822 (удалённое включение/выключение админ-интерфейса), CVE-2017-12819 (NTLM-relay через обновление языковых пакетов), CVE-2017-12820 (произвольное чтение памяти → DoS). Обнаружены Kaspersky ICS CERT; исправления — обновление до Sentinel LDK RTE 7.55/7.60 и выше.

Механика повышения привилегий (LPE) на примере CVE-2024-0197

Уязвимый компонент: установщик Thales SafeNet Sentinel HASP LDK (например, haspdinst.exe или иной установочный компонент) на Windows. Версии до 9.16.

Суть уязвимости: неправильное управление привилегиями при загрузке библиотек (CWE-269). Установщик при запуске с повышенными правами загружает DLL из каталогов, которые контролируются пользователем (текущая директория, каталоги в PATH с правами на запись у обычного пользователя). Классическая схема DLL hijacking (подмена DLL).

Цепочка атаки:

  1. Злоумышленник имеет локальный доступ к системе с правами обычного пользователя (без прав администратора).
  2. Он помещает вредоносную DLL с именем, которое установщик пытается загрузить, в каталог, откуда установщик её подхватит первым (например, каталог установки или текущая рабочая директория при запуске установщика).
  3. Администратор (или автоматизированный процесс) запускает установщик HASP с повышенными правами — например, для обновления драйвера или переустановки.
  4. Установщик загружает подставленную DLL; в ней выполняется код инициализации (DllMain и т.п.). Этот код выполняется уже в контексте процесса установщика, то есть с правами администратора/SYSTEM.
  5. Итог: повышение привилегий с обычного пользователя до полного контроля над хостом (CVSS 7.8, локальный вектор, низкая сложность; известен публичный PoC, в т.ч. на GitHub).

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

Сводка по механикам

Тип Компонент Вектор Механика Результат
RCE hasplms (порт 1947) Сеть, без аутентификации Stack buffer overflow при разборе ASN.1/V2C или длинных имён в языковых пакетах; перезапись адреса возврата → выполнение кода от имени службы Полный контроль над хостом (SYSTEM)
RCE Драйвер/RTE (память) Сеть Повреждение памяти в обработчиках → выполнение кода в ядре/службе Полный контроль над хостом
LPE Установщик (haspdinst и др.) Локально, низкие привилегии DLL hijacking: установщик загружает DLL из пользовательского каталога → код выполняется с правами установщика Повышение привилегий до администратора/SYSTEM

Меры снижения риска (кратко): обновление Sentinel LDK RTE и установщика до версий с исправлениями (RTE 7.60+ для CVE 2017 года, LDK 9.16+ для CVE-2024-0197); ограничение сетевого доступа к порту 1947 только доверенными подсетями; мониторинг подозрительной активности на порту 1947 и подозрительных запусков; установка только из официальных дистрибутивов и проверка целостности.

6. Официальные и легальные источники для углубления

В рамках проекта DENKART: конфигурация 1С и NetHASP описана в 1c-license-placement-and-nethasp.md; риски и уязвимости (в т.ч. эмуляция и дамп) — в 1c-licensing-vulnerabilities-and-risks.md.

7. Правовые и этические границы

  • Дампы и эмуляторы в целях обхода лицензий нарушают лицензионные соглашения и могут подпадать под нормы об обходе технических средств защиты прав (в РФ — ст. 1299 ГК РФ и др.).
  • Изучение механизмов защиты в собственной инфраструктуре (свои ключи, тестовые лицензии) и по открытой документации/публикациям по безопасности — допустимо для оценки рисков и архитектуры.
  • Рекомендуется не хранить и не использовать неофициальные эмуляторы и «кряки» в производственной среде; учёт и ограничение доступа к ключам и серверу LM — см. 1c-licensing-vulnerabilities-and-risks.md.

Связанные документы

Дата последнего обновления: 2026-02-10
Технический директор: AI Denkart