Аппаратные ключи защиты | Компания "Аладдин Р.Д."

Содержание

Аппаратные ключи защиты | компания “аладдин р.д.”
Защита при помощи функций api
Изготовление эмулятора (программной копии) ключа
Лицензирование в локальных вычислительных сетях
Отделение модуля автоматической защиты
Правила использования usb-ключей в астрологических программах
Программно-аппаратная защита с использованием электронных ключей
Простой способ обнаружения эмуляторов ключа guardant
Рекомендации пользователям программ с usb-ключами защиты
Удаление вызовов функций api

Аппаратные ключи защиты | компания “аладдин р.д.”

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

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

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

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

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

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

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

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

HASP

Одним из наиболее распространенных в России защитных устройств такого типа является устройство 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

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

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

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

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

eToken

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

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

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

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

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

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

Secret Disk

В случае если объем конфиденциальной информации довольно значителен, можно воспользоваться устройством 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) и впускает его в систему по аппаратному ключу, то достаточно подобрать к этому устройству один пароль — и все секреты как на ладони…

Защита при помощи функций api

Этот метод защиты основан на использовании функций API, собранных в объектных модулях. Функции API позволяют выполнять с ключом любые операции (поиск ключа с заданными характеристиками, чтение и запись данных, подсчет контрольных сумм, преобразование информации и т. п.).

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

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

В общих чертах работу системы защиты можно представить таким образом:

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

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

Далее приведены основные методы взлома защиты и способы противодействия взлому.

Изготовление эмулятора (программной копии) ключа

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

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

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

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

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

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

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

Лицензирование в локальных вычислительных сетях

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

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

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

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

Отделение модуля автоматической защиты

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

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

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

Правила использования usb-ключей
в астрологических программах

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

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

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

Аппаратные ключи защиты очень надёжны в работе при бережном к ним отношении и имеют неограниченный срок службы.

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

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

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

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

Программно-аппаратная защита с использованием электронных ключей

На сегодняшний день это — наиболее надежный и удобный метод защиты тиражируемого ПО средней и высшей ценовой категории. Он обладает высокой стойкостью к взлому и не ограничивает использование легальной копии программы. Применение этого метода экономически оправдано для программ стоимостью свыше $80, так как использование даже самых дешевых электронных ключей увеличивает стоимость ПО на $10-15.

Электронными ключами, в основном, защищают так называемый «деловой» софт: бухгалтерские и складские программы, правовые и корпоративные системы, строительные сметы, САПР, электронные справочники, аналитический софт, экологические и медицинские программы и т. п.

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

Простой способ обнаружения эмуляторов ключа guardant

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

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

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

Порядок действий будет примерно таким:

Через SetupDiGetClassDevsA() получим список всех присутствующих устройств.
Проверим, имеет ли устройство отношение к ключам Guardant через проверку GUID устройства. (У Guardant данный параметр равен {C29CC2E3-BC48-4B74-9043-2C6413FFA784})
Получим символьную ссылку на каждое устройство вызовом SetupDiGetDeviceRegistryPropertyA() с параметром SPDRP_PHYSICAL_DEVICE_OBJECT_NAME.
Откроем устройство при помощи ZwOpenFile() (CreateFile() тут уже к сожалению не подойдет, т.к. будут затруднения при работе с символьными ссылками).

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

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

Для начала константы IOCTL выглядят так:

  GetDongleQueryRecordIOCTL = $E1B20008;
  GetDongleQueryRecordExIOCTL = $E1B20018;

Первая для ключей от Guardant Stealth I/II

