Hasp программа что это

Записки IT специалиста

Ключи защиты 1С Предприятие 8.1. Особенности использования.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Какие бывают ключи

Локальные однопользовательские ключи представлены моделью HASP HL Basic (синего цвета), данный ключ имеет маркировку H4 M1 ORGL8, не имеет встроенной памяти и персонального ID, не хранит в себе никаких параметров и настроек. Поставляется продуктами имеющими лицензию на одно рабочее место.

Система ХАССП в ресторане | Просто о сложном | Часть №1

Сетевые клиентские ключи включают серию HASP HL Net (красного цвета). Имеют внутреннюю память, в которой хранится количество лицензий, и уникальный ID. Существуют разновидности на 5, 10, 20, 50 и 100 пользователей. Имеет маркировку NETXX ORGL8, где ХX — количество лицензий (например NET5 ORGL8).

Существуют также ключи на 300 и 500 пользователей которые имеют маркировку NET250+ ORG8A и NET250+ ORG8B. Поставляются с продуктами имеющими лицензию на 5 рабочих мест, а также отдельно, в виде дополнительных клиентских лицензий.

Ключи для сервера 1С Предприятие бывают только локальные. 32-битная версия имеет ключ защиты HASP HL Pro (фиолетового цвета), который имеет внутреннюю память и уникальный ID. Имеет маркировку ENSR8, поставляется вместе с лицензией на сервер 1С Предприятие.

Для 64-битного сервера используется ключ HASP HL Max (зеленого цвета) с внутренней памятью и уникальным ID. Имеет маркировку EN8SAи поддерживает также 32-битный сервер. Т.е. имея лицензию на 64-битный сервер можно, не меняя ключа, использовать 32-битную версию, но не наоборот.

Как правильно устанавливать ключи

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

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

Все принципы ХАССП за 5 минут.

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

На машине где установлен ключ находим файл nhsrv.ini в папке с менеджером лицензий. За имя сервера лицензий отвечает параметр NHS_SERVERNAMES, оно может состоять из латинских букв и цифр и содержать не более 7 символов.

[NHS_SERVER]
NHS_SERVERNAMES = NAME1

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

