Виртуальные ключи и статистика использования ПО клиентами

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

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

Чтобы решить эти проблемы и был разработан сервис Virkey. Кроме предоставления средств защиты с помощью виртуального ключа и контроля запуска ПО, он так же позволяет:

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

Если Вам интересно, более детально можно почитать на нашем сайте virkey.com/analytics.htm?sl=RU

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

Пока мы не предлагаем на сервисе ПО которое навешивается на Вашу разработку шифрует его или добавляет автоматическую защиту. Такую защиту снимают хакеры достаточно быстро (из своего опыта). Мы предлагаем инструменты для лицензирования, защиты, мониторинга, которые будут включены в ПО разработчиком.

Возможно, я неверно понимаю суть.
Я так понимаю, что моё ПО общается с вашим сервисом и получает оттуда ответ, лицензировано ли оно. Если так, то кто-то (я так понял что ваш сервис) должен генерировать лицензионные ключи, — которые при активации будут проверены на валидность на вашем сервисе. Если так, то часть ПО, работающая с ключами, должна быть подвергнута шифрованию, полиморфизму и прочим интересным процедурам — иначе активацию тоже просто легко отломают. Логично, если сервис активации предоставляет некий готовый SDK для реализации описанного процесса в защищаемом ПО. Вот тут и вопрос: насколько хорошо реализован данный механизм на стороне ПО, и как решена проблема с сумасшедшими антивирусами.

Простое шифрование части кода, как правило, не является 100% гарантией защиты, если ПО достаточно ценное, нужен комплекс мер по его защите (внутри ПО). Готового SDK на сервисе пока нет, но он предполагается в дальнейшем и будет содержать примеры функций для работы с сервисом, которые разработчик сможет включить в свое ПО. В данном случае разработчик использует стандартные компоненты для отправки и получения пакетов по https протоколу используя стандартные библиотеки для электронной подписи и проверки электронной подписи. Которые воспринимаются антивирусами «адекватно». Расшифровка пакетов информации между сервисом и приложением ничего не даст, если используется две пары ключей. Узкое место, это защита ПО от внесения в него изменений, а для этого лучше использовать комплекс мер собственных и/или внешних. В случае аппаратных ключей, Вы защитили ПО но не можете полностью защититься от его эмуляции.

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

Вопрос: вы вот эту часть оставляете на усмотрение автора софта? Или у вас есть/планируется какой-то SDK, который бы защищал эту часть софта?

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

Мы можем рекомендовать методы защиты софта, но выбор за разработчиком. SDK планируется, но он будет включать в первую очередь примеры использования и рекомендации по защите ПО. У нас есть свои разработки по проверки целостности ПО, прочие проверки и шифрование, но нужно ли их включать в SDK — посмотрим. На счёт ценности, если Вам не нужен контроль за использованием ПО, автоматическое лицензирование, проверка использования лицензий, и т.п., тогда делайте это вручную или с помощью аппаратных ключей + сервис по мониторингу, и т.п. SDK аппаратных ключей и их аналоги в сети не дают возможность защититься полностью одним нажатием кнопки, потому как их ломают, а платите Вы за каждую проданную копию ПО. Оправданы ли эти затраты?

В мире «шаровары» все это существует уже сто лет как. Для пущей объективности, не помешало бы сообщить чем вы лучше/хуже конкурентов, коие давно на рынке и прошли свои детские болезни. О вас же я слышу впервые.

Ниже в комментариях мы писали об отличиях, а именно: мониторинг виртуальных (лицензирование) и аппаратных ключей; возможность не привязываться к железу (от этого теряет разработчик и не удобно пользователю); не нужно платить за каждую лицензию (как в аналогах, у некоторых есть минимальные заказы от 50 штук); бесплатное использование сервисом для нового ПО (к примеру, для 1-го ПО, до 3 лицензий в месяц) ... У разработчиков аппаратных ключей не детские болезни, но почему-то их эмулируют очень быстро!

