Защита программ: генерирование серийных ном., активационных etc

← →
Maacheba (2009-02-13 15:30) [0]

На начальном этапе для защиты программы принята такая технология:

1) клиенту выдается серийный номер
2) при установке программы по серийному номеру и железу генерируется код запроса.
3) клиент вбивает на сайте код запроса и получает активационный код

И возникает куча вопросов - как лучше это реализовать, по каким критериям генерировать серийный код? Желательно ли в код запроса каким-то образом включать информацию, по которой можно понять о каком серийном ключе идет речь (по базе)?

Можно ли обойтись в кодах исключительно цифрами для более простой передачи информации в разговорном виде?

По каким параметрам лучше привязываться к железу, есть у кого опыт?

Как генерировать код запроса и активационный код?

Какие грабли встречаются, чего лучше не делать?

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

← →
Кто б сомневался © (2009-02-13 15:37) [1]

У меня также похожий вопрос. Возможно кто то знает, есть ли возможность вводить этот код на сайтах ресселлеров? Например на plimus. Если кто то стакливался, расскажите - просто да или нет.

← →
Медвежонок Пятачок © (2009-02-13 15:46) [2]

Какие грабли встречаются, чего лучше не делать?

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

Хитроумную проверку ломать никто не будет, сломают иф/зен/елс

← →
Jeer © (2009-02-13 15:55) [3]

> Maacheba (13.02.09 15:30)

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

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

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

← →
Jeer © (2009-02-13 15:56) [4]

> а от защиты запуска на несанкционированном ( не активированном
> ) рабочем месте.

для защиты от запуска на...

← →
KSergey © (2009-02-13 16:04) [5]

> Медвежонок Пятачок © (13.02.09 15:46) [2]
> Хитроумную проверку ломать никто не будет, сломают иф/зен/елс

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

← →
Сергей М. © (2009-02-13 16:14) [6]

> чего лучше не делать?

Не страдать откровенной фигней.

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

← →
Eraser © (2009-02-13 16:17) [7]

> [1] Кто б сомневался © (13.02.09 15:37)
> У меня также похожий вопрос. Возможно кто то знает, есть
> ли возможность вводить этот код на сайтах ресселлеров? Например
> на plimus.

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

← →
Сергей М. © (2009-02-13 16:18) [8]

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

← →
Медвежонок Пятачок © (2009-02-13 16:26) [9]

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

необязательно.
число_хакеров_в_мире << число_пользователей_нелегальных_копий_ПО

← →
Rouse_ © (2009-02-13 16:31) [10]

> следует защищать его современными аппаратными ключами

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

← →
Anatoly Podgoretsky © (2009-02-13 16:49) [11]

> Сергей М. (13.02.2009 16:18:08) [8]

При этом биометрию пусть рисует мышкой в реале

← →
Сергей М. © (2009-02-13 16:49) [12]

> Rouse_ © (13.02.09 16:31) [10]

Вне сомнений)

← →
Сергей М. © (2009-02-13 16:54) [13]

> Anatoly Podgoretsky © (13.02.09 16:49) [11]

А что ?

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

← →
Maacheba (2009-02-13 16:54) [14]

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

а не знаешь способа считать этот серийный номер стопроцентно? Желательно, не имея прав администратора.
Чтобы работало со всеми винчестерами, в том числе IDE, SCSI, SATA, RAID-массивы и прочее...
Я до этого думал о ID процессора...

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

а вот тут и как раз один из важнейших моментов. Как кодировать?
Включать ли в закодированные данные информацию о серийном ключе?

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

Вопрос в том как шифровать? Например, одна из идей - несимметричное шифрование. Кодировать информацию будет сервер неизвестным кроме нас самих ключом. А клиент будет расшифровывать и получать данные.

Проблемы:

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

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

а в чем разница?
Защита ПО - это разве не предотвращение несанкционированного запуска?!

← →
Anatoly Podgoretsky © (2009-02-13 16:59) [15]

> Maacheba (13.02.2009 16:54:14) [14]

