Установка WinRIK и ГРАНД-Смета

[Aku_Demon]

проблема в следующем:

было:

на сервере:

имеется WINRik версии проф 1.3.080110

ключ - LTP

запущена - NNKSRV32.EXE (версия Guardant 2.5.0.0)

на клиенте:

имеется WINRik версии проф 1.3.080110

запущена - NNKMON32.EXE (версия Guardant 4.3.0.0)

и все прекрасно работало... пока не сделали так:

на сервере:

дополнительно поставили ГРАНД-смету версии 3.0

так же установился драйвер Guardant 5.10.48

ключ - USB

WINRik прекрасно запускается (ибо ключ на прямую к кому подключен)

после ребута перестал запускаться NNKSRV32.EXE (версия Guardant 2.5.0.0)

и соответственно WINRik на клиенте перестал видеть ключ

как быть?

PS:

скачал с сайта драйвера Guardant 5.20.65 и обновил на:

сервере - grdsrv.exe (версия 5.2.0.0)

клиенте - grdmon.exe (версия 5.2.0.0)

всеравно не видят друг друга.

[Sergey]

Как я понимаю ключ на Гранд-смету у вас локальный? Если да, то именно в этом состоит проблема. Менеджер лицензий, в принципе не должен запускаться на локальном ключе. Неоднократно сталкивался в случае одновременного использования на одном компьютере Guardant ключей USB и LPT типа, почему-то обращения к USB ключам происходят быстрее и приоритет по запросам у этих ключей выше. Как я думаю, проблема именно в этом.

[Aku_Demon]

ключ локальный.

ну и как решить-то?

[Sergey]

Как вариант: вернуть все как было и поставить Гранд-смету не на сервер, а на любой их компов в сети.

[Aku_Demon]

отпадает. надо именно на "сервере" и Гранд и ключ Рика

[Aku_Demon]

нет идей? разработчики\хозяива Рика здесь не бывают? или мне на форум Гранд сметы идти? :twisted:

[Sergey]

нет идей? разработчики\хозяива Рика здесь не бывают? или мне на форум Гранд сметы идти?

Насколько я понимаю, твоя проблема связана с тем, что менеджер лицензий сетевых ключей Guardant не может запуститься на сервере, в том случае когда на сервере одновременно подключены два Guardant ключа: один сетевой от программы РИК LPT типа, а второй локальный от Гранд-сметы USB типа. Разработчики программы РИК и разработчики Гранд-сметы в сложившейся ситуации, вообще-то говоря, ни при чем. Как мне кажется в этой ситации правильнее было бы обратиться к разработчикам ключей защиты Guardant и менеджера лицензий для сетевых ключей Guardant. Напиши вопрос в службу технической поддержки на сайте Guardant-а. Укажи какие типы ключей стоят (имеются ввиду серии ключей, например Guardant Stealth II, Guardant Net II и т.д. данную информацию можно посмотреть на самом ключе, укажи версию драйвера ключа). И пожалуйста выложи их предложения по решению проблемы в эту ветку форума, лично мне интересен вариант решения подобной проблемы.

[Sergey]

Немножко не в тему, прошу прощения.

Пару раз доводилось сталкиваться с косяками со стороны компании "Актив" - разработчика ключей Guardant. Последний пример был таким: у организации пользователя РИКа, так же стоит сетевой ключ. Сам ключ установлен на Windows Server и на сервере так же поднят менеджер лицензий. Кроме этого на сервере стоит программа прокси-сервер, обеспечивающая доступ к сети интернет для компьютеров из локальной сети организации. В составе менеджера лицензий Guardant есть программа grdmon.exe, позволяющая просматривать состояние сетевого ключа. Ну так вот в этой организации при попытке запуска этой программы, вместо веб-интерфейса состояния ключа открывается веб-интерфейс состояния прокси-сервера, хотя через адресную строку любого из браузеров все открывается нормально. Я уже писал об этой проблеме в техподдержку компании "Актив", но ответа от них так и не получил. Причем в последних версиях менеджера лицензий данная проблема не исправлена.

[Гость root]

Я уже писал об этой проблеме в техподдержку компании "Актив", но ответа от них так и не получил. Причем в последних версиях менеджера лицензий данная проблема не исправлена.

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

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

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