Вторая для Guardant Stealth III и выше (Sign/Time/Flash/Code)

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

  TDongleQueryRecord = packed record
    dwPublicCode: DWord; // Public code
    byHrwVersion: Byte; // Аппаратная версия ключа
    byMaxNetRes: Byte; // Максимальный сетевой ресурс
    wType: WORD; // Флаги типа ключа
    dwID: DWord; // ID ключа
    byNProg: Byte; // Номер программы
    byVer: Byte; // Версия
    wSN: WORD; // Серийный номер
    wMask: WORD; // Битовая маска
    wGP: WORD; // Счетчик запусков GP/Счетчик времени
    wRealNetRes: WORD; // Текущий сетевой ресурс, д.б. <= byMaxNetRes
    dwIndex: DWord; // Индекс для удаленного программирования
  end;

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

  TDongleQueryRecordEx = packed record
    Unknown0: array [0..341] of Byte;
    wMask: WORD;    // Битовая маска
    wSN: WORD;      // Серийный номер
    byVer: Byte;    // Версия
    byNProg: Byte;  // Номер программы
    dwID: DWORD;    // ID ключа
    wType: WORD;    // Флаги типа ключа
    Unknown1: array [354..355] of Byte;
    dwPublicCode: DWORD;
    Unknown2: array [360..375] of Byte;
    dwHrwVersion: DWORD; // тип микроконтролера
    dwProgNumber: DWORD; // Номер программы
    Unknown3: array [384..511] of Byte;
  end;

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

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

procedure TEnumDonglesEx.Update;
var
  dwRequired: DWord;
  hAllDevices: H_DEV;
  dwInfo: DWORD;
  Data: SP_DEVINFO_DATA;
  Buff: array [0 .. 99] of AnsiChar;
  hDeviceHandle: THandle;
  US: UNICODE_STRING;
  OA: OBJECT_ATTRIBUTES;
  IO: IO_STATUS_BLOCK;
  NTSTAT, dwReturn: DWORD;
  DongleQueryRecord: TDongleQueryRecord;
  DongleQueryRecordEx: TDongleQueryRecordEx;