[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.0.10, 192.168.0.11
NH_SERVER_NAME = NAME1, NAME2

Какие бывают ошибки

К сожалению 1С Предприятие вместо штатных сообщения HASP об ошибках выводит собственное «Не обнаружен ключ защиты программы!» . Под этим сообщением может скрываться четыре вида ошибок, рассмотрим их подробнее.

• Не найден ключ. Пожалуй самая распространенная ошибка. Возникает при отсутствии ключа, попытке использования ключа от другого продукта. Для сетевых ключей эта ошибка может возникать при отсутствии сети, если на машине с ключом не запущен менеджер лицензий, закрыт 457 порт или ошибочно установлен несетевой ключ.
• Ключ не содержит лицензии. Возникает при установке на один ПК двух ключей одной серии, при этом виден тот из них, на котором отсутствует нужная лицензия. При работе в сети двух менеджеров лицензий с одинаковыми именами и обслуживающими ключи одной серии приложение может найти первым ключ не содержащий нужной лицензии, что также приведет к получению этой ошибки.
• Обнаружена служба терминалов. Возникает при попытке запустить приложение из терминальной сессии с локальным ключом. Может также возникнуть в случае если в nethasp.ini явно не прописан адрес менеджера лицензий.
• Превышено число лицензий. Возникает когда количество пользователей (активных сессий) превышает число указанных в ключе лицензий. При работе в сети двух менеджеров лицензий с одинаковыми именами и обслуживающими ключи одной серии приложение может найти первым ключ с которым уже установлено максимальное количество соединений, что также приведет к получению этой ошибки.

Дополнительные материалы:

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Источник: interface31.ru

Статьи и публикации

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

Большинство компьютерных программ распространяется по принципу владения оговоренным количеством рабочих копий (в простейшем случае — только одной). Естественно, общепринятый в международной практике термин «защита от копирования» достаточно условен, так как практически всегда можно переписать информацию, находящуюся на носителе, и сделать сколько угодно ее резервных копий. Другое дело, что для сохранения коммерческих и авторских прав разработчиков программа все равно должна выполняться только на одном компьютере. Таким образом, фактически защита от копирования для программного обеспечения — это невозможность выполнения программы на большем числе компьютеров, чем разрешено ее разработчиками и распространителями по данному договору. Следовательно, для сохранения прав необходимо наличие средств, дающих возможность защиты от несанкционированного выполнения — чтобы без санкции разработчика или фирмы-распространителя невозможно было получить работоспособный программный продукт.

Наиболее распространенным и надежным способом защиты от несанкционированного запуска стали программно-аппаратные ключи, подключаемые к COM-, LPT- или USB-портам. Почти все коробочные варианты серьезного коммерческого ПО используют программно-аппаратные комплексы защиты, более известные как аппаратные ключи защиты. Такие способы защиты основаны на том, что в компьютер добавляется специальное физическое защитное устройство, к которому при запуске защищаемой программы обращается ее контролирующая часть, проверяя наличие ключа доступа и его параметров. Если ключ не найден (устройства обычно формируют еще и код ответа, который затем анализируется программой), то программа не запустится (или не будет разрешен доступ к данным).

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

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

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

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

Сегодня все острее встает проблема обеспечения безопасности при использовании сетевых технологий и все более насущной становится потребность в решениях по защите мобильных пользователей. Появляются и беспроводные аппаратные ключи защиты приложений, работающие по технологии Bluetooth. Так, тайваньская компания First International Computer продемонстрировала PDA с соответствующим модулем и беспроводной аппаратный ключ защиты приложений BlueGenie, разработанный в сотрудничестве с Silicon Wave.

Одним из наиболее распространенных в России защитных устройств такого типа является устройство HASP (Hardware Against Software Piracy) от компании Aladdin, по сути ставшее стандартом де-факто. Aladdin Software Security R.D. — это российская компания, представитель мирового лидера в области разработки и производства систем аутентификации, защиты информации при работе с Интернетом и защиты программного обеспечения от несанкционированного использования Aladdin Knowledge Systems Ltd.

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

Затем появились USB-HASP-устройства. Иметь маленький USB-ключ значительно удобнее, чем большой 25-штырьковый сквозной разъем, да и часто возникающие проблемы с совместимостью ключей и устройств, работающих через параллельный порт, типа принтеров и ZIP-дисководов изрядно утомляли пользователей. А с USB-устройствами работает автоматическое подключение (рlug-and-рlay), порты USB выносятся на переднюю панель, встраиваются в клавиатуру и монитор. А если даже такого удобного разъема под рукой нет, то в комплекте с этими ключами часто продают удлинители. Существуют несколько разновидностей ключей — с памятью, с часами и т.д.

Основой ключей HASP является специализированная заказная микросхема — ASIC (Application Specific Integrated Circuit), имеющая уникальный для каждого ключа алгоритм работы. Принцип защиты состоит в том, что в процессе выполнения защищенная программа опрашивает подключенный к компьютеру ключ HASP. Если HASP возвращает правильный ответ и работает по требуемому алгоритму, то программа выполняется нормально. В противном случае, по усмотрению разработчика программы, она может завершаться, переключаться в демонстрационный режим или блокировать доступ к каким-либо функциям программы.

Используя память ключа, разработчик может:

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

У каждого ключа HASP с памятью имеется уникальный опознавательный номер, или идентификатор (ID-number), доступный для считывания защищенными программами и позволяющий различать пользователей. Идентификатор присваивается электронному ключу в процессе изготовления, что делает невозможным его замену, но гарантирует надежную защиту от повтора. С использованием идентификатора можно шифровать содержимое памяти и использовать возможность ее дистанционного перепрограммирования.

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

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

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

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

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

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

Каждому брелоку eToken можно присвоить уникальное имя, например имя его владельца. Чтобы узнать имя владельца eToken, достаточно подключить брелок к USB-порту и открыть окно «Свойства». Однако получить доступ к защищенной памяти eToken и воспользоваться этим брелоком без знания специального PIN-кода нельзя.

Кроме того, eToken выполнен в прочном водонепроницаемом корпусе и защищен от воздействия окружающей среды. Он имеет защищенную энергонезависимую память (модели PRO и RIC снабжены микропроцессором). Небольшой размер позволяет носить его на связке с ключами.

Если нужно подключить к компьютеру несколько ключей одновременно, а USB-портов не хватает, то можно воспользоваться концентратором (USB-HUB). Для удобства применения eToken поставляется вместе с удлинителем для USB-порта.

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

В случае если объем конфиденциальной информации довольно значителен, можно воспользоваться устройством Secret Disk, выполненным с применением технологии eToken. Secret Disk — это разработка компании Aladdin Software Security R.D., предназначенная для защиты конфиденциальной информации на персональном компьютере с ОС Windows 2000/XP.

Принцип защиты данных при помощи системы Secret Disk заключается в создании на компьютере пользователя защищенного ресурса — секретных дисков, предназначенных для безопасного хранения конфиденциальной информации. Доступ к этой информации осуществляется посредством электронного ключа eToken, подсоединяемого к USB-порту компьютера. Доступ к информации, защищенной системой Secret Disk, получают только непосредственный владелец информации и авторизованные им доверенные лица, имеющие электронный ключ eToken и знающие его PIN-код. Для других пользователей защищенный ресурс будет невидим и недоступен. Более того, они даже не догадаются о его наличии.

Устанавливая на компьютере систему Secret Disk, пользователь может быть уверен в сохранности защищаемых данных. Конфиденциальная информация не может быть просмотрена, скопирована, уничтожена или повреждена другими пользователями. Она не может быть использована посторонними при ремонте или краже компьютера, а также при утере съемного зашифрованного диска.

Для защиты корпоративных серверов используется специальная версия — Secret Disk Server. Особенностью системы Secret Disk Server также является отсутствие следов закрытого «контейнера с информацией» в файловой системе. Таким образом, если злоумышленники снимут диск с вашего сервера, то они не только не смогут расшифровать данные — они даже не увидят, где именно находится информация.

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

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

Что касается проблем аутентификации, то все чаще применяется технология PKI (Public Key Infrastructure), использующая системы сертификатов и специальных серверов для их проверки — центров сертификации CA (Certification Authorities). Одни из самых популярных систем сертификации — RSA Keon, Baltimore, Verisign и Entrust, работающие по протоколам HTTP и LDAP (сертификаты X.509). Центр сертификации уже входит в поставку Windows 2000 Server; в платформе .Net будет встроена поддержка цифровых сертификатов. Остается нерешенной только проблема защищенного хранения цифровых сертификатов.

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

Источник: www.aladdin-rd.ru

HASP — общие вопросы

Серия разработчика = Batch code = код разработчика = серия ключей – равнозначные понятия.

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

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

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

Batch code нанесён на корпус каждого ключа (как пользовательского, так и служебного) и выглядит как последовательность из нескольких латинских символов, вида: «CDQDR», «DEMOMA» и т.д.

DEMOMA — серия разработчика, присвоенная демонстрационным ключам. Серия DEMOMA интегрирована в комплект разработчика и предназначена для тестирования функционала комплекта разработчика. Для работы с ключами серии DEMOMA не требуется наличие Sentinel (HASP) HL Master ключа.

Vendor ID – числовой эквивалент серии разработчика, отображается в Sentinel Admin Control Center на вкладке Sentinel Keys в столбце Vendor для подключенного ключа. Исключение – служебные ключи Sentinel (HASP) HL Master и Sentinel (HASP) HL Developer. Для этих ключей Vendor ID всегда одинаковый – «64294» и отличен от Vendor ID серии разработчика клиента.

Vendor ID содержится в именах всех кастомизированных под данную конкретную серию разработчика библиотек Sentinel LDK Licensing API из комплекта разработчика.

Обновление прошивки (firmware) ключа HASP HL до версии 3.25

Обновление микропрошивки в стандартном режиме производится автоматически при соблюдении двух условий:

1. Наличия на ПК актуальной версии установленного драйвера для ключей Sentinel (HASP);
2. Наличия на ПК активного интернет соединения.

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

Если же обновление микропрошивки не было произведено в автоматическом режиме, то есть возможность выполнить это вручную. Сделать это можно двумя способами:

• Обновление USB-ключей HASP HL до функциональности HASP SRM с помощью утилиты Firmware Update: ftp://ftp.cis-app.com/pub/hasp/Sentinel_HASP/Firmware_Update/HASP_HL_Firmware_Update.zip
• Обновление USB-ключей HASP HL до функциональности HASP SRM с помощью файла* V2C: ftp://ftp.cis-app.com/pub/hasp/Sentinel_HASP/Firmware_Update/HASP_HL_Firmware_Update_v2c.zip

*Файл применяется к ключу с помощью: стандартной утилиты RUS под данную серию разработчика, либо через интерфейс драйвера — Sentinel Admin Control Center.

Процедура установки/удаления драйвера ключа

Для OS Windows Vista и ниже необходимо выполнять оба раздела инструкции, для Windows 7 и выше только «Раздел II».

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

Раздел I. Удаление драйверов версии 4.116 и ниже.

1. Войти в систему как администратор.
2. Если возможно, следует временно отключить любое защитное ПО (антивирус, брандмауэр).
3. Отключить все локальные Sentinel (HASP) ключи.
4. Загрузить драйвер 4.116: http://safenet-sentinel.ru/files/hasp4_driver_cmdline.zip для проверки, не установлено ли старых версий драйверов.
5. Распаковать загруженный архив на диск и в командной строке перейти в директорию с файлами из архива.
6. Запустить «hinstall –r –alldrv» для удаления версий, установленных ранее.
7. Если возникли проблемы с удалением, обратитесь к пункту настоящей инструкции «ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА».

Раздел II. Установка/удаление драйверов версии 5.х и выше.

1. Войти в систему как администратор.
2. Если возможно, следует временно отключить любое защитное ПО (антивирус, брандмауэр).
3. Скачать свежую консольную версию драйвера: https://thales-sentinel.ru/helpdesk/download-space/
4. Отключить все локальные Sentinel (HASP) ключи.
5. Разархивировать драйвер.
6. Выполнить из командной строки «haspdinst.exe –fr –kp –purge» для удаления версий, установленных ранее.
7. Выполнить «haspdinst.exe –i» для установки драйвера.
8. Если возникли проблемы с удалением, следует обратиться к пункту инструкции «ПРОБЛЕМЫ ВО ВРЕМЯ УСТАНОВКИ ДРАЙВЕРА».
9. Открыть браузер и перейти по адресу http://localhost:1947; проверить, что ключ отображается на странице «Sentinel Keys».
10. Проверить, что приложение работает. Если нет:

• Использовать «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».

Работа с ключом на виртуальных машинах

Работа на виртуальных машинах ограничивается двумя факторами:

1. Используемой системой защиты.
2. Используемой платформой виртуализации.

Для каждой системы защиты есть свой список официально поддерживаемых платформ виртуализации, посмотреть который можно либо на сайте sentinelcustomer.safenet-inc.com/platformsupport/, либо в документации к используемому комплекту разработчика.

Некоторые платформы виртуализации не поддерживают проброс USB устройств с реальной машины в виртуальную, например Microsoft Virtual Server + Hyper-V.

При использовании виртуальных сред с балансировкой нагрузки может происходить блокировка работы программных ключей Sentinel (HASP) SL, так как при балансировке нагрузки виртуальная машина фактически «перемещается» с одного физического ПК на другой, вследствие чего изменяется параметр привязки CPU ID, подробнее см. «Ошибка SL Clone detected».

Ошибка: «HASP not found (-10), (-11), (Error 27), (H0027), Terminal services detected»

Возникновение данной ошибки возможно в следующих случаях.

1. При обнаружении программ терминального доступа типа Microsoft Terminal Server (в т.ч. служба RDP – Remote Desktop), Citrix Winframe/Metaframe и т.д. драйвер ключа блокирует доступ к ключу. Т.е. ключ не должен находиться на одной машине с активным терминальным ПО. Для систем защиты HASP HL и Sentinel HASP* разработчик защищенного приложения имеет возможность контролировать данную опцию, разрешая или запрещая работу на терминальном сервере. Для ключей HASP4 она задана жестко и не может быть отключена. Если вы являетесь пользователем защищенного ПО, то варианты решения данного вопроса следующие:
2. Остановить работу терминального сервера.
3. Разместить ключ на любом другом компьютере в сети, если ключ сетевой.
4. Обратиться к разработчику защищенного ПО.
5. Ошибка «HASP not found (-10)» также может возникать при запуске приложений, защищенных с помощью HASP4 под Windows Vista/Windows 7.

* Для стандартной Feature 0, которая есть во всех ключах по умолчанию, лицензионные ограничения изменять нельзя. При этом для всех локальных ключей Sentinel HL для Feature 0 запрещена работа в терминальном режиме, а для сетевых ключей Sentinel (HASP) HL Net и сетевых ключей Sentinel (HASP) HL NetTime – разрешена. Соответственно, если защита программ осуществляется через Sentinel LDK Envelope на Feature 0 (например, используется DataHASP, который для своей работы использует Feature 0), то защищённое таким образом ПО может работать на терминальном сервере только с сетевым ключом, в котором для Feature 0 разрешён терминальный режим. С локальными ключами ПО будет выдавать ошибку «HASP_TS_DETECTED = 27».

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

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

!Update!: в системе защиты Sentinel LDK (в актуальной версии SDK LDK), для локальных моделей ключей Sentinel HL, работающих в Driverless режиме (для всех моделей кроме Sentinel HL Basic), есть возможность записывать сетевые лицензии с разрешённой / запрещённой работой RDP и с подсчётом подключений: по станциям, по процессам и по логинам. Благодаря чему любую, изначально локальную модель ключа можно превратить в сетевую. Но этот функционал требует приобретения дополнительных лицензий (HL seats) на Ваш Мастер ключ.

Ошибка «HASP not Found (-3), (Error 7), (H0007)»

Возникновение данной ошибки возможно в следующих случаях.

• Ключ Sentinel (HASP) не подсоединен к компьютеру. Необходимо подсоединить ключ защиты.
• Подсоединен ключ Sentinel (HASP) другой серии (ключ от другого ПО). Необходимо подсоединить ключ требуемой серии (ключ от данного приложения).
• Сетевой ключ, подсоединенный к компьютеру в сети, на самом деле не является сетевым (сетевой ключ должен содержать в себе сетевую лицензию). Следует проверить установленный ключ и, в случае ошибки, подключить требуемый сетевой ключ Sentinel (HASP).
• На компьютере, где установлен сетевой ключ Sentinel (HASP), не запущен менеджер лицензий. Следует установить и запустить менеджер лицензий.
• На компьютере, где установлен ключ, или на компьютере, где запускается защищенное приложение, блокируется передача трафика по 475 или 1947 порту (активен firewall, брандмауэр windows, антивирусные программы также могут блокировать передачу по сети). Необходимо отключить все ПО, которое может блокировать доступ к ключу.

Какие существуют утилиты для мониторинга доступа к ключу и занятых лицензий?

• Для систем защиты HASP4 и HASP HL в этих целях используется утилита Aladdin Monitor.
• Для системы защиты Sentinel LDK (SRM) в этих целях используется менеджер лицензий Sentinel Admin Сontrol Center, встроенный в драйвер ключа и доступный по адресу: http://localhost:1947/

Источник: www.euromobile.ru

AntiHASP: эмулируем ключ аппаратной защиты HASP

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

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);
>

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

