(2016-02-24 13:59:38 отредактировано trh)

Защита нескольких dll

Добрый день. Вопрос по технологии защиты.

Есть три Net-овские dll:
- dll_1 - грузится сторонним приложением "A", использует классы из dll_3, лицензирование - на процесс
- dll_2 - грузится сторонним приложением "B", использует классы из dll_3, лицензирования не требует, т.к. используется в частных случаях и только совместно с dll_1
- dll_3 - библиотека классов для dll_1 и dll_2

Процесс защиты dll_1 и dll_3 через LicenseWizard.exe понятен.
Как защищать dll_2 (+ dll_3 ???, но она уже защищена), чтобы при ее использовании не занималась дополнительная лицензия?

Все три dll либо на клиентском ПК в папке приложения "B", т.к. используют библиотеки этого приложения, либо dll_1 и dll_3 на сервере терминалов, а dll_2 и dll_3 на клиентском ПК.

Re: Защита нескольких dll

На сколько я понимаю, у меня есть только один путь:
1 этап - обфусцирую совместно три библиотеки;
2 этап - защищаю код только dll_1.

Или я не прав?

Re: Защита нескольких dll

Здравствуйте!
Из Вашего объяснения не совсем понятно, какой именно совет Вы хотите от нас получить.
Если Вы хотите привязать 3 библиотеки .net  к нашему ключу с помощью мастера лицензирования и автоматической защиты, то Вам нужно добавить все эти библиотеки в проект. Обращаю Ваше внимание, что библиотеки с внешними вызовами не следует подвергать обфускации.
Если я Вас правильно понял, Вам нужно в Ваш проект автозащиты добавить dll_2, но не подвергать его функции защите и не обфусциоровать, а остальные dll защитить по аналогии с предыдущим проектом.

(2016-02-25 10:23:22 отредактировано trh)

Re: Защита нескольких dll

Станислав Петрушевский пишет:

Здравствуйте!
Из Вашего объяснения не совсем понятно, какой именно совет Вы хотите от нас получить.
Если Вы хотите привязать 3 библиотеки .net  к нашему ключу с помощью мастера лицензирования и автоматической защиты, то Вам нужно добавить все эти библиотеки в проект. Обращаю Ваше внимание, что библиотеки с внешними вызовами не следует подвергать обфускации.
Если я Вас правильно понял, Вам нужно в Ваш проект автозащиты добавить dll_2, но не подвергать его функции защите и не обфусциоровать, а остальные dll защитить по аналогии с предыдущим проектом.

App_1 <---> dll_1 <--- dll_3 ---> [dll_2 <---> App_2]

App_1 - основное приложение, используемое пользователем. App_1 загружает dll_1 (COM объект). App_1 может располагаться как на пользовательском ПК, так и на терминальном сервере, значит лицензировать надо "на процесс".

App_2 - вспомогательное приложение, которое пользователь может использовать (а может и не использовать). App_2 располагается на клиентском ПК и загружает dll_2. dll_2 взимодействует c dll_1 посредством различных механизмов, использование dll_2 без dll_1 невозможно и не имеет смысла, значит лицензировать ее (ограничивать количество запусков) не надо

dll_3 библиотека классов для dll_1 и dll_2 (т.е. подгружается обеими и dll_1 и dll_2 ), значит лицензировать ее не надо.

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

Т.к. dll_1 + dll_3 грузятся процессом App_1, а dll_2 + dll_3 грузятся процессом App_2, то получается чтобы занять всего одну лицензию, я должен защитить протектером только dll_1. Т.е. я не могу добавить все три библиотеки в проект Мастера лицензирования, и не могу добавить две любые библиотеки, иначе один пользователь займет две лицензии при использовании dll_1 и dll_2 (напомню что они используются разными процессами). Мне кажется в опции "Ограничивать запуск в сети" очень не хватает четвертого пункта "Не ограничивать", тогда можно было бы добавить в проект все три библиотеки как независимые, dll_1 ограничить по количеству процессов, а dll_2 и dll_3 не ограничивать. Можете посоветовать что мне делать?

