Защита программы

← →
Семен Сорокин © (2006-11-21 14:49) [0]

Приветствую уважаемые.

Есть комплекс программ (6 штук), работающей с MS SQL 2000, который устанавливается на предприятие (до 200 рабочих мест). На данный момент возникла необходимость сделать защиту от копирования программы и сервера. Хотелось бы иметь следующую реализацию: программа работает до определенной даты, и если не было обновления версии то перестает работать, в то же время в случае обновления "конечная дата" корректируется. И без возможности скопировать серверную и клиентскую часть в другую сеть.
Первое что пришло на ум - это использовать Hasp ключи, но здесь необходимо обойтись без установки на каждое рабочее место (потому что их очень много и они часто меняются) чего либо кроме ссылки на программу.
Возможен сетевой вариант Hasp ключа, но тогда необходимо еще удаленно его перепрограммировать при обновлении версии.
Встраивать в EXE-шник банальную проверку на дату не хочется, потому как обходится на раз-два.
Были мысли по поводу написания Extended Stored Proc на сервере с использованием API Hasp ключа и каким либо способом прикрутить к программе. Или использовать дополнительной таблицы на сервере с шифрованными данными. Но опять же правкой EXE-шника это исправится.
Хотелось бы услышать Ваши мнения по этому вопросу с учетом всей приведенной специфики.

ЗЫ. От посылок в поиск просьба воздержаться, ибо там был и вопрос проштудирован, интересует Ваше мнение и реализация.
ЗЫЫ. Необходимость взлома программы тоже просьба не обсуждать.

С Уважением.

← →
tesseract © (2006-11-21 14:51) [1]

> Возможен сетевой вариант Hasp ключа, но тогда необходимо
> еще удаленно его перепрограммировать при обновлении версии.
>

http://www.guardant.ru - лично 2 года с ними работал. Всё что тебе нужно поддерживает.
Удалённое программирование ключей может выполнить даже начальник зооцеха.

← →
Александр Иванов © (2006-11-21 14:52) [2]

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

← →
Anatoly Podgoretsky © (2006-11-21 14:53) [3]

> Семен Сорокин (21.11.2006 14:49:00) [0]

Hasp, да и все остальное не помогает против копирования. Особенно сервера.

← →
wal © (2006-11-21 14:54) [4]

> Возможен сетевой вариант Hasp ключа, но тогда необходимо
> еще удаленно его перепрограммировать при обновлении версии.
А как версия обновляется? Вполне можно вместо "удаленно" и локально перепрограммировать.

← →
Rouse_ © (2006-11-21 14:55) [5]

Берешь гвардантовские АПИ по ссылке tesseract - а, берешь EXECryptor www.strongbit.com все это дело навешивай на программу. Если грамотно навесишь - упаряться снимать.

← →
KilkennyCat © (2006-11-21 14:59) [6]

Я бы порекомендовал хасп-ключи от алладина. Я пользовался многими. Их надежность выше (не только в крипто, но и просто в отказах).
Но стоимость их выше.
http://www.alladin.ru/catalog/hasp/

← →
Rouse_ © (2006-11-21 15:08) [7]

Надежность у Хаспа ниже чем у Гварданта, начать с того что у Гварданта хардварная защита от чтения памяти ключа, а не софтверная :)

← →
Семен Сорокин © (2006-11-21 15:09) [8]

tesseract ©
> http://www.guardant.ru - лично 2 года с ними работал. Всё
> что тебе нужно поддерживает.
> Удалённое программирование ключей может выполнить даже начальник
> зооцеха.

возьму на заметку

> Александр Иванов ©

опять же снимается заменой условного перехода на безусловный :) если не мудрить с алгоритмами.

> Anatoly Podgoretsky ©

уловил иронию, хасп эмуляторы во внимание не принимаются.

> KilkennyCat ©

именно его сейчас и прикупили, но в ограниченном количестве (HASP HL).

← →
KilkennyCat © (2006-11-21 15:13) [9]

> [7] Rouse_ © (21.11.06 15:08)

