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

[SDom]

Всем привет! Делюсь своим опытом и мнением. Имею 2 сервера, где стояла версия 1С 8.3.22.1604:
1. Linux CentOS 7 - на нем стоит PostgreSQL + сервер 1С + Web сервер + HASP (сервер 64, сервер 32, 50 раб мест)
2. Windows 2016 - терминальный сервер
15.11.22 утром смартфон перегревается от звонков и вибрации - все жалуются, работа 1С стоит, "Система 1С взломана, являемся жертвой мошенников" и т.д. Требуется поставить платформу 8.3.22.1704
На Linux сервере установлен виртуальный HASP, скомпилированный самостоятельно из vhci-hcd-1.15, libusb_vhci-0.7, UsbHasp, а также установлен HASP драйвер haspd-7.90-eter2centos и его модули haspd-modules-7.90-eter2centos... Сервер 1С 8.3.22 определяет ключи как не лицензионные и везде блочит базы, которые пытаемся открыть. Чешу репу и думаю по-пробовать поставить другой драйвер и эмулятор - успешно скомпилировал из vhci-hcd-1.15, libusb_vhci-0.8, UsbHasp, а также установлен другой HASP драйвер haspd-8.23-eter3centos. В итоге ключи lsusb показал, а 8.3.22 их посчитал как не лицензионные и везде блочит базы... Пробую поменять HASP драйвер на Sentinel_LDK_RedHat aksusbd-7.81, где в итоге ключи lsusb показал, а 1С все равно считает их не лицензионными. Сделан вывод - 1С 8.3.22 научен определять эмулятор.

1. Приходит первая мысль поставить ключи на Windows сервере, установить там HASPLM (менеджер лицензий), открыть порт 475 UDP и раздать их локально на терминальный сервер и Linux сервер 1С. При этом хочу заметить, что сервер 1С настроен на выдачу ключей тонким и web клиентом самим сервером, а не локальными машинами. В процессе установки ключей на Windows пришлось потрудиться с зачисткой от старых драйверов и записей в реестре ..1С 8.3.22 их моментально определяет и блочит базы. Удалось поставить Emuls4Windows_x86-x64_refresh2e с дампами MuKeyDrv и раздать их для сервера Linux. В итоге получилось, что все ключи видны, а серверный нет. Web клиент запустить не удается и сообщается об отсутствии лицензии, тонкий клиент запускается без проблем, но с ограничением количества 10 сессий... Не исключаю, что службы 1С своими сессиями также входят в список, т.к. регулярно поступала жалоба о пропадании лицензии.. как только пользователи набирали массу сессий выше 10 сразу все работало нестабильно у ВСЕХ. Основной вывод - сетевой ключ не передается через HASPLM. Так-же возникли постоянные сбои в работе конфигуратора и начало появляться сообщение о принудительном завершении сессии каким-то "Администратором". Видимо сам 1С сервер стал выступать в лице "Администратора" :)))
Так-же выявилось, что происходит большая утечка информации из системы 1С в непонятные серверы, а потом выясняется, что это 1С контроль, Yandex, MAIL и т.д. - https://ufa-1c.ru/content/articles/a...url-ip-for-1c/

2. Приходит вторая мысль откатить версию платформы 1С до 8.3.21.1393. Это привело к тому, что рабочие базы открываться отказались, а в итоге вываливается инфа - "Ошибка формата потока". Спасло меня то, что сам являюсь писателем на разных языках, включая TSQL.
В итоге имею исходный материал: 1) База своей самописки с очень небольшим объемом метаданных которая не работает и выдает - "Ошибка формата потока", 2) Та-же самая база резервной копии, которую мне удалось успешно загрузить в новую пустую конфигурацию.
Открываю обе базы используя инструмент pgAdmin 4 v5 и начинаю сравнивать таблицы обоих баз данных запросом:

select * from config ORDER BY filename;

Замечаю в конфигурациях обоих баз 2 единственных расхождения в таблицах "config" и "params", которые можно увидеть запросами:

select * from config where filename = 'versions';
select * from params where filename = 'locale.inf';

В итоге вижу, что в неисправной базе в день запуска было внесено изменение в таблицу "config" в строку "versions" значение "datasize" = 9228, а в рабочей из backup версии значение стоит старое = 4448. Так-же в таблице "params" в нерабочей базе datasize = 120, а в рабочей datasize = 112.
Вношу изменения в строки неисправной базы. Значения беру из исправной базы

update config set datasize = 4448 where filename = 'versions';
update params set datasize = 112 where filename = 'locale.inf';

В итоге нерабочая база все равно не запускается и вываливается инфа - "Ошибка формата потока"
В неисправной базе в таблице "config" удаляю строку "versions"

delete from config where filename = 'versions';

И вуаля!! База открывается успешно, конфигурация успешно, выгрузка ведется без проблем.
Пока остановился на откате до версии 1С 8.3.21.1393 с добавлением расширений в базы для обновления и заблочил ряд IP адресов служб 1С
Всем удачи!

[vomad]

а серверный нет.

Серверный ключ нельзя отдать по сети, он обязан быть локальным. Его можно лишь пробросить на сервер через сторонний софт проброса USB-over-IP. Но популярный дамп этого ключа сейчас у 1С в черном списке. Вообще самое быстрое гарантированное решение - это покупка официального программного сервера x64. Либо ждать, пока умельцы сделают дамп "белого ключа".
Интересное наблюдение - у частников, мелких фирм, где стояли дампы мультикей однопользовательского ключа - их проблема не затронула ВООБЩЕ - как работали веб-клиентом до стороннего сервера, так и работают, при этом лицензию на запуск платформы берут из своего ключа... А вот дампы ключей сервера x64, ключа на 100, ключа на 500 - в черном списке.
Обе известные виртуалки (Windows XP с дампом ключа 100, pycelle с дампом сервера x64).
P.S. Кстати активировать ПРОГРАММНУЮ лицензию сейчас еше та проблема :)) Сервисы 1С наглухо лежат. Вторые сутки при активации пишет - нет интернета...

[warlomak]

Либо ждать, пока умельцы сделают дамп "белого ключа".

Дамп сделать не проблема, но ключ "белый" нужен, а его не даст никто в текущей ситуации... ИМХО...