idlTemp = idlHead->ldlNext;
ExFreePool(idlHead);
idlHead = idlTemp;
if (!idlTemp)
idlTail = NULL;
>

Когда перехватчик готов, запускаем сначала его, а затем — защищенное приложение с ключами и без. Из полученных логов становится видно, какие управляющие коды посылаются и их результаты. Также можно видеть, что запросы и ответы на два различных кода (9c402450, 9c4024a0) не изменяются. Казалось бы, можно построить табличный эмулятор, но после серии запусков убеждаемся, что это невозможно, так как содержимое буферов различно, и неизвестно, как оно образуется.

Перехваченные пакеты без ключа

Перехваченные пакеты с ключом

Затем возможны несколько вариантов дальнейших действий:

• изучать дебри драйвера защиты;
• воспользоваться информацией самих разработчиков системы.

Оба варианта дают необходимую информацию. Итак, оказывается, содержимое пакетов шифруется публичным симметричным алгоритмом AES (Advanced Encryption Standard). Логичной целью является получение ключа шифрования.

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

Пример дампа ключа

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

unsigned short Key;
unsigned char RefKey[8], VerKey[8];

for (Key = 0; Key if (!HL_LOGIN(Key, 1, RefKey, VerKey))
HL_LOGOUT();
Break;
>
>

Далее ключ (MODAD) используется для снятия дампа: тип, идентификатор, порт подключения и так далее. Для этого есть функции, определенные разработчиками.

Функции HL_LOGIN, HL_LOGOUT доступны из HASP SDK для разработчиков приложений, защищенных на этой платформе, и имеют следующие прототипы:

WORD HL_LOGIN(WORD ModAd, Word Access, Byte *RefKey, Byt *VerKey);
WORD HL_LOGOUT(void);

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

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

Обработчик

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

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

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

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 Seed -= (WORD)(Buffer + i) ^ i;
>

for (int i = 0xBE; i < 0xFF; i++) (WORD)(Buffer + i) -= Seed;
Seed = (Seed >> 15) | (Seed Seed += (WORD)(Buffer + i) ^ i;
>

Видно, что алгоритм гораздо сложнее, чем обычный сдвиг и исключающее «или». А вот алгоритм дешифрования:

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

Источник: xakep.ru

Ключи защиты программы 1С – виды и особенности

1С поддерживает работу как с программными, так и с аппаратными ключами. Разберемся подробнее с каждым из этих видов:

Программный ключ защиты 1С

Программная лицензия 1С — это файл, который хранится на ПК и участвует в запуске 1С. Если файл активирован пин-кодом, то запуск 1С будет осуществлен, в противном случае (если запуск осуществляется впервые) потребуется ввести ПИН, который находится в комплекте поставки. Программный ключ привязывается к аппаратной части компьютера, потому периодически, при замене комплектующих компьютера, приходится активировать лицензию 1С повторно.

Условно программную лицензию 1С можно поделить на 2 вида:

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

Многопользовательская лицензия чаще всего устанавливается на сервер (1С:Предприятие, сервер терминалов, WEB-сервер). При обращении 1С-клиента к 1С-серверу программное обеспечение само отслеживает количество свободных лицензий и позволяет (или не позволяет, если количество лицензий исчерпано) работать с 1С. При этом стоит отметить, что многопользовательская лицензия до 50 пользователей может быть активирована не только на сервере, как общая, её можно активировать на 50 разных клиентских компьютерах как 50 однопользовательских лицензий. Но если хотя бы одна лицензия из комплекта многопользовательской активирована как однопользовательская, то дальнейшее использование лицензий как “комплекта” уже невозможно.

Аппаратный ключ защиты 1С

Более надежным, но вместе с тем, и более дорогим способом защиты 1С являются аппаратные ключи. Аппаратные ключи защиты (HASP-ключ) выглядят как флешка и отмечают 1С, как прошедшую лицензирование. В данном случае, в отличие от программной лицензии, ПИН хранится на HASP, а не в файле на компьютере/сервере.

Существуют 4 вида аппаратных ключей, каждый имеет отличительный цвет и маркировку:

• Ключ для одного пользователя (локальный). Ключ имеет синий цвет и маркировку H4 M1 ORGL8. Данный ключ поставляется вместе с продуктами, у которых есть лицензия на один персональный компьютер.
• Сетевой ключ. Ключ красного цвета. HASP-ключ вставляется в один компьютер и виден всем компьютерам в сети. Маркируется как NETXX ORGL8. где ХХ — это количество лицензий. Есть разновидности на 5, 10, 20, 50, 100, 300, 500 лицензий.
• Серверный ключ для 32-битного сервера. Имеет фиолетовый цвет и маркировку ENSR8. Всегда поставляется вместе с лицензией на сервер.
• Серверный ключ для 64-битного сервера. Имеет зеленый цвет и маркировку EN8SA. Может работать также и с 32-разрядными серверами.

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

Менеджер лицензий 1С

В случае работы с многопользовательской лицензией необходимо, чтобы 1С знала о наличии такой лицензии в сети. За это отвечает Менеджер лицензий 1С (Hasp License Manager). Менеджер лицензий 1С является дополнительным программным обеспечением (входит в комплект поставки), без которого многопользовательская лицензия не будет корректно работать.

Ответы на часто задаваемые вопросы по ключам защиты 1С

№1. 1С не видит лицензии

В случае использования аппаратных ключей, если 1С не видит лицензий, в первую очередь необходимо удостовериться, что на HASP-ключе мигает индикатор. Это показатель того, что устройство определено и драйвер HASP-ключа установлен. Если лампочка не горит, попробуйте подключить ключ-флешку в другой порт USB, либо обратитесь к системному администратору, возможно у пользователя не хватает прав доступа для установки драйвера.

Также, в первую очередь убедитесь, что к компьютеру подключен ключ нужной серии. помните, что ключи могут блокировать друг-друга.

№2. Драйвер ключа защиты HASP устанавливается с ошибкой.

1. Возможно несовместимы операционная система и драйвер ключа. Попробуйте скачать более новую версию драйвера.
2. Файлы драйвера могут быть заблокированы из-за того, что заняты другим процессом. Попробуйте перезагрузить компьютер и сразу после загрузки установить драйвер. Либо примените консольную версию утилиты установки с параметрами командной строки: hinstall -i -kp

№3. Ошибка: HASP not Found (-3), (Error 7), (H0007)

HASP в сети работает по порту 475. Убедитесь, что на компьютере с ключом, на компьютере с запущенным приложением и в сети не блокируется порт 475. Он может быть заблокирован брандмауэром или антивирусом.

№4. HASP Device Driver not installed (-100)

Распространенная ошибка Windows XP. Драйвер защиты загружается медленнее, чем сервер защиты из автозагрузки. Вместо сервера защиты используйте Менеджер лицензий LMSETUP, который устанавливается, внимание, в качестве службы (Service) Windows!

В дополнение скажем, что при работе с 1С могут одновременно функционировать два и более менеджеров лицензий, но для предотвращения появления ошибок каждому менеджеру должно быть присвоено свое уникальное имя. Для этого используют файл nhsrv.ini, нужно изменить значение параметра NHS_SERVERNAMES в секции NHS_SERVER. Более того, необходимо сообщить эти имена каждой копии запущенной программы. Для этого используют nethasp.ini: в параметре NH_SERVER_ADDR указывают ip-адреса серверов, в параметре NH_SERVER_NAME указывают их имена в том же порядке, в котором были указаны адреса.

Если у вас еще есть вопросы по выбору, настройке, покупке программных или аппаратных ключей 1С на 10-50 пользователей, вы всегда можете обратиться за консультацией к нашим специалистам, а также заключить соглашение о техническом обслуживании 1С в дальнейшем.

Источник: integrus.ru