Крипто - зависит от модели.
А вот алладиновских сгоревших ключей у меня всего один. В отличие от прочих.

← →
Семен Сорокин © (2006-11-21 15:14) [10]

> wal © (21.11.06 14:54) [4]
> А как версия обновляется? Вполне можно вместо "удаленно"
> и локально перепрограммировать.

пока еще неизвестно, но возможно будет настроен канал VPN.

← →
Anatoly Podgoretsky © (2006-11-21 15:21) [11]

> Семен Сорокин (21.11.2006 15:09:08) [8]

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

← →
Сергей М. © (2006-11-21 15:23) [12]

> Семен Сорокин © (21.11.06 14:49)

> .. защиту от копирования программы ..
> .. программа работает ..

Раз она работает (на другом компьютере, надо понимать ?), значит она УЖЕ скопирована.
Ну и о какой защите от копирования при этом идет речь ?

← →
Rouse_ © (2006-11-21 15:25) [13]

> А вот алладиновских сгоревших ключей у меня всего один.
> В отличие от прочих.

Ну Гварданта за последние три года ключей 15 мы меняли. Это с учетом что у нас в районе 60 тысяч конечных пользователей (читай организаций) у каждой из которых от одного до 25 ключей....

← →
Семен Сорокин © (2006-11-21 15:38) [14]

> Anatoly Podgoretsky © (21.11.06 15:21) [11]
> Почему не принимаются, особенно если у тебя Алладин со старыми
> функциями, которые по сути относятся к определению, вставлена
> заглушка или нет.

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

> Сергей М. © (21.11.06 15:23) [12]
> Раз она работает (на другом компьютере, надо понимать ?),
> значит она УЖЕ скопирована.
> Ну и о какой защите от копирования при этом идет речь ?

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

← →
Anatoly Podgoretsky © (2006-11-21 15:48) [15]

> Сергей М. (21.11.2006 15:23:12) [12]

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

Но мне, для дисскуссии, интересен вопрос, а что собираемся защищать в сервере и как?

← →
Anatoly Podgoretsky © (2006-11-21 15:50) [16]

> Rouse_ (21.11.2006 15:25:13) [13]

Ого, это 1 500 000 ключей, так что 15 ключей это великолепная надежность 1/100000 - это же японское качество, отказ не в процентах а в штуках, всего 10 промилей.

← →
Anatoly Podgoretsky © (2006-11-21 15:51) [17]

> Семен Сорокин (21.11.2006 15:38:14) [14]

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

← →
Anatoly Podgoretsky © (2006-11-21 15:51) [18]

> Rouse_ (21.11.2006 15:25:13) [13]

Кстати я почитал про Гварданта - очень красиво они себя хвалят.

← →
Сергей М. © (2006-11-21 15:58) [19]

> Anatoly Podgoretsky © (21.11.06 15:48) [15]

> говорить надо об защите от несанкционированного использования

Это ты автору втолкуй)

Он, видимо, не понимает разницы, судя по вопросу.

> Семен Сорокин

Alladin HASP HL на сей день - не самое плохое решение по сабжу.

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

См. HL_API-ф-цию HL_ENCRYPT (код $0E, не документирована).

← →
Anatoly Podgoretsky © (2006-11-21 16:08) [20]

> Сергей М. (21.11.2006 15:58:19) [19]

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

← →
Семен Сорокин © (2006-11-21 16:10) [21]

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

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

← →
Сергей М. © (2006-11-21 16:11) [22]

> Anatoly Podgoretsky © (21.11.06 16:08) [20]

Пока никак.

← →
Сергей М. © (2006-11-21 16:12) [23]

> Семен Сорокин © (21.11.06 16:10) [21]

> Интересует именно невозможность взять копию БД и имеющийся
> бинарник

Эта "невозможность" не возможна.

← →
Семен Сорокин © (2006-11-21 16:13) [24]

> Сергей М. © (21.11.06 16:12) [23]
> Эта "невозможность" не возможна.

хорошо, "максимально усложнить"...

← →
Сергей М. © (2006-11-21 16:15) [25]