Вот такой рецепт выдал Актив для защиты от эмуляторов ключей:

"Вы перейдите на Stealth III и переделайте свою защиту под него".

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

В итоге пришлось самому изобретать велосипед, благо получилось.

[Aku_Demon]

2Sergey

нет идей? разработчики\хозяива Рика здесь не бывают? или мне на форум Гранд сметы идти?

Насколько я понимаю, твоя проблема связана с тем, что менеджер лицензий сетевых ключей Guardant не может запуститься на сервере, в том случае когда на сервере одновременно подключены два Guardant ключа: один сетевой от программы РИК LPT типа, а второй локальный от Гранд-сметы USB типа.

[Sergey]

Приведенный тобой вариант не относится к системе защиты программы, а относится к совместному использованию двух сметных программ работающих на одном компьютере и использующих для доступа к базам данных Borland Database Engine (BDE).

[Aku_Demon]

так и думал :?

[Aku_Demon]

ответ от Guardant Hotline:

"Попробуйте, пожалуйста, сделать следующее:

- включите в настройках сервера GrdSrv.exe опцию "Опрос LPT-ключей" - т. к. по умолчанию она отключена

- пропишите в настройках конфигурационных файлов клиентов (GnClient.ini) IP-адрес компьютера, на котором установлены сервер и ключ."

[Sergey]

ответ от Guardant Hotline:

"Попробуйте, пожалуйста, сделать следующее:

- включите в настройках сервера GrdSrv.exe опцию "Опрос LPT-ключей" - т. к. по умолчанию она отключена

Ну и как, помогло?

[Aku_Demon]

сделал - новая версия сервера Guardant стала видеть LTP ключ, подключенный к машине -> ключ клиент увидел тоже :!:

но т.к. перенесли ключ WinRIK на 2ю тачку (а на 1й так и остается ключ от Гранд-сметы) - то работоспособность 2х ключей на одной тачке не проверял :?

[Павел]

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

Разве так можно? DeviceIoControl?

Вот такой рецепт выдал Актив для защиты от эмуляторов ключей:

"Вы перейдите на Stealth III и переделайте свою защиту под него".

Странный ответ. Слышал, что и эти ключи эмулируют.

В итоге пришлось самому изобретать велосипед, благо получилось.

То есть в новых версиях эмуляторы не будут работать? Было бы хорошо. Развелось у нас в городе сметчиков с кривыми и ломаными программами, работать нормально не дают.

[Гость root]

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

Разве так можно? DeviceIoControl?

Не только, но и это тоже.

Вот такой рецепт выдал Актив для защиты от эмуляторов ключей:

"Вы перейдите на Stealth III и переделайте свою защиту под него".

Странный ответ. Слышал, что и эти ключи эмулируют.

Меня их ответ тоже повеселил. Эмулировать можно все, вопрос во времени и трудозатратах. А рецепт Актива - это просто дешевая отмазка и нежелание что-то делать.

В итоге пришлось самому изобретать велосипед, благо получилось.

То есть в новых версиях эмуляторы не будут работать? Было бы хорошо. Развелось у нас в городе сметчиков с кривыми и ломаными программами, работать нормально не дают.

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

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

[Павел]

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

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

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

2. Защита от общедоступных эмуляторов (GiA Emulator, lzdc): проверка веток реестра, файлов D8EC8FA9 (.bin, .dmp и др.) в папке windows\system32\drivers.

3. Существует также какой-то "полный" эмулятор (маленький такой). В нем ключ лежит в открытом виде. Можно, допустим, искать в папке windows\system32\drivers файлы с шестнадцатеричным кодом 0xA9 0x8F 0xEC 0xD8. Если такой файл обнаружен, то для подстраховки также можно искать в нем публичный код ключа в шестнадцатеричном виде. Если такой файл найден, то можно либо сразу ругаться на эмулятор, либо проверить существование и статус службы с именем, как у подозрительного файла.

4. Проверка ключа с кодом чтения, взятым "от балды". Эмулятор может отправлять статус "Успешно" на запрос ключа с любым кодом чтения.

