Есть ли отдельный от аппаратных ключей Guardant обфускатор DotNet, который не ломается автоматическими de4dot подобными инструментами? А то Eazfuscator как то слишком уж быстро ломают, не успеет выйти релиз и уже кряк. Автор утверждает, что это фейки, но как то верится с трудом, потому что пробные запуски кряков говорят об обратном. У меня есть лицензия Eazfuscator, я заинтересован в отсутствии его взлома, а не в появлении кряков обфускатора.

Похожий вопрос обсуждался тут — http://forum.guardant.ru/post/4099

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

Есть ли отдельный от аппаратных ключей Guardant обфускатор DotNet, который не ломается автоматическими de4dot подобными инструментами? А то Eazfuscator как то слишком уж быстро ломают, не успеет выйти релиз и уже кряк. Автор утверждает, что это фейки, но как то верится с трудом, потому что пробные запуски кряков говорят об обратном. У меня есть лицензия Eazfuscator, я заинтересован в отсутствии его взлома, а не в появлении кряков обфускатора.

Что означают разные строки? - Это разные редакции защиты (с разным набором функций)?
Что означают значения в столбцах ? Разная цена для разного количества активаций?
А приобретать активации нельзя без предоплаты сразу 50/100/200/500 и т.д. штук?
Поштучно, например?

GUARDANT SP                    50 — количество софтверных ключей. Это миннимальный пакет для заказа.         
Guardant SP (1 активация — каждый софтверный ключ из пакета можно активировать только на одном ПК)         
Guardant SP (3 активации — можно активировать на трех разных конфигурациях ПК)     
Guardant SP (5 активаций — можно активировать на пяти разных конфигурациях ПК)

Эти цены сформированны оптовой стоимостью включенных в комплект ключей?

Верно.

Да, можно.

Нет.

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

Вопрос со стойкостью последних версий Guardant для меня пока остается открытым.

Тогда затронем и ранее оставленные сообщения на эту тему.
По приведенным ссылкам видно, что речь идет о взломе конкретных программ, которые используют в качестве носителей лицензии электронные ключи старых моделей. Например, чаще всего из ключей Guardant упоминаются Stealth II, а эта модель была выпущена на рынок в 2004 году и, к слову, большинство сообщений с предложениями о построении эмулятора к этим ключам начинаются где-то с 2009 года, т.е. порядка 5 лет эти ключи позволяли разработчикам коммерческого ПО спокойно продавать лицензии к своим продуктам без рисков и больших затрат на его защиту. Что пошло не так тогда описано на нашем сайте, и что было сделано тоже:

https://www.guardant.ru/press-center/pu … 02-06.html
https://www.guardant.ru/press-center/pu … 04-15.html

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

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

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

Такого не наблюдается для протектора Guardant Armor — он был представлен лишь два года назад, но технология защиты кода, применяемая в нем, была разработана давно и применялась ранее исключительно для защиты наших собственных библиотек и утилит. Подробнее о нем можно прочитать на сайте: https://www.guardant.ru/products/all/guardant-armor/

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

Если немного отойти в сторону от автоматических утилит защиты, то, например, в этой статье хорошо описаны разные схемы проверки ключа лицензии с их достоинствами и недостатками. Не самый свежий материал но концептуально актуальный — http://alexander-bagel.blogspot.com/201 … -post.html . Т.е. если ответственно подойти к проектированию защиты, то и Stealth II отвязать от приложения будет трудоемкой задачей и без использования протекторов. Но нужно ли всем проектировать собственные схемы защиты при наличии современных решений вопрос открытый и по-своему актуальный для определенных задач, ведь даже протекторы не всегда есть возможность применять.