Почему нельзя обфусцировать библиотеки с внешними вызовами? Обфусцирую все кроме публичных интерфейсов и вроде все работает.

Re: Защита нескольких dll

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

Упрощу задачу.
Если я разобью библиотеку dll_3 на две  - dll_3 и dll_4, dll_3 будет использоваться только в dll_1, а dll_4 только в dll_2. Тогда я смогу полноценно защитить dll_1 и dll_3 через LicenseWizard. Но остается открытым вопрос о защите dll_2 и dll_4 таким образом, чтобы не захватывалась еще одна лицензия при использовании dll_2.

Все таки нужен пункт "Не ограничивать" в настройке "Ограничивать запуск по сети" (/LOGIN_MODE=H | S | P | N ).

Напишу по вашему совету запрос на hotline.

Re: Защита нескольких dll

Здравствуйте.

trh пишет:

App_1 - основное приложение, используемое пользователем. App_1 загружает dll_1 (COM объект). App_1 может располагаться как на пользовательском ПК, так и на терминальном сервере, значит лицензировать надо "на процесс".

Уточните, пожалуйста, верно ли то, что за основной фактор, который "мешает" применять лицензирование по рабочим станциям, принята вероятность установки защищенного приложения на сервере терминалов?

Re: Защита нескольких dll

Антон Тихиенко пишет:

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

Да. Это факт, т.к. некоторые внедрения проходят непосредственно через нас.

Re: Защита нескольких dll

trh пишет:

Да. Это факт, т.к. некоторые внедрения проходят непосредственно через нас.

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

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

Re: Защита нескольких dll

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

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

1. А если в настройках терминала нет ограничения на количество сессий для пользователя?
2. dll_2 на клиентском ПК все равно будет занимать еще одну лицензию

Re: Защита нескольких dll

trh пишет:

1. А если в настройках терминала нет ограничения на количество сессий для пользователя?

Не влияет.

trh пишет:

2. dll_2 на клиентском ПК все равно будет занимать еще одну лицензию

trh пишет:

App_2 - вспомогательное приложение, которое пользователь может использовать (а может и не использовать). App_2 располагается на клиентском ПК и загружает dll_2. dll_2 взимодействует c dll_1 посредством различных механизмов, использование dll_2 без dll_1 невозможно и не имеет смысла, значит лицензировать ее (ограничивать количество запусков) не надо

Верно ли то, что App_2 и dll_2 не будут защищаться?

Re: Защита нескольких dll

Антон Тихиенко пишет:

Верно ли то, что App_2 и dll_2 не будут защищаться?

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

Re: Защита нескольких dll

trh пишет:

dll_2 необходимо защитить, но чтобы она не захватывала лицензию

В таком случае достаточно защищать и лицензировать dll_2 "по рабочим станциям" без использования таблицы лицензий (параметр dwModuleLMS задается как "-1").

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

(2016-03-10 16:10:42 отредактировано trh)

Re: Защита нескольких dll

Антон Тихиенко пишет:

В таком случае достаточно защищать и лицензировать dll_2 "по рабочим станциям" без использования таблицы лицензий (параметр dwModuleLMS задается как "-1").

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

Попробовал. Не работает ваша схема. Пошагово ...

SignNet:  общий ресурс ключа = 2; Модуль №1 = 2.

Обфускатор:
/INIT /CFO=хх /SO /SE ... /ATR=1 /GN3S=0:х:ххх /UN=0x2 /MN=0 /LOGIN_MODE=S "dll1.dll" /ATR=1 /GN3S=0:x:xxx /LOGIN_MODE=S "dll2.dll"

Протектер:
/GN3S=0:x:xxx /ATR=1 /PER=xx /UN=0x2 ... /EXCEPT /LOGIN_MODE=S /MN=0 /Q "dll1.dll"
/GN3S=0:x:xxx /ATR=1 /PER=xx /LOGIN_MODE=S /Q "dll2.dll"

