Показано с 1 по 10 из 1275
Комбинированный просмотр
-
01.06.2019, 21:35 #1
- Регистрация
- 30.05.2019
- Сообщений
- 18
- Сказал(а) спасибо
- 2
- Поблагодарили 1 раз в 1 сообщении
Re: как ломануть 1C 8.3 for Linux
Проблему так и не решил. Пjставил на 64-битный убунту 32-битный сервер с клиентом. Взломал backbas.so патчером rbc. Сначала убрал галочку в настройках "Аппаратный ключ защиты". Запустил - спрашивает лицензию. Потом вернул галочку, хасп запущенный стоит, запускаю:
Текущая:
Локальный HASP4 ORGL8 10, получило клиентское приложение
Информационная база:
Локальный HASP4 ORGL8 500
Локальный HASP4 ORGL8 100.
Уже другая лицензия стоит клиентская. Тест Гилева прошел на УРА. Пока полет нормальный.
Вообще это правильно устанавливать 32битное приложение на 64битное? Есть ли последствия? Или можно спокойно работать, пока не изобретут вакцину для 64битной?
-
02.06.2019, 12:50 #2
- Регистрация
- 18.04.2018
- Адрес
- HP-Compaq DX2300 microtower PC
- Сообщений
- 249
- Сказал(а) спасибо
- 69
- Поблагодарили 1811 раз(а) в 395 сообщениях
Re: как ломануть 1C 8.3 for Linux
Тест Гилева какое значение показал?
на основном моем компе Тест Гилева показал результат 82 "попугая", и ни разу не упала "HASP has been lost!" (оно же KEYWASLOST)
Я достал старенький ноут HP-550, вот на нём прекрасно ловится крах "HASP has been lost!" (вылеченная платформа на WinXP - будем "посмотреть" на механику происходящего).
Если платформа "не вылечена" и ключик ловится по сети, то тест Гилева на HP-550 не падает, выдает 25 "попугаев" (таймауты NH_SESSION и NH_SEND_RCV в nethasp.ini не понадобились).Последний раз редактировалось HPDX2300; 02.06.2019 в 13:11.
"кинжал хорош для того, у кого он есть, и плохо тому у кого он не окажется в нужное время"
-
Пользователь сказал cпасибо:
redhat2020 (13.05.2023)
-
03.06.2019, 10:25 #3
- Регистрация
- 30.05.2019
- Сообщений
- 18
- Сказал(а) спасибо
- 2
- Поблагодарили 1 раз в 1 сообщении
-
03.06.2019, 11:01 #4
- Регистрация
- 25.01.2018
- Адрес
- Подмосковье
- Сообщений
- 50
- Сказал(а) спасибо
- 57
- Поблагодарили 26 раз(а) в 12 сообщениях
Re: как ломануть 1C 8.3 for Linux
1. Насколько помню там был момент что требовалось возвращать в систему файл который получался с расширением .bak, но может и не факт так как глубоко не копал в сторону 32-бит, - этот момент весьма интересен.
2. 32 бит использовать можно и иногда даже приходится, но так же можно нарваться на ограничения самой архитектуры, и дополнительно ощутить снижение производительности.
3. Я бы поглубже покопал почему Ваша конфигурация брыкается, подозреваю что дело как раз может быть в конфигурации которая требует 32 бит? У меня к примеру есть несколько баз в которых вызываются дополнения работающие только в 32 битном режиме, и из за этого приходится держать зоопарк версий и релизов.
ps: Про момент с тестом и отваливанием ключа - насколько помню мелькало что отваливался ключ из за высокой загрузки компьютера на котором запускали тест, и в итоге компьютер просто не успевал обновить результат перепроверки наличия ключа. Опять же насколько помню решали проблему через распределение приоритетов ресурсов.
-
03.06.2019, 14:26 #5
- Регистрация
- 30.05.2019
- Сообщений
- 18
- Сказал(а) спасибо
- 2
- Поблагодарили 1 раз в 1 сообщении
-
03.06.2019, 15:31 #6
- Регистрация
- 25.01.2018
- Адрес
- Подмосковье
- Сообщений
- 50
- Сказал(а) спасибо
- 57
- Поблагодарили 26 раз(а) в 12 сообщениях
Re: как ломануть 1C 8.3 for Linux
Этот момент с приоритетом может и кому нибудь пригодиться, вот один из постов по этому поводу:
"..
foxnet
Я описывал отваливание ключей просто в течение работы. Лечится перезапуском сервиса.
Fragster
Это проблема hasplm при недостаточности процессорных ресурсов. Лечится выделением машины с hasplm на отдельный хост с гарантированной производительностью (не очень большой), у менеджера лицензий должен быть условно реалтайм приоритет."
.. "
-
04.06.2019, 19:34 #7
- Регистрация
- 18.04.2018
- Адрес
- HP-Compaq DX2300 microtower PC
- Сообщений
- 249
- Сказал(а) спасибо
- 69
- Поблагодарили 1811 раз(а) в 395 сообщениях
Re: как ломануть 1C 8.3 for Linux
я уже писал об этом, но видать не у всех отложилось в копилку.
В окне выбора базы нажмите кн."Настройка", откроется диалог параметров платформы,
самая нижняя галка "Использовать аппаратную лицензию (ключ защиты)" - её НЕ ВЫКЛЮЧАТЬ на сломанной платформе, её выключают, видимо, тока обладатели программных лицензий.
Когда она выключена платформой игнорируется часть защитных механизмов, связанная с HASP ключами, поэтому даже вылеченная платформа остается без лицензии, созданной кодом патча unipatch в памяти процесса."кинжал хорош для того, у кого он есть, и плохо тому у кого он не окажется в нужное время"
-
2 пользователя(ей) сказали cпасибо:
redhat2020 (13.05.2023), vfp7 (05.06.2019)
Социальные закладки