как ломануть 1C 8.3 for Linux

[yhm57878@cndps]

Поставь дамп на 100 пользователей. На 500 сделами из 100

поставил на 100, результат такой же

[yhm57878@cndps]

kaisar@Z500:~/Загрузки/1c$ service usbhasp status
● usbhasp.service - LSB: USBHasp Emulator
Loaded: loaded (/etc/init.d/usbhasp; generated)
Active: active (running) since Thu 2019-05-30 21:48:29 +06; 2min 32s ago
Docs: man:systemd-sysv-generator(8)
Process: 1926 ExecStart=/etc/init.d/usbhasp start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4492)
CGroup: /system.slice/usbhasp.service
└─1953 /usr/bin/usbhaspd -d /opt/1c-key/v8-100-user.json /opt/1c-key/v8-server-x64.json

мая 30 21:48:29 Z500 usbhasp[1953]: Port 1 connected.
мая 30 21:48:29 Z500 usbhasp[1953]: Port 2 is powered on -> connecting device.
мая 30 21:48:29 Z500 usbhasp[1953]: Port 2 connected.
мая 30 21:48:29 Z500 usbhasp[1926]: ...done.
мая 30 21:48:29 Z500 systemd[1]: Started LSB: USBHasp Emulator.
мая 30 21:48:29 Z500 usbhasp[1953]: Port 1 is disabled.
мая 30 21:48:29 Z500 usbhasp[1953]: Set device on port 1 address = 2
мая 30 21:48:30 Z500 usbhasp[1953]: Port 2 is disabled.
мая 30 21:48:30 Z500 usbhasp[1953]: Set device on port 2 address = 3
мая 30 21:48:33 Z500 usbhasp[1953]: Port 2 is suspended.

[HPDX2300]

Вложение 2210Вложение 2211
Сделал все как написали, появились две папки с названиями 1cv8* и 1cv8c*. На всякий оба приложил

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

у меня лично компу более 10 лет, но проц у меня i7 4 физических ядра, каждое с hyper threading, и оперативки 32Гига - больше мазерборд не скушает (я бы дал).
на шустром компе такое поведение может не проявиться

но это только лишь мое предположение, можно включить более подробное логирование, но мне не хватит опыта в нем разобраться.
напоследок, я бы проделал последний эксперимент, но тут нужен еще один физический комп для эмулятора:
1) поставить на него эмуль и Lic. Manager - раздавать ключи по сети
2) тест гилева выполнять в ситуации, когда локальный эмулятор не работает. ключик ловится по сети со 2-го компа
3) для ловли ключа из сети возможны болшие задержки, поэтому парни в "1 сек" ввели параметры таймаутов в hethasp.ini (смотреть пост #177). при работе с локальным ключом невозможно увеличить таймауты на операциях чтения ключа. Поэтому на слабом компе тест гилева надо выполнять с сетевым эмул-ом и hethasp.ini как в посте #177.

если крах "Ключ защиты программы больше не доступен! Работа программы завершена." ловится с эмулятором на другом компе, значит вопрос стоит того, чтобы с ним внимательно разобраться т.к. это проявление защитных механизмов платформы.

[yhm57878@cndps]

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

у меня лично компу более 10 лет, но проц у меня i7 4 физических ядра, каждое с hyper threading, и оперативки 32Гига - больше мазерборд не скушает (я бы дал).
на шустром компе такое поведение может не проявиться

но это только лишь мое предположение, можно включить более подробное логирование, но мне не хватит опыта в нем разобраться.
напоследок, я бы проделал последний эксперимент, но тут нужен еще один физический комп для эмулятора:
1) поставить на него эмуль и Lic. Manager - раздавать ключи по сети
2) тест гилева выполнять в ситуации, когда локальный эмулятор не работает. ключик ловится по сети со 2-го компа
3) для ловли ключа из сети возможны болшие задержки, поэтому парни в "1 сек" ввели параметры таймаутов в hethasp.ini (смотреть пост #177). при работе с локальным ключом невозможно увеличить таймауты на операциях чтения ключа. Поэтому на слабом компе тест гилева надо выполнять с сетевым эмул-ом и hethasp.ini как в посте #177.

я в другой ветке форума предположил, что крах "Ключ защиты программы больше не доступен! Работа программы завершена." вызван недоработкой парней, сделавших "лекарство" unipatch (rbc_icp - это он же с добавлением лечения краха "повреждение девственности платфлормы" ). Но теперь у меня созревает подозрение, что крах "Ключ защиты программы больше не доступен! Работа программы завершена." ловят те, кто работает с локальным ключом/эмулем на относительно слабом железе.

На винде 1Ска нормально работает с rbc_icp. Запускал на Manjaro, эмулятор не смог установить, но на другой машине раздавались ключи, и в этой сети у меня тесты Гилева и другие махинации с платформой шли без каких либо ошибок. Да, вы правы, после каких либо нагрузок: загрузка отчета большого, тестирование сразу вылетает. А нельзя тайминги увеличить на локальном эмуляторе?

[HPDX2300]

На винде 1Ска нормально работает с rbc_icp. Запускал на Manjaro, эмулятор не смог установить, но на другой машине раздавались ключи, и в этой сети у меня тесты Гилева и другие махинации с платформой шли без каких либо ошибок. Да, вы правы, после каких либо нагрузок: загрузка отчета большого, тестирование сразу вылетает. А нельзя тайминги увеличить на локальном эмуляторе?

они в коде (захардкодены) и не настраиваются.
пожалуй, я не прав про "ловят те, кто работает с лок.эмулем на относительно слабом железе" - еще его ловят те, кто работает на платформе, вылеченной rbc_icp.
вот что я почитал в ветке про эмули:
1)
"После установки 8.3.14.1565_Windows_Repack_x86 во всех файловых базах БП 2.0 появляется ошибка KEYWASLOST через 2-3 минуты после запуска 1С"