Еще немного стоит написать о современных моделях ключей Sign ( https://www.guardant.ru/products/all/guardant-sign/ ) и Code ( https://www.guardant.ru/products/all/guardant-code/ ), для которых устранены узкие места, которые упрощали процесс реверса защищенных приложений и усложняли процесс построения надежной защиты с устаревшими моделями. На самом деле отличий от старых моделей много (поддержка Linux, HID-режим и это не все), но сейчас отметить надо вот что:

1. Это технология аппаратных запретов на доступ к памяти ключа снаружи ( https://dev.guardant.ru/pages/viewpage. … Id=1279810 ) — запреты устанавливаются при программировании ключа разработчиком защищенного приложения. Это значит, что из области памяти, на которую установлены такие запреты, нельзя вытащить данные (неизвлекаемость). В таких защищенных областях памяти хранятся дескрипторы — секретные ключи аппаратных алгоритмов шифрования и подписи данных
2. Об этом я тоже упоминал ранее, а именно шифрование протокола обмена на сеансовых ключах (транспорт данных между ключом и защищенным приложением — https://dev.guardant.ru/pages/viewpage. … =1277982).
3. Отдельно стоит упомянуть появление в Sign/Code ключах ассиметричного алгоритма подписи данных ECC160 ( https://dev.guardant.ru/pages/viewpage. … Id=1278004 ) — с его помощью можно контролировать валидность данных, отдаваемых ключом и даже строить на этом своего рода аутентификацию ключа в защищенном приложении.

Как результат сообщений об успешной эмуляции современной линейки ключей, так и нет.

Ваши опасения абсолютно понятны. Однако самая лучшая защита ПО, которую может предложить компания Актив из всех свои направлений, включая и Рутокен и Guardant – это ключ Guardant Sign (а еще лучше Guardant Code) + Guardant Armor + консультации наших специалистов.

Если у вас остались какие-то сомнения, готов ответить на вопросы свзяанне с нашими технологиями защиты, но уже за рамками данного форума, поскольку здесь эта тема не профильная.

e-mail: hotline@guardant.ru
В теме письма укажите ссылку на эту ветку форума.

https://www.guardant.ru/purchase/store/#guardant_sp

GUARDANT SP                    50            100          200           500
Guardant SP (1 активация)    17000    32000    59000    124000   
Guardant SP (3 активации)    23000    43000    78000    149000   
Guardant SP (5 активаций)    29000    54000    98000    182000

Мне непонятна.

Что означают разные строки? - Это разные редакции защиты (с разным набором функций)?

Что означают значения в столбцах ? Разная цена для разного количества активаций?
А приобретать активации нельзя без предоплаты сразу 50/100/200/500 и т.д. штук?
Поштучно, например?

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

Пожалуйста, поясните расценки со страницы:
https://www.guardant.ru/purchase/sdk/kit/

Эти цены сформированны оптовой стоимостью включенных в комплект ключей?
Можно ли покупать ключи поштучно и использовать ваш защитный софт бесплатно?

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

Отломать Энигму от любой программы по словам хакеров стоит от 200-300 USD (за каждый релиз защищенной программы заново).
От - это, наверно, подразумевает, что в среднем $500 и более.
Т.е. защитить хотя бы несколько дней или недель своей работы Энигмой можно.

Вопрос со стойкостью последних версий Guardant для меня пока остается открытым.

http://forum.ru-board.com/topic.cgi?for … art=160#lt

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

Вот еще забавная ветка:
http://batona.net/114016-skolko-stoyat- … -foto.html

Ваши цены на защиту очень гуманны :)

sanyo пишет:

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

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

https://yandex.ru/yandsearch?text=guardant взлом

http://dongla-net.ru/guardant/instructguardant.htm
https://rus.dongla.net/
http://xaker.name/threads/20555/
http://cyber-worlds.org/forum/showthrea … 0501d8294f

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

Энигму последний раз ломали в паблик года 2 назад, но последнее время пока спокойно вроде бы. 

А как проверить какой вид защиты Guardian поломан в 2018 году? И чтобы не потратить на это исследование много времени.

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

Пока не приходилось работать с Guardant, только с Rutoken, поэтому и заинтересовался Guardant.

У меня поэтому и появилась мысль использовать Энигму в паре с Rutoken, потому что для нынешней Энигмы пока лома нет, для Рутокен ЭЦП2 тоже вроде бы нет. Зачем экспериментировать с Guardant, про который гуглится много о дампе и копировании эмуляции? Зачем Guardant, когда используя проверенные решения типа Rutoken+Enigma, спокойствия намного больше, что токен (неизвлекаемый закрытый ключ с него) не скопируют и что Энигму не сломают надолго, а если и сломают, то после усиления защиты будет опять период затишья на пару тройку лет.

Причем, появление лома Энигмы никак не повлияет на стойкость ключей внутри Рутокен ЭЦП2. Можно выпустить новую версию своего софта, завернутую новой Энигмой для старого ключа Рутокен и токен менять ненужно. Рутокен сертифицирован ФСБ и ФСТЭК, чем сертифицирован Guardant кроме сотен сообщений о взломе, дампинге и эмуляции?

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

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

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

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

Если не секрет, на чем базируется такой вывод? Уже приходилось работать с технологиями Guardant самостоятельно? Если да, то с какими проблемами и в каких версиях SDK столкнулись?

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

А ведь известно, что защита сильна настолько, насколько сильно ее самое слабое звено.

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

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

С моей точки зрения комплект отдельных инструментов типа Enigma Protector для защиты кода X86 и лицензирования, Eazfuscator для защиты кода DotNet и Infralution для только лицензирования будет защищать лучше, чем Guardant. 

Rutoken ECP2 был бы отличным дополнением к моему комплекту защиты для лучшей аутентификации пользователя ПО. Токены - это та область вашей специализации, где вы лучшие.

К сожалению, в области защиты ПО, судя по форумам, есть массовые взломы ваших защит.

Опишите, пожалуйста, почему не рассматриваете применение ключей Guardant так, как есть, т.е. просто выполнять защиту приложения с ключами, например, через наши утилиты автоматической защиты?

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

Общеизвестного и общедоступного быстрого и дешевого, универсального взлома современной версии Enigma Protector нет, тоже самое можно сказать про Rutoken ECP2.

Если взлом такой связки будет стоить хотябы >$1K, то он будет бессмысленным для обычных удаленных заказчиков кастом ПО - нехакеров, особенно в случае постоянных обновлений и регулярных оплат.

Взломать Enigma смогут только профи ради спортивного интереса и ломать придется каждый релиз моего ПО заново. Достать ключ из Rutoken ECP2, наверно, вообще нереально при затратах на это менее $10K?

Поэтому, наверно имеет смысл использовать некий open source API типа GPG, который можно было бы завернуть Энигмой в один исполняемый файл для затруднения подмены библиотек API доступа к вашему токену.

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

И да, ключи умеют шифровать, например, симметричным AES блоки данных от приложения, умеют подписывать их на однонаправленном ECC, но использовать эти возможности для построения некой своей системы PKI, выглядит не очень удобным занятием, для этого Рутокен ЭЦП подходят. Электронные ключи же выполняют функцию доверенного носителя лицензии, а аппаратное шифрование в них нужно чтобы строить стойкую защиту и надежные механизмы верификации ключа лицензии защищенным приложением.