Для расшифровки нужен полный (private) ключ.

← →
Maacheba (2009-02-13 17:03) [16]

> если купить ПО+ключи для защиты жаба давит

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

← →
Jeer © (2009-02-13 17:06) [17]

> а не знаешь способа считать этот серийный номер стопроцентно?
> Желательно, не имея прав администратора.
> Чтобы работало со всеми винчестерами, в том числе IDE, SCSI,
> SATA, RAID-массивы и прочее...
> Я до этого думал о ID процессора...

Алекс Коншин - hddsn.pas
Что есть - то есть, разбирайся сам, чего он не может.

HDD - это понятно и справедливо. Если переустановлена система на новом винте, то и не грех заново запросить активацию.

> а вот тут и как раз один из важнейших моментов. Как кодировать?
>
> Включать ли в закодированные данные информацию о серийном
> ключе?

Зачем серийник еще какой-то ? Вести еще базу серийников ?

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

> а в чем разница?
> Защита ПО - это разве не предотвращение несанкционированного
> запуска?!

Нет.
Для корпоративки вполне сойдет.
А как защита продаваемого ПО - фигня и геморрой.

← →
Ega23 © (2009-02-13 17:08) [18]

> Нужно уметь изменять условия лицензии без перевысылке ключей.

Ну вот накрылся у пользователя винт. Вот он его поменял. Вот он переустановил программу. И что дальше? А дальше она банально не работает.

← →
Jeer © (2009-02-13 17:10) [19]

> А дальше она банально не работает.

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

← →
Maacheba (2009-02-13 17:10) [20]

> Для расшифровки нужен полный (private) ключ.

это понятно. Я и хочу поменять концепцию несимметричных ключей.

Чтобы расшифровать мог КАЖДЫЙ (ну теоретически, просто он будет вшит в программу и его при умении можно будет выцепить). А вот ключ для шифрации известен только нам.

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

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

← →
Maacheba (2009-02-13 17:17) [21]

> Зачем серийник еще какой-то ? Вести еще базу серийников
> ?

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

← →
Ega23 © (2009-02-13 17:20) [22]

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

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

← →
Maacheba (2009-02-13 17:30) [23]

Ребят, я очень прошу. Мне эти философские баяны - ну честное слово не нужны, без обид.

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

← →
Jeer © (2009-02-13 17:40) [24]

Удалено модератором
Примечание: Правила, батенька, уважаем...

← →
AndreyV © (2009-02-13 18:13) [25]

Удалено модератором

← →
Maacheba (2009-02-13 18:17) [26]

Удалено модератором

← →
Rouse_ © (2009-02-13 18:38) [27]

> Любой шифр рано или поздно будет вскрыт.

Лежка, я немножко поправлю тебя :) Шифр (если это действительно он) сам по себе занимает самую низшую позицию на этапе взлома. Любой крипкостойкий алгоритм не должен представлять из себя никакой тайны бо ну не сундук-же он. Все строиться на ключах - вот если подобрали ключ, тогда ой. Если ключ разбирается на бруте - тогда ой дважды, если на коллизий - тогда два раза КУ с приседанием и в топку такой алгоритм :)

← →
Maacheba (2009-02-13 18:45) [28]

Розыч, а ты разбираешься в этом деле? Может хоть ты ответишь. А точнее посоветуешь - какой алгоритм (желательно чтобы была готовая реализация на Delphi и на PHP) заюзать, чтобы шифровать закрытым ключом и расшифровывать открытым. При этом чтобы по ключу расшифрации нельзя было подобрать (криптостойкость на уровне) ключ шифрации?

← →
Итого (2009-02-13 18:46) [29]

> по каким критериям генерировать серийный код?

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

← →
Maacheba (2009-02-13 18:48) [30]

Впрочем, похож я на идиота, который бьется головой об стену, причем который раз. пойду спрошу в ЖЖ и на ixbt - вот просто любопытно, уверен на 99%, что ответы там будут гораздо позитивнее и без этой агрессии, характерной для DM последние пару лет.