У разработчиков аппаратных ключей не детские болезни, но почему-то их эмулируют очень быстро!

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

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

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

Впрочем, удачи в бизнесе. С таким подходом, вам только удача и поможет.

Несколько очевидных вопросов, которые стоило бы отразить на лендинге сразу:
1. Как работать в офлайне.
2. Защита от дизассемблирования и смены направления одного jmp в бинарнике.
3. Защита самого облака.
4. Дифференцировать от «монстров» онлайн анализа типа Flurry.

1. Как работать в офлайне.
Предусматривается два возможных режима для офлайне работы пользователя: 1) пользователь один раз подключается к интернету для получения кода подтверждения от сервиса (может быть на всегда или до следующего обновления ПО); 2) пользователь высылает код (к примеру оборудования) Вам — Вы регистрируете этот код вручную, получаете код подтверждения, передаёте пользователю. Проверка достоверности выполняется с помощью RSA сертификатов.
2. Защита от дизассемблирования и смены направления одного jmp в бинарнике.
4. Дифференцировать от «монстров» онлайн анализа типа Flurry
Софт нужно защищать в любом случае, только диалог между программой и сервисом не подделают т.к. используются две пары сертификатов для подписи данных и SSL шифрование https протокола.
У каждого пользователя будут свои сертификаты, уникальный идентификатор пользователя и программы.
3. Защита самого облака.
Сервер будет развёрнут на амазоне

Хорошо.
А лучше опишите это более «гладко» и включите в лендинг.

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

Спасибо, за комментарии и полезные советы! Частично, такой метод у нас реализован, но не при лицензировании, а проверке контрольной суммы указанного разработчиком фрагмента программы (не входит в функционал сервиса, по крайней мере пока).

Спасибо, Ник, информация интересная. Но не собираетесь ли Вы продублировать функционал, разрабатываемый компанией «Аладдин Р.Д.»?

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

Aladdin HASP SRM, поддерживает использование как программных, так и аппаратных ключей для лицензирования ПО и обеспечения его безопасности. Я работала немного с защитой ПО на базе аппаратного ключа HASP HL лет 5 тому назад, но так же слышала и о программных решениях HASP SL. Вот и решила у Вас узнать в чем достоинство Вашего решения перед существующими аналогами, если таковые имеются по Вашему мнению. Если есть у Вас желание/время, расталкуйте пожалуйста мне любым доступным Вам способом, буду очень благодарна.

Лично я работал и продолжаю ещё иметь дело с ключами HASP, HARDLOCK, GUARDANT и немного UniKey. HASP SL и другие аналоги заточен под слепок компьютера, у нас тоже реализован такой метод на нескольких ПО, но Вы как продавец должны предусматривать заведомо большее количество лицензий для покупателя т.к. он может менять железо, комп. и слепок уже не совпадёт. Соответственно вы как разработчик теряете прибыль если пользователь «хитрит» и работает на 2-3 компьютерах. Кроме того Вы платите в аналогах всё равно за рабочее место, хоть и меньше. Сервис допускает использование такого метода, но рекомендует использовать он-лайн или комбинированную проверку лицензирования (зависит от разработчика). Жёсткой привязки к железу нет, используется только для аналитики (пользователь получает код). Дополнительно можно мониторить аппаратные ключи разных производителей и виртуальные в одном месте.

Мы разрабатываем данный сервис и нам важно знать насколько он интересует разработчиков, стоит ли ним заниматься вообще, есть ли актуальность. Это не совсем реклама — мы изучаем спрос. У Вас есть вопросы по данной тематике? Если не хотите читать сайт, я здесь отвечу на все вопросы. :-)

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

Если сервис позволит разработчикам не попадать на «крючок» к продавцам аппаратных ключей защиты, которые делают он-лайн аналоги с аппаратным подходом (к примеру Guardant SP минимальная партия от 50 шт), я думаю он может принести пользу для остальных. Анализ нужно проводить в любом случае, согласен.

Підписатись на коментарі