1. Юзер1 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.
2. Юзер2 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.

Итого 0 свободных лицензий в общем ресурсе.

3. Юзер1 заходит на терминал, запускает App1, которое пытается загрузить dll1,  и видит сообщение об отсутствии ресурсов...
Напомню, App1 основное приложение,  а App2 вспомогательное, которое в некоторых компаниях может и не использоваться.

Если делать наоборот (выкинем из автозагрузки App2) - зашли в терминал, запустили App1, переключились на свой рабочий стол, запустили App2, переключились в терминал, то работает. Но, согласитесь, как-то это не решение, а костыль.

Re: Защита нескольких dll

trh пишет:

Если делать наоборот (выкинем из автозагрузки App2) - зашли в терминал, запустили App1, переключились на свой рабочий стол, запустили App2, переключились в терминал, то работает.

Тут не совсем понятно сколько ПК учавствует в тестировании: один ПК + терминальная сессия или два ПК + две терминальные сессии? Какой компьютер выступает в роли сервера терминалов: отдельный или один из пользовательских?

Re: Защита нескольких dll

Антон Тихиенко пишет:
trh пишет:

Если делать наоборот (выкинем из автозагрузки App2) - зашли в терминал, запустили App1, переключились на свой рабочий стол, запустили App2, переключились в терминал, то работает.

Тут не совсем понятно сколько ПК учавствует в тестировании: один ПК + терминальная сессия или два ПК + две терминальные сессии? Какой компьютер выступает в роли сервера терминалов: отдельный или один из пользовательских?

Поторопился с "наоборот" - тоже не работает, для dll2 на клиентских ПК нет ресурсов на ключе.

Re: Защита нескольких dll

trh пишет:

1. Юзер1 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.
2. Юзер2 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.
Итого 0 свободных лицензий в общем ресурсе.
3. Юзер1 заходит на терминал, запускает App1, которое пытается загрузить dll1,  и видит сообщение об отсутствии ресурсов...
Напомню, App1 основное приложение,  а App2 вспомогательное, которое в некоторых компаниях может и не использоваться.

trh пишет:

Поторопился с "наоборот" - тоже не работает, для dll2 на клиентских ПК нет ресурсов на ключе.

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

Так в данном примере, для ключа с общим сетевым ресурсом в две лицензии, в первом случае обе лицензии занимаются приложением App2, запускаемом на двух локальных рабочих станциях, а для терминальных сессий (им нужны дополнительные лицензии) лицензий уже нет. И наоборот - для App1, запускаемом в двух терминальных сессиях, выделяются обе лицензии, а для App2 лицензий не хватает. Тут либо App1 нужно запускать на тех же рабочих станциях, что и App2, либо App2 переносить на сервер терминалов.

(2016-03-11 11:16:33 отредактировано trh)

Re: Защита нескольких dll

Антон Тихиенко пишет:

App1 нужно запускать на тех же рабочих станциях, что и App2, либо App2 переносить на сервер терминалов.

App1 и App2 (есть еще и App3, которое в данном обсуждении не рассматривается) - сторонний софт, который интегрируется посредством наших dll.

App1 в частном случае - это 1С. Я сомневаюсь что небольшие фирмы ради интеграции будут менять технологию работы с 1С (работа с файловой базой на терминальном сервере или работа с клиент-серверной базой), т.к. это требует немалых дополнительных расходов (железо, софт, услуги по переходу, дальнейшая поддержка - за SQL надо "ухаживать",  Сервер 1С:Предприятия тоже иногда внимания к себе требует).

App2 не будет работать в терминальной сессии.

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

Re: Защита нескольких dll

trh пишет:

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

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

Re: Защита нескольких dll

Антон Тихиенко пишет:

... но приоритет у нее низкий и пока нет планов ее реализации даже в следующем релизе Guardant SDK ...

Печально