> Семен Сорокин © (21.11.06 16:13) [24]
>
>

> хорошо, "максимально усложнить"

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

← →
Семен Сорокин © (2006-11-21 16:19) [26]

> Сергей М. © (21.11.06 16:15) [25]
> > хорошо, "максимально усложнить"
> Нанять за достойную з/плату высококлассного профессионала-
> сисадмина - он примет все необходимые меры для предотвращения
> "утечки инф-ции"

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

а серьезно, ПО то будет ставиться из тысячи км...

← →
Сергей М. © (2006-11-21 16:24) [27]

> Семен Сорокин © (21.11.06 16:19) [26]

100%-но обезопасить свое ПО (код и данные) от копирования невозможно. Забудь.

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

← →
Семен Сорокин © (2006-11-21 16:34) [28]

> Сергей М. © (21.11.06 16:24) [27]
> 100%-но обезопасить свое ПО (код и данные) от копирования
> невозможно. Забудь.
>
> Задумайся над обеспечением максимально возможного затруднения
> использования копий, если они несанкционированные.

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

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

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

← →
Сергей М. © (2006-11-21 16:43) [29]

> Семен Сорокин © (21.11.06 16:34) [28]

> в этом случае ему придется сделать копию хаспа для работы
> или найти/написать эмулятор - уже сложности

Вот на это и сделай акцент.

Пусть он себе копирует "базу+бинарник" сколько ему вздумается - без апп.ключа или эмулятора грош цена этой копии.

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

> Семен Сорокин (21.11.2006 16:10:21) [21]

> Интересует именно невозможность взять копию БД и имеющийся бинарник

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

Так что и как собираемся защищать в базе?

> Сергей М. (21.11.2006 16:11:22) [22]

А как с этим дела обстаят у квадранта?
Описание на сайте чисто популисткое.

> Семен Сорокин (21.11.2006 16:13:24) [24]

Что именно собираешься усложнять у базы, не забудь, что администратор базы имеет полные права на все. Поставляй аппаратный комплекст и никому не выдавать прав на сервер. Закрытый, черный (железный ящик) наружу торчит только один порт.

> Anatoly Podgoretsky © (21.11.06 16:45) [31]

> как с этим дела обстаят у квадранта?

Понятия не имею.
Попросту не интересовался, ибо по уши хватает "хлопот" с алладином)

> Семен Сорокин (21.11.2006 16:19:26) [26]

Тогда на что ты расчитываешь?

> Сергей М. (21.11.2006 16:24:27) [27]

Что предложишь по базе, не извращенского?

> Anatoly Podgoretsky © (21.11.06 16:47) [34]

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

> Сергей М. ©

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

> Сергей М. (21.11.2006 16:49:36) [36]

> По поводу ее защиты от несанкц.использования ?

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

> Семен Сорокин (21.11.2006 16:54:37) [37]

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

> Ого, это 1 500 000 ключей

Не полтора миллиона, обычно берут 1-2 ключа, это около 80 процентов пользователей... остальные 5, 10, 15 и т.п. так что общее кол-во ключей меньше чем 1500000 :) А хвалят они себя за дело :) Алладины тоже хвалят себя, однако эмулей по всему инету на их продукты тонны, выбирай на вкус, а у Гварданта только первый стелс взломан. Второй и третий даже на затронут. А то что пишут что якобы второй поломан - это все сказки, алгоритм GSII64 применяемый начиная с двойки не по зубам народу :)

> Rouse_ © (21.11.06 17:31) [41]

> Алладины тоже хвалят себя, однако эмулей по всему инету
> на их продукты тонны

Работу HASP HL (Е-У-Е) без знания AES-128-ключа и IV эмулировать практически невозможно. Это обосновано устойчивостью криптоалгоритма, применяемого в ключе для реализации ф-ции HL_ENCRYPT (не путать ф-цией K_EYE, более известной как HL_CODE, той самой которую с успехом эмулируют все кому не лень)
На сей день для HASP HL нет ни единого универсального эмулятора.

Защита программы Найти похожие ветки