"Отложенный" вызов защиты в Envelope

Страницы: 1
RSS
"Отложенный" вызов защиты в Envelope, При запуске программа должна проверять, что один экземпляр уже запущен.
 
LDK 7.5
Есть программа (C#) которая при запуске проверяет ключ командной строки, и если один экземпляр с таким ключом уже запущен, то он должен активироваться (без отнимания лишней лицензии), но если ключ другой, то должен запуститься ещё один экземпляр этой программы, соответственно, отняв лицензию. Теперь представим, что на ключе записана одна лицензия. И один экземпляр программы (защищённый Envelope) уже запущен. Мы запускаем программу с тем же самым ключом ещё раз и вместо того, чтобы увидеть ранее запущенное окно, видим сообщение HASP, о том, что нет свободной лицензии. Подскажите, как "навесить" защиту так, чтобы она запускалась уже после необходимых проверок.
Вариант: сделать свой проект в DLL и написать "пускач" не предлагать.
 
1) как выглядят эти ключи, сколько разных враиантов значения ключа может быть ?

2) сколько экземпляров запущенной программы может быть по всем ключам суммарно? Какой модели аппаратный HASP-ключ ?  
 
Добрый день, Валерий.

Envelope такой механизм реализовать не сможет. Вам скорее подойдёт такой вариант:
Защищаете своё ПО на feature id 1 - эту feature Вы пишите во все ключи и никак её не ограничиваете, она будет отвечать только за запуск ПО и отработку защиты Envelope. Далее в коде своего ПО, сразу после запуска, Вы будите проверять с каким идентификатором запускалось ПО, затем это значение Вы сверяете с тем что есть в заранее определённой RW области памяти на ключе, если там нет такого идентификатора - открываете окно своего приложения и в память на ключе пишите PID процесса и идентификатор с которым этот процесс запускался. Если же в памяти ключа уже есть запись с таким идентификатором - выводите на передний план процесс с соответствующим PID'ом, а данное окно закрываете.

"Из коробки" Вы подобное не получите, нужно писать самостоятельно с помощью нашего API + Envelope.
 
> Защищаете своё ПО на feature id 1 - эту feature Вы пишите во все ключи и никак её не ограничиваете

Зачем изобретать велосипед?

Envelope ставитcя на feature ID = 0 - ибо она на фабрике зашита в каждый ключ и ее специально писать не надо. Для защиты от реверса - вполне хватит.

Вот только тут и вступает в игру мой второй вопрос.

Допустим, что у него ключи Net-10
И он хочет продать на этот один ключ 8 программ Feature=20 и ещё 8 программ Feature=21

Каждая из этих фич по отдельности не переполняется, а вот общая для конверта Feature=0 (или Feature=1 - без разницы) уже фсио.
 
Цитата
Yury Goryachev пишет:
Далее в коде своего ПО, сразу после запуска, Вы будите проверять с каким идентификатором запускалось ПО, затем это значение Вы сверяете с тем что есть в заранее определённой RW
Ужас какой! не вы ли меня когда-то критиковали за самостоятельный учёт ограничения календаря в памяти ключей ,вместо использование LicGen API :-D

Дальше мы прoсто берем функцию - см. мой первый вопрос - типа "ключи командной строки" => "Feature ID". В сааамом тупом варианте - строковая хэш функция с ксоркой до 24 или 16 бит.

Прогоняем через неё командную строку и выполняем примитивный hasp_login с вычисленной уникальной Feature ID

А эту Feature ID прописываем в ключ стандартными способами LicGen API или EMS в режиме "считать по головам" ( count logins PER PROCESS )
 
Цитата


Yury Goryachev пишет:
сверяете с тем что есть в заранее определённой RW области памяти на ключе, если там нет такого идентификатора - открываете окно своего приложения и в память на ключе пишите PID процесса и идентификатор с которым этот процесс запускался.
1) и получаем типовой race condition. Мы еще в школе так запускали бои на 5 кораблей там, где именно по такой схеме было разрешено только 4 - https://en.wikipedia.org/wiki/NetWars