Разбираюсь.
Используй например RSA для выдачи ключа пользователю, вторую часть ключа храни у себя на сервере и придумывай технологию связки. Например используй эту пару для верификации приложения или генерации сессионного ключа с последующей верификацией. Но это все не то. Это только та часть которая идет на поверхности защиты, самое правильное - это интегрировании защиты в приложение на таком уровне чтобы оно работало в парралели с вычислениями производимыми в самом ПО, т.е. убрать все (как ранее говорили) If THEN и т.п. и использовать полученные при верификации данные при рассчетах или дальнейшей инициализации движка программы. По хорошему конечно-же желательно воспользоваться электронными ключами защиты и их возможностями. Тем более у тебя корпоративные клиенты, а значит конторы не бедные и лишние тысяча-две рублей для них будут копейкой

← →
Maacheba (2009-02-13 19:14) [32]

Саш, насчет электронных ключей я уже высказался, см. пост [16]

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

Я подытожу вопросы, которые сейчас в голове крутятся:

1) к чему лучше привязываться? Первоначальное указание - привязываться к ID процессора... Насколько это гудово?

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

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

2) ты предлагаешь RSA - как я понимаю, это то что используется в PGP. Таким образом, есть открытый ключ и закрытый.
ОБЫЧНО открытым ключом шифруют, а закрытым расшифровывают. И по открытому ключу я точно знаю нереально получить в нормальные сроки закрытый ключ.

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

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

Ну и еще раз - обычно ключ шифрации является public, а ключ дешифрации - private. А у меня получится наоборот, ключ дешифрации - public (относительный), а ключ шифрации - private.

← →
Городской Шаман (2009-02-13 19:20) [33]

> Maacheba (13.02.09 15:30)

Я бы кроме стандартной начальной проверки совпадения ключа добавил бы принцип 1001 китайского несчастья.

К примеру в Pro версии после взлома начального иф/зен/елсе при выполнении некоторых функций с использованием random(если нет совпадения ключа) портил бы работоспособность сеанса системы, например через внедрение удалённой нити в процесс эксплорера или закрузку библиотек через механизм хуков и некое некорректное перенаправление api функций. Так чтобы сеанс продолжал работать, но глючить.

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

← →
Maacheba (2009-02-13 19:29) [34]

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

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

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

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

Шифрование никогда не решало и не решает задачу проверки подлинности информации.

← →
Maacheba (2009-02-13 19:35) [36]

> Шифрование никогда не решало и не решает задачу проверки
> подлинности информации.

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

Почитай на досуге что ли:
http://ru.wikipedia.org/wiki/%D0%AD%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%86%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D1%8F_%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%8C

Удалено модератором

Соответственно, правильность активационного кода определяется исключительно тем, что корректно расшифровалась активационная информация ключом дешифровки.

А кто определяет "правильность расшифровки"?

Снова код программы и снова иф/зен/елсом.

Что? Не программа проверяет, а спрашивает у сервера правильность?
А ответ сервера "правильно/неправильно" расшифровано в клиенте кто проверяет?

Снова клиентский код.

Городской Шаман (13.02.09 19:20) [33]

Срубится антивирусом, смысла нет (я здесь не только про троянов, но и про все эти внедрения). Ну и, разумеется, тут же пойдут (вполне оправданные) байки, что такая-то прога - с вирусом. И даже легальные пользователи, даже если у них антивиус не будет ругаться - будут бояться. А если их еще и немного потенциальных - тогда и вовсе плохо.
Доказать кому-то мол "это потому что пиратка, ничего не знаем" - малореально. Винда вон тоже пиратка, однако ж антивирус на нее не ругается (тут, правда, уже про сук получается, но это же объяснишь).

> Maacheba (13.02.09 17:03) [16]
> не подходит. Нужно уметь изменять
> условия лицензии без перевысылке ключей.

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

А ты не умеешь. Но при этом ничтоже сумняшеся заявляешь о какой-то там "пересылке".

Защита программ: генерирование серийных ном., активационных etc Найти похожие ветки