5. Более широкое применение флагов ключа (поиск ключа с определенным kmNProg, kmVer, kmSN, kmMask). Искать ключ с заранее неверными флагами и, если такой ключ найден, ругаться на эмулятор. Можно также использовать в параметрах поиска ключа флаг CodeIsString. Эмулятор может не понимать этот флаг. Также искать код с заранее неверным CodeIsString.

6. Использовать запись в свободную память ключа с последующей проверкой данных. Эмулятор может не поддерживать запись. Пробовать запись в запрещенную память ключа (эмулятор может отправлять статус "Успешно" на запись в запрещенную память).

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

8. Проверять дату окончания обновления, чтобы она не была слишком высокой.

[Гость root]

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

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

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

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

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

2. Защита от общедоступных эмуляторов (GiA Emulator, lzdc): проверка веток реестра, файлов D8EC8FA9 (.bin, .dmp и др.) в папке windows\system32\drivers.

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

3. Существует также какой-то "полный" эмулятор (маленький такой). В нем ключ лежит в открытом виде. Можно, допустим, искать в папке windows\system32\drivers файлы с шестнадцатеричным кодом 0xA9 0x8F 0xEC 0xD8. Если такой файл обнаружен, то для подстраховки также можно искать в нем публичный код ключа в шестнадцатеричном виде. Если такой файл найден, то можно либо сразу ругаться на эмулятор, либо проверить существование и статус службы с именем, как у подозрительного файла.

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

4. Проверка ключа с кодом чтения, взятым "от балды". Эмулятор может отправлять статус "Успешно" на запрос ключа с любым кодом чтения.

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

5. Более широкое применение флагов ключа (поиск ключа с определенным kmNProg, kmVer, kmSN, kmMask). Искать ключ с заранее неверными флагами и, если такой ключ найден, ругаться на эмулятор. Можно также использовать в параметрах поиска ключа флаг CodeIsString. Эмулятор может не понимать этот флаг. Также искать код с заранее неверным CodeIsString.

Вообщем это продолжение пункта 4. ;-) Ключ и так ищется с определенными флагами.

6. Использовать запись в свободную память ключа с последующей проверкой данных. Эмулятор может не поддерживать запись. Пробовать запись в запрещенную память ключа (эмулятор может отправлять статус "Успешно" на запись в запрещенную память).

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

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

Да вот это то и напрягает, стоит чуть-чуть изменить алгоритм и наступит армагедон у тех поддержки.

8. Проверять дату окончания обновления, чтобы она не была слишком высокой.

Это без проблем поставить не более 1 года, если выше то ошибка. Правда это так мелочевка, обойти не составит большого труда.

Итого:

1. Поставить опросы ключа с заранее не верными параметрами поиска.

2. Проверка на дату обновления больше 1 года.

3. Поиск D8EC8FA9 (.bin, .dmp и др.) в папке windows\system32\drivers. Под вопросом, труда не составит изменить эмулятор и называть эти файлы произвольно.

[Павел]

6. Использовать запись в свободную память ключа с последующей проверкой данных. Эмулятор может не поддерживать запись. Пробовать запись в запрещенную память ключа (эмулятор может отправлять статус "Успешно" на запись в запрещенную память).

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

Не соглашусь.

Во-первых: ключ на запись и так хранится в программе (а точнее в секции автоматической защиты на исполняемых файлах). Чтобы не быть голословным: начинается он с символа 'C', а сумма всех его байтов равна 20Eh (526).

Во-вторых: ну пусть он там хранится. Что в этом такого? Макстер-код ведь не раскрывается. Что может сделать пользователь, имея ключ на запись. Да практически ничего.

В-третьих: я уже видел программу winrik maintenance utility v1.0, которая может менять некоторые данные в Вашем ключе (номер ключа, дилера и программы).Из этого вытекает, что пароль на запись ключа - не такая уж и секретная штука и достать его не сложно.

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

[Павел]

3. Поиск D8EC8FA9 (.bin, .dmp и др.) в папке windows\system32\drivers. Под вопросом, труда не составит изменить эмулятор и называть эти файлы произвольно.

Не составит труда сделать все, что угодно. Однако на данный момент это вполне приемлимый вариант определения эмулятора.

P.S.: Отправил некоторую дополнительную информацию в ЛС.