- Aladdin monitor не показывает ключ sentinel (hasp)
- Hasp4 — надежная защита от пиратов
- Hasp4 hasp hl (legacy) для разработчиков — база знаний
- Автозагрузка приложения, использующего ключ защиты sentinel (hasp)
- В чём различия между технологиями hasp4, hasp hl и sentinel ldk (srm)?
- Взглянем
- Где взять документацию к комплекту разработчика?
- Два ключа защиты по sentinel (hasp) на одном компьютере
- Есть ли совместимость у ключей sentinel (hasp) с предыдущими версиями, если есть, то какая?
- Какие варианты защиты существуют?
- Какие документы нужны для отправки ключа за границу?
- Механизм системы защиты
- Обработчик
- Ошибка «hasp not found (0)»
- Перехват и эмуляция
- Перехватчик
- Процедура установки/удаления драйвера ключа
- Работа ключа на удаленной машине – настройка «nethasp.ini»
- Работа приложений, защищенных при помощи электронных ключей hasp4, hasp hl и sentinel hl в рамках системы защиты hasp4 под windows vista
- Заключение
Aladdin monitor не показывает ключ sentinel (hasp)
Сам по себе монитор может показать только наличие менеджера лицензий на том или ином адресе. Ключ он сможет увидеть только после того, как защищенное приложение успешно откроет хотя бы одну сессию с ключом. Кроме того, следует учитывать, что Aladdin Monitor работает только по протоколу UDP, порт 475. Таким образом, отсутствие данных о ключе в мониторе еще не означает, что ключ недоступен для приложения.
Hasp4 — надежная защита от пиратов
Пожалуй, самым надежным способом защиты программного обеспечения от пиратов на сегодняшний день являются аппаратные ключи. А самыми известными среди них — HASP4 от компании Aladdin Software Security R.D. Сами разработчики определяют HASP4 как мультиплатформенную аппаратно-программную инструментальную систему для защиты программ и данных от нелегального использования и несанкционированного распространения. Сегодня мы с вами, уважаемые читатели, подробно рассмотрим этот комплекс с точки зрения разработчика.
Итак, с предназначением системы HASP4 мы уже разобрались. Она защищает интеллектуальную собственность разработчиков и поставщиков программного обеспечения. Основой системы является аппаратный ключ, который присоединяется к компьютеру. Без этого небольшого устройства защищаемое программное обеспечение либо вообще не будет работать, либо будет иметь заданные разработчиками функциональные ограничения. На сегодняшний день компания выпускает три типа ключей — USB-брелок, LPT-ключ, PCMCIA-карта. В принципе, этот набор позволяет разработчикам программного обеспечения охватить всех потенциальных клиентов вне зависимости от используемых ими компьютеров.
В общем, принцип действия системы HASP4 таков. Аппаратный ключ присоединяется к определенному порту компьютера. Далее защищенная программа через специальный драйвер отправляет ему информацию, которая обрабатывается в соответствии с заданным алгоритмом и возвращается обратно. Если ответ ключа правильный, то программа продолжает свою работу. В противном случае она может выполнять любые действия, заданные разработчиками — например, переключаться в демонстрационный режим, блокируя доступ к определенным функциям.
У системы HASP4, в отличие от многих других комплексов защиты с помощью аппаратных ключей, есть ряд преимуществ. Вот они:
- новейший ASIC-чип (для ключей LPT) или микроконтроллер (для ключей USB), выполненный по 1,2-микронной технологии и содержащий 2800 вентилей на кристалле;
- встроенный криптопроцессор, который позволяет шифровать и дешифровать данные в режиме реального времени, причем ключ шифрования никогда не передается на выход ключа, что исключает возможность его перехвата;
- возможность использования собственных функций обработки входной информации;
- до 512 байт EEPROM-памяти, доступной как для чтения, так и для записи (из них 16 байт — управляющая память);
- неизменяемый уникальный код разработчика, который обеспечивает использование каждого ключа только с продуктами определенной компании;
- отсутствие элементов питания (за исключением HASP4 Time), что обеспечивает практически бесконечную работу ключа;
- возможность каскадного подключения LPT-ключей друг на друга;
- возможность подключения нескольких USB-ключей одновременно к одному компьютеру.
Линейка ключей HASP4
На сегодняшний день в линейке аппаратных ключей HASP4 присутствуют шесть моделей. Давайте кратко рассмотрим каждую из них.
HASP4 Standart — простые ключи. Они не имеют собственного уникального ID-номера и встроенной памяти. HASP4 Standart — самые дешевые ключи в линейке, а поэтому их можно использовать для защиты недорогих программ. Кроме того, эти ключи не требуют предварительного программирования и сразу готовы к поставке в составе защищенного программного обеспечения.
HASP4 M1 — ключи с уникальным ID-номером и защищенной перезаписываемой памятью объемом 112 байт. С помощью одного ключа этого типа можно защитить до 16 различных приложений. Кроме того, устройства HASP4 M1 имеют функцию дистанционного перепрограммирования Remote Update System (подробно на ней мы остановимся позже).
HASP4 M4 — в принципе, эти ключи отличаются от HASP4 M1 только большим объемом памяти EEPROM (496 байт) и большим числом программ, которые можно защитить с помощью одного устройства (до 112 приложений).
HASP4 Time — ключи со встроенными часами реального времени, показывающими текущую дату и время. Это предоставляет разработчикам программ дополнительные возможности по распространению своих продуктов. Так, например, с помощью устройств HASP4 Time можно обеспечить передачу программы на определенный срок (демоверсия), сдачу ее в аренду или лизинг с периодической оплатой за пользование и так далее. Кроме того, эти ключи содержат 496 байт защищенной перезаписываемой памяти, а также поддерживают функции Full Authorization System (управление доступом для нескольких приложений) и Remote Update System.
HASP4 Net — главной особенностью ключей этого типа является возможность защиты приложений в сети (доступные протоколы — IPX/SPX, NetBIOS, NetBEUI и TCP/IP). Достаточно только подключить ключ на любом компьютере (не обязательно на сервере), чтобы он начал свою работу. Устройства HASP4 Net могут ограничивать число пользователей, одновременно работающих с защищенной программой. Кроме того, эти ключи имеют память EEPROM объемом 496 байт и могут одновременно работать со 112 приложениями, а также поддерживают функции Full Authorization System и Remote Update System.
HASP4 PC-Card — модель ключа, предназначенная для портативных компьютеров, которую можно подключать к слоту PCMCIA. Вообще-то, возможности устройства этого типа практически идентичны возможностям ключей HASP4 M4.
HASP для разработчика
Для начала работы с системой компания, занимающаяся созданием программного обеспечения, должна приобрести HASP Developer’s Kit, то есть специальный набор разработчика. Он состоит из полной технической документации, утилит, необходимых для работы и демонстрационного ключа. Все это позволяет защитить как создаваемую, так и уже готовую программу.
Кстати, система HASP4 позволяет защищать ПО двумя способами. Первый из них — это HASP Envelope. Он применяется для уже готовых программ. Причем для его использования не обязательно даже иметь исходные коды продукта и разбираться в программировании. Эта схема защиты не представляет абсолютно никаких сложностей. Достаточно запустить специальную утилиту HASP Envelope, входящую в комплект разработчика, выбрать нужные исполняемые файлы (exe, dll, ocx), настроить параметры защиты (ограничение количества лицензий, времени использования или количества запусков, привязка к конкретному ключу, фоновые проверки наличия ключа во время работы программы и тому подобное), после чего нажать на кнопку Protect. Собственно, это все. Далее утилита обработает указанные файлы, закодирует их и встроит специальные антиотладочные и антитрассировочные средства. Естественно, что после этого запустить программу просто так уже нельзя — ее код зашифрован. Если же во время запуска приложения к компьютеру подключен нужный ключ, расшифровка файлов происходит автоматически.
Второй механизм защиты — HASP API. Суть его заключается в том, что разработчики в любом месте своего приложения могут обращаться к ключу с помощью специальных функций API. Результаты этих обращений маскируются в теле программы или библиотеке DLL. Таким образом можно реализовать полный цикл работы с ключом — например, проверить его наличие, прочитать или изменить содержимое памяти EEPROM, получить его ID-номер, просмотреть значение таймера (если он есть в ключе) и так далее. Конечно, использование этого механизма защиты требует внесения изменений в исходный код программы. А значит, удобнее всего его использовать в момент создания продукта, заранее определившись со способом защиты от пиратов. Кроме того, надежность защиты в этом случае во многом зависит от качества работы разработчиков приложения.
Кстати, специалисты компании Aladdin советуют комбинировать оба способа защиты программы с помощью системы HASP4. Осуществляется это следующим образом. Сначала в код разрабатываемого приложения встраиваются вызовы функций API, работающих с ключом. Ну, а после завершения работы над продуктом скомпилированные исполняемые файлы обрабатываются утилитой HASP Envelope. Таким образом, у нас получается двухуровневая защита, сломать которую очень и очень непросто.
После того как программный продукт полностью готов, его разработчики заказывают у Aladdin комплект ключей для реализации вместе с ним. При этом компании присваивается уникальный код, который в будущем будет «зашиваться» во все устройства для всех программ этой фирмы. Кстати, обратите внимание, что необходимо вернуть демонстрационный ключ, входящий в комплект разработчика, при получении первого же комплекта нормальных ключей. Ну, а дальше все уже просто. Полученные ключи при необходимости программируются, после чего можно приступать к реализации программного продукта.
Утилиты системы HASP4
В системе HASP4 предусмотрено несколько утилит для работы с аппаратными ключами. Они могут существенно облегчить жизнь как разработчиков защищаемого программного обеспечения, так и его пользователей. А поэтому давайте, хоть и кратко, рассмотрим наиболее полезные из них.
Aladdin DiagnostiX. Эта утилита фактически реализует механизм обратной связи. Ее главная задача — диагностика работоспособности всех ключей (в том числе и сетевых), работающих в системе. Кроме того, она позволяет устанавливать новые драйверы, а также настраивать конфигурацию для HASP4 Net. В дополнение к этому, DiagnostiX может генерировать отчеты, включающие всю информацию, связанную с устройствами Aladdin.
HASP Edit. Эта утилита предназначена для перепрограммирования ключей. Предназначена она только для разработчиков. HASP Edit позволяет узнать ID-номера ключа, изменить содержимое его памяти EEPROM, установить различные параметры защиты, настроить часы реального времени (только для HASP4 Time). Кроме того, эта утилита может шифровать блоки данных для включения их в исходный код при защите приложения. Все эти функции особенно важны, когда используется механизм защиты HASP API, или программа подготавливается для распространения нестандартным способом (аренда, лизинг, демоверсия).
Remote Update System (RUS) — система дистанционного перепрограммирования. Она предназначена для удаленного изменения памяти аппаратных ключей. Система позволяет добавлять или удалять лицензии, а также изменять содержимое EEPROM. Все это нужно, когда разработчикам требуется перепрограммирование ключей, уже переданных клиентам. Принцип работы RUS таков. Разработчик запускает специальную программу, которая генерирует зашифрованный блок информации, привязанный к ID-номеру ключа клиента. Эти данные любым доступным способом отправляются пользователю, который запускает свою утилиту RUS, автоматически расшифровывающую информацию и обновляющую память ключа.
Full Authorization System (FAS) — система полного управления доступом. Она предназначена для автоматического лицензирования нескольких программ с помощью одного ключа. Обычно FAS работает совместно со схемой защиты HASP Envelope. Она позволяет настроить параметры и условия, при которых будет исполняться каждое приложение. В частности, можно ограничить число запусков программы, количество лицензий (для сетевых версий) и время окончания лицензии (для демоверсий). Также нужно отметить, что FAS является обязательной частью сетевой защиты с использованием ключа HASP4 Net.
Вывод
Рассмотрев подробно систему защиты программ от пиратов HASP4, можно с уверенностью сказать, что на сегодняшний день она является одной из самых надежных на российском рынке. Кроме того, ее использование не доставит разработчикам ПО никаких сложностей, даже в том случае если программный код по каким-либо причинам недоступен. В принципе, и цену комплекта HASP Developer’s Kit (от 25 до 55 долларов в зависимости от модели ключа) нельзя назвать высокой. Правда, несколько огорчает стоимость ключей для пользователей. Согласитесь, что вряд ли кто-то согласится заплатить 15 долларов за ключ в дополнение к программе ценой в 20 долларов. Но зато для разработчиков серьезного (например, для бизнеса) программного обеспечения использование системы HASP4 является, пожалуй, наилучшим решением в области защиты своих разработок от пиратов.
Hasp4 hasp hl (legacy) для разработчиков — база знаний
Причина сбоев в работе менеджера лицензий – «битые» пакеты, приходящие по UDP. Поскольку обмен при помощи UDP-дэйтаграмм не предусматривает контроля успешной доставки пакета, данный протокол надежно работает только в сетях, построенных на высококачественном оборудовании. Если же на какой-нибудь рабочей станции, где запускается защищенное приложение, установлена карта, которая не корректно работает с FlowControl, то это приводит к вышеописанной ситуации. Единственный способ разрешить эту проблему, не учитывая замену оборудования на более качественное, – это переход на обмен посредством TCP-пакетов. В этом случае контролируется успешная доставка каждого пакета, и работа с ключом становится более надежной.
Для того, чтобы настроить защищенное приложение на работу через TCP-пакеты, необходимо сконфигурировать файл «nethasp.ini» следующим образом:
——————— «nethasp.ini» ——————————
[NH_COMMON]
NH_TCPIP = Enabled
…
[NH_TCPIP]
NH_SERVER_ADDR = 168.192.1.41
NH_TCPIP_METHOD = TCP
…
—————————————————————-
Адрес дан для примера, следует указывать реальный IP-адрес машины, где установлен менеджер лицензий. Далее (важно!) следует отключить в менеджере лицензий прослушивание UDP-протокола, оставив только TCP:
——————— «nhsrv.ini» ——————————-
…
[NHS_IP]
NHS_USE_UDP = disabled
NHS_USE_TCP = enabled
…
—————————————————————-
Если этого не сделать, то при получении «битых» UDP-пакетов менеджером ошибка может возникнуть вновь.
Некоторые приложения не работают по TCP, только по UDP (например, 1С 8.х). Однако можно заставить их использовать TCP неявно. Для этого, помимо того, что описано выше, необходимо разрешить в свойствах протокола TCP/IP (Properties — Advanced — WINS) поддержку NetBios over TCP/IP на рабочих станциях, где работает защищенное приложение и на машине, где установлен ключ. Конфигурационные файлы приложения необходимо настроить следующим образом:
——————— «nethasp.ini» ——————————
[NH_COMMON]
NH_TCPIP = Disabled
NH_NETBIOS = Enabled
…
[NH_NETBIOS]
…
NH_USELANANUM = … —————————————————————-
Значение параметра Num можно взять из лога менеджера лицензий – там указывается, какие каналы менеджер слушает по NetBios. Если номеров несколько, переберите их по очереди, пока 1С не запустится. При такой настройке 1С в качестве транспорта по-прежнему будет использовать TCP/IP, но работать с ним будет через интерфейс NetBios. Причем при передаче пакетов будет использоваться именно TCP-механизм в силу особенностей реализации NetBios over TCP/IP.
Автозагрузка приложения, использующего ключ защиты sentinel (hasp)
- Гарантия на ключи Sentinel (HASP) – 2 год.
- На батарейку в ключах моделей Sentinel (HASP) HL Time и Sentinel (HASP) HL NetTime – 4 года.
В чём различия между технологиями hasp4, hasp hl и sentinel ldk (srm)?
- HASP4 – устаревшая система защиты, была актуальна с 1996 по 2006 год и на данный момент полностью снята с поддержки.
- Для работы с системой защиты используются два пароля.
- HASP HL – устаревшая система защиты, на данный момент снята с поддержки.
- Для работы с системой защиты использовался белый HASP HL Master ключ. Реализована публичная криптография. Появилась поддержка удалённого обновления лицензий в ключах защиты.
- Sentinel LDK (SRM) / Sentinel HASP / HASP SRM – актуальная на данный момент система защиты, обладает обратной совместимостью с HASP4 и HASP HL.
- Для защиты ПО используется синий Sentinel HL Master ключ. Появилась поддержка:
- x64-битных ОС как для защищённых приложений, так и для самого комплекта разработчика.
- Программных ключей защиты – Sentinel (HASP) SL.
- Технологии AppOnChip – исполнения части кода приложения внутри ключа.
- Технологии Driverless – работа с ключом без установки драйвера, ключ определяется как HID совместимое устройство.
- Интеграции системы лицензирования с CRM системами по средствам API.
- Актуальных версий ОС симейств Windows, Linux и Mac OS X.и т.д.
- И т.д.
Взглянем
Утрируя, можно сказать, что HASP состоит из двух частей: аппаратной и программной. Аппаратная часть — это электронный ключик в виде USB-брелка, PCMCIA-карты, LTP-девайса или вообще внутренней PCI-карты. Установленный софт будет работать только на той машине, в которую воткнут электронный ключ. Собственно, неплохо было бы отучить софт от такой неприятной для кошелька привычки.
Программная часть — это драйвера электронного ключа и различный софт, привязывающий электронные ключи с их драйверами непосредственно к защищаемому продукту или к каким-то зашифрованным данным. В статье мы рассмотрим и обойдем защиту, использующую USB-брелок — наверное, наиболее популярный электронный ключ на сегодня.
Где взять документацию к комплекту разработчика?
Документация к комплекту разработчика есть на диске с самим комплектом разработчика, либо в образе диска. Она доступна на любом ПК с установленным комплектом разработчика.
Два ключа защиты по sentinel (hasp) на одном компьютере
При установке двух и более ключей защиты программного обеспечения Sentinel (HASP) на один компьютер следует учитывать, следующее:
- Ключи, имеющие разные серии, будут работать нормально.
- Для системы защиты HASP4: ключи одной серии будут работать, если такая возможность была реализована разработчиком защищенного ПО. Если же разработчиком данная возможность не была реализована, то ключи, относящиеся к одной серии, не будут работать совместно на одном компьютере, будет виден только один из них: либо ближний к порту (в случае с LPT-ключами), либо размещенный на порту с младшим адресом (в случае с USB-ключами защиты программ HASP).
- Для системы защиты HASP HL: ключи, относящиеся к одной серии, не будут работать совместно на одном компьютере, будет виден только один из них: либо ближний к порту (в случае с LPT-ключами), либо размещенный на порту с младшим адресом (в случае с USB-ключами защиты программ Sentinel (HASP)).
- Для системы защиты Sentinel LDK (SRM): ключи, относящиеся к одной серии, могут работать совместно на одном компьютере, будут видны все ключи. ПО будет работать с тем из них, на котором есть свободная лицензия, требуемая для работы защищённого приложения. Порядок опроса ключей, подключенных к ПК, определяется порядком размещения. Первым опрашивается ключ, размещенный на порту с младшим адресом, и т.д. по возрастанию адреса. Также для данной системы защиты можно контролировать, к какому ключу следует подключаться защищённому приложению. Реализуется это следующим образом:
Сначала используется функция hasp_get_info() для получения ID всех ключей. Далее выбирается нужный ID и при помощи функции hasp_login_scope открывается сессия с ключом. Более подробно можно посмотреть в утилите Sentinel LDK ToolBox (интерактивное руководство по функциям Sentinel LDK Licensing API), которая устанавливается в составе Sentinel LDK Vendor Suite.
Возможные решения данной проблемы:
- Замена нескольких ключей защиты программ Sentinel (HASP) на один, с большим количеством лицензий (необходимо обратиться к разработчику защищенного программного обеспечения).
- Установка ключей защиты на разные компьютеры с последующей установкой и настройкой менеджеров лицензий при каждом ключе, см. «Два и более менеджеров лицензий (HASP License Manager) в сети«.
- Возможность обрабатывать наличие двух ключей на одном компьютере существует для систем защиты HASP4 (путем адресации запроса на конкретный порт) и Sentinel LDK (SRM) (с помощью функции hasp_get_info() и hasp_login_scope). Для системы защиты HASP HL данная возможность отсутствует.
Есть ли совместимость у ключей sentinel (hasp) с предыдущими версиями, если есть, то какая?
Ключ HASP4 может работать только с системой защиты HASP4 и не поддерживает работу с другими системами защиты.
Ключ Sentinel (HASP) HL обладает обратной совместимостью со старыми системами защиты. Чтобы использовать ключи Sentinel (HASP) HL со старыми системами защиты, необходимо применять инструменты из соответствующих версий комплектов разработчика (API / Envelope / утилиты для записи лицензий в ключи: HASP4 — HASPEdit, HASP HL — Factory, Sentinel LDK (SRM) — Business Studio / Sentinel LDK EMS).
Современная система защиты Sentinel LDK (SRM) обладает обратной совместимость с предыдущими системами защиты HASP HL и HASP4:
- На уровне драйвера. Драйвер от современной системы защиты поддерживает работу ключей и от более старых систем защиты.
- На уровне API. API от современной системы защиты поддерживает вызовы старых функций API от более старых систем защиты.
- На уровне утилиты автоматической защиты Sentinel LDK Envelope. Sentinel LDK Envelope поддерживает защиту приложений в режиме системы защиты HASP HL, для защиты используются вызовы функций API от соответствующей системы защиты.
Какие варианты защиты существуют?
Возможны три варианта защиты вашего ПО:
- С помощью утилиты автоматической защиты Envelope: скомпилированный файл «.exe», «.dll», «.jar» и т.д. (зависит от используемой системы защиты и комплекта разработчика) добавляется в проект защиты утилиты Envelope, для него указываются требуемые настройки защиты, после чего осуществляется автоматическая защита программного обеспечения. На выходе получается файл с таким же расширением, но только уже со встроенными механизмами защиты ПО, такими как:
- Привязка к ключу защиты;
- Шифрование кода приложения;
- Обфускация кода приложения;
- Борьба с отладчиками и многое другое, в зависимости от используемой системы защиты и версии используемого комплекта разработчика.
- С помощью API из комплекта разработчика: разработчику предоставляется набор функций API для работы с ключами защиты (проверка наличия ключа защиты с необходимой лицензией, чтение/запись в память ключа, шифрование данных с помощью криптопроцессора ключа и т.д.), на базе которых он должен самостоятельно реализовать требуемые механизмы защиты своего ПО и встроить их в код своего приложения. Данный вариант крайне гибок, так как реализация защиты целиком и полностью зависит от фантазии разработчика, но и гораздо более сложен, нежели вариант с автоматической защитой с помощью утилиты Envelope.
- Комбинация первых двух вариантов: часть функционала работы с ключом разработчик реализует в коде своего приложения с помощью API из комплекта разработчика, а потом скомпилированный файл обрабатывает утилитой Envelope. Данный метод наиболее гибок и надёжен в плане защиты ПО.
Компания Thales регулярно проводит бесплатные семинары по построению надёжной защиты на базе API на территории СНГ. Расписания мероприятий доступно на сайте: https://safenet-sentinel.ru/
Какие документы нужны для отправки ключа за границу?
Если для защиты или лицензирования своего ПО вы использовали:
- Два пароля. – Система защиты HASP4.
- Белый Master ключ. – Система защиты HASP HL.
- Синий Master ключ. – Система защиты Sentinel LDK (SRM).
Также существуют другие косвенные признаки использования той или иной системы защиты, например:
- Версия используемого комплекта разработчика 1.3 или ниже – система защиты HASP HL; выше 1.3 – система защиты Sentinel LDK (SRM);
- Для лицензирования ПО используете утилиту Business Studio – система защиты Sentinel LDK (SRM) версии 5.хх и ниже;
- Для лицензирования ПО используете утилиту Sentinel LDK EMS – система защиты Sentinel LDK (SRM) версии 6.х и выше;
- Для лицензирования ПО используете утилиту Factory – система защиты HASP HL;
- Для лицензирования ПО используете утилиту HASP Edit – система защиты HASP4;
- Если вы используете утилиту Bistro – система защиты Hardlock;
- Используете драйверы версии 4.102 или 4.116, и утилиты HASP License Manager и Aladdin Monitor – вероятнее всего либо система защиты HASP4, либо HASP HL (но для HASP HL более характерны драйверы версии 5.20).
Механизм системы защиты
Сам брелок нас почти не интересует, в отличие от ПО в его комплекте. Для нас наибольший интерес представляет модуль hardlock.sys. Не углубляясь в подробности, отмечу, что этот драйвер отвечает за взаимодействие с аппаратным ключом. Он имеет два объекта устройства, один из которых обладает символьным именем DeviceFNT0.
Главным недостатком такой системы защиты является возможность перехвата вызовов диспетчера ввода-вывода и эмулирования аппаратного ключа. Существует также вариант разработки драйвера виртуального ключа, но это гораздо более сложная техническая задача, нежели перехват вызовов.
Как тебе известно, модель драйвера описывается в структуре DRIVER_OBJECT при загрузке модуля. Она хранит массив обработчиков сообщений. Причем никто не мешает переписать эти адреса и получить управление, выполнив наш код. Таким образом, можно перехватывать и подменять IRP-пакеты, подставляя лицензионные данные. Другими словами, имея дамп ключа защиты, можно передать его программе, проверяющей верность лицензионных данных!
Для эксплуатации другого метода также требуется дамп ключа, но подстановка данных осуществляется иначе, а именно — в программной эмуляции. То есть драйвер защиты сможет обращаться с виртуальным ключом так же, как и с физическим.
Обработчик
Теперь есть все необходимое для корректной работы модуля. Осталось реализовать подстановку лицензионной информации. Причем можно перехватывать лишь некоторые IRP-пакеты. Здесь все уже зависит от конкретной версии ключа и защищаемой программы.
Дамп ключа лучше не встраивать в драйвер, а загружать динамически из реестра. Лучше основываться на уже готовом перехватчике запросов, так будет проще отладить драйвер, отправляя перехваченные/подставленные пакеты на анализ пользовательскому приложению. Принципиально логика перехватчика будет иметь такой вид:
NTSTATUS HookDispatch():
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);}}
Return STATUS_FAILED;
Пакет запроса к драйверу находится в криптованном виде, поэтому для доступа к его содержимому требуется расшифровать, а затем зашифровать. Возникает вопрос: каким алгоритмом и каким ключом выполнено шифрование? Покопавшись в исходниках от создателей системы, можно получить следующий первичный алгоритм шифрования пакета:
Код Encrypt()
void Encrypt(BYTE * Buffer){WORD Seed = ((WORD)Buffer 0x5e);WORD Ver = ((WORD)Buffer 0xba);
if (Ver){for (int i = 0; i < 0xB9; i ) {(WORD)(Buffer i) = Seed;Seed = (Seed >> 15) | (Seed << 1);Seed -= (WORD)(Buffer i) ^ i;}
for (int i = 0xBE; i < 0xFF; i ) {(WORD)(Buffer i) -= Seed;Seed = (Seed >> 15) | (Seed << 1);Seed = (WORD)(Buffer i) ^ i;}
((WORD)Buffer 0xba) = Seed;}}
Видно, что алгоритм гораздо сложнее, чем обычный сдвиг и исключающее «или». А вот алгоритм дешифрования:
Код Decrypt()
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 << 15) | (Seed >> 1);(WORD)(Buffer i) = Seed;}
for (int i = 0xB8; i >= 0; i—) {Seed = (WORD)(Buffer i) ^ i;Seed = (Seed << 15) | (Seed >> 1);(WORD)(Buffer i) -= Seed;}
((WORD)Buffer 0xba) = Seed;}}
Затем следует ещe один этап преобразования данных, более сложный и уже полностью зависящий от структуры запроса. Тут не обойтись без дизассемблера, придется покопаться в бине и позаимствовать немного кода у создателей. Это непросто, так как код драйвера защиты сильно обфусцирован, но он не отличается разнообразием уловок. Достаточно будет декомпилировать драйвер не полностью, а только лишь некоторые кусочки кода.
В заключение отмечу, что построение табличного эмулятора, основанного на перехвате DeviceIoControl, — достаточно трудная задача. Но такой принцип эмулятора можно использовать и на другом уровне взаимодействия: создать виртуальную USB-шину.
Ошибка «hasp not found (0)»
Такая ошибка иногда возникает, если защищенное приложение или ключ установлены на машине с более чем одним сетевым интерфейсом. Для устранения следует отключить второй сетевой интерфейс или переставить ключ/приложение на машину с одним сетевым интерфейсом.
Перехват и эмуляция
Как уже отмечалось, идея перехвата состоит в перезаписи обработчиков IRP-пакетов. Для этого необходимо иметь возможность изменять поля структуры DRIVER_OBJECT. К счастью, существует функция IoGetDevicePointer, которая возвращает указатель на объект вершины стека именованных устройств и указатель на соответствующий файловый объект. Вот фрагмент кода функции, устанавливающей ловушку:
NTSTATUS HookDevice(LPWSTR lpDevice)
UNICODE_STRING DeviceName;PDEVICE_OBJECT DeviceObject;PFILE_OBJECT FileObject;
RtlInitUnicodeString(&DeviceName, lpDevice);IoGetDeviceObjectPointer(&DeviceName, 1u, &FileObject, &DeviceObject);
Получив указатель на структуру 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(FileObject);
В последней строчке вызывается функция ObfDereferenceObject, которая уменьшает количество ссылок на файловый объект. Это необходимо делать для корректной выгрузки драйвера, чтобы не было утечки ресурсов и аналогичных ошибок.
Так как указатель на объект драйвера защиты сохранeн, то чтобы снять ловушку, нужно просто восстановить прежние обработчики IRP-пакетов:
void UnhookDevice(void)
gDriverObject-> MajorFunction[IRP_MJ_DEVICE_CONTROL] = gDeviceControl;gDriverObject-> MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = gInternalDeviceControl;gDriverObject->DriverUnload = gDriverUnload;
Конечно, надо добавить соответствующие проверки на валидность указателей и прочее.
Теперь необходимо реализовать правильную выгрузку драйверов. Так как система защиты по каким-либо причинам может закончить свою работу раньше нашего драйвера, то чтобы избежать краха системы из-за неверных указателей, обработаем это событие в функции HookUnload:
void HookUnload(PDRIVER_OBJECT DrvObj)
UnhookDevice();gDriverUnload(DrvObj);
Здесь происходит восстановление полей структуры DRIVER_OBJECT, и передаeтся управление на оригинальный код выгрузки драйвера перехваченного устройства.
Аналогично поступаем, если наш драйвер завершает работу раньше системы защиты. Только нужно высвободить захваченные ресурсы и не вызывать сохранeнный gHookUnload.
Принцип работы эмулятора
Перехватчик
Зная основные принципы простейшего перехвата IRP-пакетов, приступим к реализации пока только самого перехватчика для дальнейшего анализа. Для этого создадим объект драйвера, который содержит символьное имя (например DosDevicesHook) и точки входа CREATE, CLOSE, READ.
IoCreateDevice(DriverObject, 0, &usDeviceName, FILE_DEVICE_NULL, 0, 0, &pDeviceObject);IoCreateSymbolicLink(&usSymbolicDeviceName, &usDeviceName);
DriverObject->MajorFunction[IRP_MJ_CREATE] = DriverDispatch;DriverObject->MajorFunction[IRP_MJ_CLOSE] = DriverDispatch;DriverObject->MajorFunction[IRP_MJ_READ] = DriverDispatch;DriverObject->DriverUnload = DriverUnload;
Это нужно для того, чтобы работать с нашим перехватчиком как с файлом, используя функции CreateFileReadFileCloseHandle. При такой реализации обмена данными между приложением и перехватчиком невозможно сразу же отправить их пользовательской программе, поэтому необходимо создать некоторую структуру для хранения необходимых данных о пойманном пакете.
Например односвязный список, как это реализовано мной. Теперь следует определиться, какую информацию нужно буферизировать. Это общая информация о пакете (тип, флаги, прочее) и, конечно, буферы. Также можно добавить время перехвата. При копировании содержимого буферов нужно помнить об их типе, иначе — крах. Забегая вперед, отмечу, что драйвер защиты использует буферизированный ввод-вывод, это немного упрощает код.
Код HookDispatch
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);}
Осталось реализовать чтение из драйвера. Так как пакет содержит буферы, чье содержимое представляет интерес, то размер сообщений заранее не известен. Поэтому поступим следующим образом: при первом чтении получаем общую информацию о пакете и размере буферов; при повторном читаем содержимое, удаляем звено из списка пакетов и не забываем про спиновые блокировки для последовательной работы с данными:
Код DriverDispatch
Процедура установки/удаления драйвера ключа
Для OS Windows Vista и ниже необходимо выполнять оба раздела инструкции, для Windows 7 и выше только «Раздел II».
Перед установкой/удалением необходимо убедиться, что UAC отключен и после его отключения ПК был перезагружен.
Раздел I. Удаление драйверов версии 4.116 и ниже.
- Войти в систему как администратор.
- Если возможно, следует временно отключить любое защитное ПО (антивирус, брандмауэр).
- Отключить все локальные Sentinel (HASP) ключи.
- Загрузить драйвер 4.116: http://safenet-sentinel.ru/files/hasp4_driver_cmdline.zip для проверки, не установлено ли старых версий драйверов.
- Распаковать загруженный архив на диск и в командной строке перейти в директорию с файлами из архива.
- Запустить «hinstall –r –alldrv» для удаления версий, установленных ранее.
- Если возникли проблемы с удалением, обратитесь к пункту настоящей инструкции «ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА».
Раздел II. Установка/удаление драйверов версии 5.х и выше.
- Войти в систему как администратор.
- Если возможно, следует временно отключить любое защитное ПО (антивирус, брандмауэр).
- Скачать свежую консольную версию драйвера: https://thales-sentinel.ru/helpdesk/download-space/
- Отключить все локальные Sentinel (HASP) ключи.
- Разархивировать драйвер.
- Выполнить из командной строки «haspdinst.exe –fr –kp –purge» для удаления версий, установленных ранее.
- Выполнить «haspdinst.exe –i» для установки драйвера.
- Если возникли проблемы с удалением, следует обратиться к пункту инструкции «ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА».
- Открыть браузер и перейти по адресу http://localhost:1947; проверить, что ключ отображается на странице «Sentinel Keys».
- Проверить, что приложение работает. Если нет:
- Использовать «MsConfig» для остановки всех служб, которые не относятся к Microsoft, перезагрузите компьютер и проверить снова.
- В случае отказа системы необходимо сохранить «дамп памяти ядра».
- В случае отказа Менеджера лицензий (HASP License Manager) необходимо сохранить лог (event log: Пуск -> Панель управления -> Администрирование -> Просмотр событий) и сохранить скриншот возникающей ошибки.
- Удалить файл «C:Windowsaksdrvsetup.log», запустить «haspdinst –i –v», сохранить созданный файл aksdrvsetup.log
- Запустить «MsInfo32» (Пуск -> выполнить -> msinfo32 -> Ввод), создать .NFO log и выслать его.
Все сохранённые данные по проблеме необходимо передать в службу технической поддержки, порядок обращения в техническую поддержку см. «Порядок обращения в техническую поддержку«.
ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА
- Удалить все компоненты HASP через «Установка/удаление программ».
- Остановить все службы, которые содержат в названии «Hasp» или «HLServer».
- Удалить все файлы aks*.*, «hardlock.sys» и «haspnt.sys» из папки c:windowssystem32drivers» (если они не используются другими приложениями).
- Удаление драйверов в «Диспетчере устройств»:
o Зайти в «Панель управления»«Система».
o Перейти на вкладку «Оборудование» и откройте «Диспетчер устройств».
o Выбрать в меню «Показать скрытые устройства».
o Раскрыть пункт «Драйверы устройств не Plug and Play».
o Удалить каждый из следующих пунктов, если они присутствуют: «Hardlock», «Haspnt», «HASP fridge».
- Еще раз удалить драйверы с помощью команды «haspdinst –purge», а затем установить с помощью «haspdinst –i».
Работа ключа на удаленной машине – настройка «nethasp.ini»
Для того, чтобы защищенное приложение нормально работало на удаленной рабочей станции, необходимо обеспечить беспрепятственный проход UDP- и TCP-пакетов по порту 475 в обе стороны. Также должны проходить и broadcast-пакеты. Если последнее требование не выполняется, необходима настройка приложения через файл «nethasp.ini» (должен находится в одной директории с защищенным приложением) с целью отключения broadcast-механизма поиска ключа и явного указания IP-адреса машины, обслуживающей ключ.
Пример «nethasp.ini»:
[NH_COMMON]
NH_TCPIP = Enabled
…
[NH_TCPIP]
NH_SERVER_ADDR = 168.192.1.41 //ip-адрес компьютера, где расположен менеджер лицензий.
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = Disabled
Однако если часть маршрута проходит через Интернет, могут возникнуть проблемы с тайм-аутами при доставке пакетов.
Работа приложений, защищенных при помощи электронных ключей hasp4, hasp hl и sentinel hl в рамках системы защиты hasp4 под windows vista
Для работы приложения, защищенного при помощи электронных ключей HASP4, HASP HL и Sentinel HL в рамках системы защиты HASP4 под Windows Vista должны выполняться следующие требования:
2) Версия HASP4 API, использованного при защите программы, не ниже 8.01.
3) Версия HASP4 Envelope (instw32.exe), использованного при защите, не ниже 12.10.
Заключение
Это не единственный способ избавиться от системы защиты. Существуют и другие, более совершенные методы. Изложенные в статье принципы можно использовать и для анализа работы драйверов, перехватывая IRP-пакеты. Таким образом можно добавить неплохой инструмент в свой сделанный на коленке набор. Удачи!