begin
  SetLength(FDongles, 0);
  DWord(hAllDevices) := INVALID_HANDLE_VALUE;
  try
    if not InitSetupAPI then
      Exit;
    UpdateUSBDevices;
 
    hAllDevices := SetupDiGetClassDevsA(nil, nil, 0,
      DIGCF_PRESENT or DIGCF_ALLCLASSES);
    if DWord(hAllDevices) <> INVALID_HANDLE_VALUE then
    begin
      FillChar(Data, Sizeof(SP_DEVINFO_DATA), 0);
      Data.cbSize := Sizeof(SP_DEVINFO_DATA);
      dwInfo := 0;
      while SetupDiEnumDeviceInfo(hAllDevices, dwInfo, Data) do
      begin
        dwRequired := 0;
        FillChar(Buff[0], 100, #0);
        if SetupDiGetDeviceRegistryPropertyA(hAllDevices, @Data,
          SPDRP_PHYSICAL_DEVICE_OBJECT_NAME, nil, @Buff[0], 100, @dwRequired)
          then
          if CompareGuid(Data.ClassGuid, GrdGUID) then
          begin
            RtlInitUnicodeString(@US, StringToOleStr(string(Buff)));
            FillChar(OA, Sizeof(OBJECT_ATTRIBUTES), #0);
            OA.Length := Sizeof(OBJECT_ATTRIBUTES);
            OA.ObjectName := @US;
            OA.Attributes := OBJ_CASE_INSENSITIVE;
            NTSTAT := ZwOpenFile(@hDeviceHandle,
              FILE_READ_DATA or SYNCHRONIZE, @OA, @IO,
              FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE,
              FILE_SYNCHRONOUS_IO_NONALERT);
            if NTSTAT = STATUS_SUCCESS then
            try
 
              if DeviceIoControl(hDeviceHandle, GetDongleQueryRecordIOCTL,
                nil, 0, @DongleQueryRecord, SizeOf(TDongleQueryRecord),
                dwReturn, nil) and (DongleQueryRecord.dwID <> 0) then
              begin
                SetLength(FDongles, Count   1);
                FDongles[Count - 1].Data := DongleQueryRecord;
                FDongles[Count - 1].PnPParentPath :=
                  GetPnP_ParentPath(Data.DevInst);
                Inc(dwInfo);
                Continue;
              end;
 
              Move(FlashBuffer[0], DongleQueryRecordEx.Unknown0[0], 512);
 
              if DeviceIoControl(hDeviceHandle, GetDongleQueryRecordExIOCTL,
                @DongleQueryRecordEx.Unknown0[0],
                SizeOf(TDongleQueryRecordEx),
                @DongleQueryRecordEx.Unknown0[0],
                SizeOf(TDongleQueryRecordEx),
                dwReturn, nil) then
              begin
 
                DongleQueryRecordEx.wMask :=
                  htons(DongleQueryRecordEx.wMask);
                DongleQueryRecordEx.wSN :=
                  htons(DongleQueryRecordEx.wSN);
                DongleQueryRecordEx.dwID :=
                  htonl(DongleQueryRecordEx.dwID);
                DongleQueryRecordEx.dwPublicCode :=
                  htonl(DongleQueryRecordEx.dwPublicCode);
                DongleQueryRecordEx.wType :=
                  htons(DongleQueryRecordEx.wType);
 
                SetLength(FDongles, Count   1);
                ZeroMemory(@DongleQueryRecord, SizeOf(DongleQueryRecord));
                DongleQueryRecord.dwPublicCode :=
                  DongleQueryRecordEx.dwPublicCode;
                DongleQueryRecord.dwID := DongleQueryRecordEx.dwID;
                DongleQueryRecord.byNProg := DongleQueryRecordEx.byNProg;
                DongleQueryRecord.byVer := DongleQueryRecordEx.byVer;
                DongleQueryRecord.wSN := DongleQueryRecordEx.wSN;
                DongleQueryRecord.wMask := DongleQueryRecordEx.wMask;
                DongleQueryRecord.wType := DongleQueryRecordEx.wType;
                FDongles[Count - 1].Data := DongleQueryRecord;
                FDongles[Count - 1].PnPParentPath :=
                  GetPnP_ParentPath(Data.DevInst);
              end;
            finally
              ZwClose(hDeviceHandle);
            end;
          end;
        Inc(dwInfo);
      end;
    end;
  finally
    if DWord(hAllDevices) <> INVALID_HANDLE_VALUE then
      SetupDiDestroyDeviceInfoList(hAllDevices);
  end;
end;

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

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

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

  function GetPnP_ParentPath(Value: DWORD): string;
  var
    hParent: DWORD;
    Buffer: array [0..1023] of AnsiChar;
    Len: ULONG;
    S: string;
  begin
    Result := '';
    if CM_Get_Parent(hParent, Value, 0) = 0 then
    begin
      Len := Length(Buffer);
      CM_Get_DevNode_Registry_PropertyA(hParent, 15, nil,
        @Buffer[0], @Len, 0);
      S := string(PAnsiChar(@Buffer[0]));
      while CM_Get_Parent(hParent, hParent, 0) = 0 do
      begin
        Len := Length(Buffer);
        CM_Get_DevNode_Registry_PropertyA(hParent, 15, nil,
          @Buffer[0], @Len, 0);
        S := string(PAnsiChar(@Buffer[0]));
        Result := S   '#'   Result;
      end;
    end;
    if Result = '' then
      Result := 'не определен';
  end;

Собственно (вы будете смеяться) детектирование эмулятора будет происходить именно на базе данной строки.

Обычно путь устройства выглядит следующим образом:

Device0000004#Device0000004#Device0000044#Device0000049#DeviceNTPNP_PCI0005#DeviceUSBPDO-3#

В нем как минимум будет присутствовать текст NTPNP_PCI или USBPDO.

Т.е. PCI шина или HCD хаб как минимум будут одним из предков.

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

Device0000040#Device0000040

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

  function IsDonglePresent(const Value: string): Boolean;
  begin
    Result := Pos('NTPNP_PCI', Value) > 0;
    if not Result then
      Result := Pos('USBPDO', Value) > 0;
  end;

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

Небольшой нюанс:

Описанный в статье метод даст ложно/позитивное срабатывание при использовании пользователем вашего продукта платформы Anywhere:

http://www.digi.com/products/usb/anywhereusb#overview

Забрать пример можно здесь.

Удаление вызовов функций api

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

Существует несколько эффективных приемов противодействия попыткам удаления или обхода вызовов функций API:

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

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