2)
"про 8.3.14.1630:
У меня эмуляторов не было, пользовался патчерами. Режим БД MSSQL на 2016 виндовом серваке. Сутки почти - работает.
Скидывал товарищу, у него файловый режим, эмуляторов тоже не было. Не работает, через 10 минут пишет ошибку об отсутствии лицензий.
Ради эксперимента развернул его базу у себя на чистой виртуалке - у меня работает."

3)
"Подскажите как решили проблему "Ключ программы больше не доступен"?
Стояла 8.3.13.1690 с этого форума, поставил 8.3.14.1630.
В БП 2.0 постоянно вылетает такая ошибка, в БП 3.0 её нет."

т.е. БП-2.0 частенько вылетает с крахом KEYWASLOST, а БП-3 "не кашляет".

4)
"Ситуация такая. Сервер windows 2016, 1c 8.3.13.1690 (x64 + x86 для отчетов pdf) + HASP LM.
Поставил MultiKey. Aladdin монитор видит занятую лицензию
Ранее было установдено 8.3.13.1513 и пропатчено rbc_ipc.
В режиме Предприятия вопросов нет.
В конфигураторе при обновлении конфигурации, при попытке записать изменения вылетает:
"Ключ защиты программы больше не доступен! Работа программы завершена."
В логах:
NETHASP_LASTSTATUS(,prog=17,ser=ORGL8,,,,)->NStat=0,SysErr=0,stat=0,'
54:43.776000-0,EXCP,2,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=475df7fb-d939-4c96-9876-566be5a134cf,Descr='src\CleanMemoryImpl.cpp(226):
475df7fb-d939-4c96-9876-566be5a134cf: Ключ защиты программы больше не доступен! Работа программы завершена.'
54:47.698008-0,EXCP,2,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=475df7fb-d939-4c96-9876-566be5a134cf,Descr='src\CleanMemoryImpl.cpp(226):
475df7fb-d939-4c96-9876-566be5a134cf: Ключ защиты программы больше не доступен! Работа программы завершена.'
55:11.354000-0,EXCP,2,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=475df7fb-d939-4c96-9876-566be5a134cf,Descr='src\DBUpdaterImpl.cpp(1697):
475df7fb-d939-4c96-9876-566be5a134cf: Ключ защиты программы больше не доступен! Работа программы завершена.'
55:13.479003-1,HASP,0,process=1cv8,OSThread=3164,Txt='NETHASP_L OGOUT(,prog=17,ser=ORGL8,,,,)->,,,'
55:13.479005-1,HASP,0,process=1cv8,OSThread=3164,Txt='NETHASP_L ASTSTATUS(,prog=17,ser=ORGL8,,,,)->NStat=0,SysErr=0,stat=0,'
55:13.479007-0,EXCP,0,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=HASP has been lost!

Причем это во всех конфигурациях, даже маленькой и самописной. На платформе 8.3.13.1513 + rbc_ipc обновляет на ура."


У чела в техн.журнал упала строка "Exception=HASP has been lost!", она встречается только в теле толстого клиента (смотрел с 8.3.12 по 8.3.15).
Вообщем причины KEYWASLOST пока очень неясены.

[yhm57878@cndps]

Так я не лечил, с оффа взято. А я только обрадовался, что сегодня настроил хасп, можно смело на линукс с винды переходить)

[HPDX2300]

Так я не лечил, с оффа взято. А я только обрадовался, что сегодня настроил хасп, можно смело на линукс с винды переходить)

как следует из поста выше твоего - крах KEYWASLOST ты легко можешь получить и на винде.

[vfp7]

На сервере сработало обновление по безопасности и обновилось ядро, если кто не знает про этот момент с обновлениями то обратите внимание на эти два файла:
sudo nano /etc/apt/apt.conf.d/20auto-upgrades
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Итак, перекомпиляция на Ubuntu 18.04.2:
/ Глобальную смену ядра пока не затрагиваю, так как еще не проверенно. После проверки подготовлю универсальный скрипт, а пока ручками под контролем /

..
cd ~/vhci-hcd-1.15
sudo make KVERSION=$(uname -r) KSRC=/usr/src/linux-source-4.15.0
sudo make install
cd ~/libusb_vhci-0.7
./configure
make
sudo make install
..

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

[HPDX2300]

пример кода на асме - замер времени выполнения куска кода

снимок (кликни меня)
backbas.timeout.asm.png

код	комментарий
call edi	; это 2-й вызов core::get_milliseconds(void)
mov ecx, eax	; сохраним результат вызова get_milliseconds в регистр ECX
sub ecx, [esi+40h]	; вычтем из него результат предыдущего вызова get_milliseconds
cmp ecx, 7D0h	; разницу сравним с 0x07D0 = 2000 т.е. 2сек.
jb short loc_1ADBCD94	; условный переход по результату сравнения (если...то...)

[HPDX2300]

> когда "1 сек" решит прекратит использование HASP-ключей.

и такой вариант развития предусмотрен ... незачем опережать события ...
ps: хотя "правильный" дистрибутив для linux x64 был бы приятен

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