2) и получаем совпадение Process ID у программ, запущенных на разных компьютерах ( в случае типового офисного набора, где образы системы накатываются с одной и той же болванки и автостарты полностью совпадают как следствие)
 
Зачем писать в ключ PID не понимаю - мьютексы, ИМХО, эффективнее. Ключи я использую сетевые. Лицензии считаются следующим образом: программа может запускаться с разными ключами (предположим, конфигурации).
Программа запущенная на разных машинах, независимо от ключей - лицензии по количеству машин.
Программа запущенная на одной машине с разными ключами - лицензии по количеству экземпляров.
Повторный запуск на машине программы с уже работающим ключом не должен отнимать лицензию, а должен открывать уже запущенный экземпляр.
Я могу реализовать проверку экземпляров и учет лицензий в собственном коде, но, ведь, энвелопер не только навешивает защиту, но и выполняет другие функции (например, обфусцирует код)
 
> Ключи я использую сетевые.
>  мьютексы, ИМХО, эффективнее

сетевые мьютексы? :-D

сетевых ключей - много разных моделей

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

Вообще не касается HASP'a. Как найти уже запущенную программу и ее разбудить - во всех FAQ по всем языкам программирования

Пока не разберетесь запускаться или нет - hasp не трогаете. Когда разобрались, либо не касаясь hasp'a активируете уже работающую и закрываетесь, или hasp_login и работаете сами

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

Экземпляров чего? машин? Process ID ? конфигураций? в терминах SQL написать можете что конкретно вы считаете ?

Я считаю, что для каждой конфигурации задается свой feature ID и на него  пишется в ключ лицензия "по экземплярам". Если количество конфигураций конечно... В общем - см. выше
 
Цитата
Дмитрий Буров пишет:
сетевые мьютексы? :-D
Подкол засчитан. Каюсь - не совсем точно описал свои "хотелки". Программа запущенные на разных машинах - разные лицензии, тут даже проверять нечего. Проблема начинается, когда программа запускается на одной машине.

Цитата
Дмитрий Буров пишет:
сетевых ключей - много разных моделей
Много. Но если не рассматривать NetTime, остаётся только HASP Net X, где X - максимальное количество лицензий. И если клиент покупает 5 лицензий, то давать ему HASP NET 25, несколько не оптимально.
Цитата
Дмитрий Буров пишет:
Вообще не касается HASP'a.
А я где-то просил, чтобы это делал HASP? Я, по-моему, уже писал, что всё это могу сделать сам (собственно, как и реализовать защиту). Энвелопер, в таком случае, потребуется только для обфусцирования и защиты кода (без привязки к HASP), но, если я правильно помню, для такого режима работы этой поделки требуется потратить ещё некоторое количество вечнозелёных северозаокеанских единиц. Или я не прав?
Цитата
Дмитрий Буров пишет:
Экземпляров чего? машин? Process ID ? конфигураций? в терминах SQL написать можете что конкретно вы считаете ?
Вот тут у меня и возникает некоторая головная боль. Хотя, Вы натолкнули меня на мысль.
Внутри программы я функционал защищаю на конкретную фичу, которая и будет считать процессы с разными конфигурациями на одной машине и по всем машинам скопом. Так же логиниться на эту фичу программа будет уже после проверки запущенных конфигураций. Энвелопер же будет навешиваться на фичу 0, которая по-дефолту считаетcя как "Per Stations" (т.е. в пределах одного компа, даже при одной захваченной лицензии можно запустить второй процесс и проверить: "а не выполняется ли уже такой же?". Причём, если второй экземпляр программы запускается на второй машине, то мы получаем отлуп, так как лицензия уже захвачена на первой машине.
А это идея! Спасибо за помощь!

Цитата
Дмитрий Буров пишет:
Я считаю, что для каждой конфигурации задается свой feature ID и на него пишется в ключ лицензия "по экземплярам". Если количество конфигураций конечно...
В том-то и дело, что конфигурации создаёт сам человек и сколько их будет я не знаю. Я только стремлюсь ограничить количество одновременно работающих процессов. Но как это сделать - я уже понял.

Всем спасибо за помощь!
Страницы: 1
Читают тему (гостей: 1)