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

[lacos1]

Приветствую. Пару лет назад пробовал. Прототип не особо понравился, не стал допиливать.

Опишу задачу, которую ставил перед собой и пытался решить.
У меня на руках были файлы установки платформы (deb/run) и постгреса (deb). Цель - собрать отдельные docker-образы для субд (postgresql), платформы (1c-enterprise) и веб-сервера (apache).
Ну и образ с лекарством - по задумке он должен был быть один, раздача лицензий серверу 1с происходить через сокет /tmp/.aksusb (иной вариант раздачи не рассматривался).

В целом, запустить задуманное оказалось не трудно, сервер 1с в изолированном контейнере был удовлетворен лицензиями от лекарства.
Нюансы:
1. для установки драйверов контейнеру требуется больше привилегий
2. из нюанса выше следует, что второй такой контейнер может и будет конфликтовать с первым, т.к. оба работают в пространстве ядра хостовой системы. также может начаться путаница, чьи ключи на каком эмулированном usb-устройстве висят из-за неопределенной очередности запуска таких контейнеров
3. два пакета, т.е. два сервиса, значит нужен промежуточный сервис, который будет крутить их внутри вместе, - я выбрал образ ubuntu с systemd
4. мне не удалось организовать точечный проброс сокет-файла /tmp/.aksusb из контейнера с лекарством контейнеру с сервером, поэтому сделал для них общий том /tmp
5. обновление хостовой системы приводило к неработоспособности контейнера с лекарством, т.к. внутри него требовалось выполнить установку пакета с файлами ядра соответствующей версии, чтобы драйвер с помощью dkms собрался

Итог: образы субд, платформы и веб-сервера получились хорошо. С лекарством, меня устраивало выполнить сборку на основе образа ubuntu с systemd и скриптами автоматизировать нюанс 5, но остальные (1,2,4) - не давали гибкости docker-контейнеров, и смысл терялся, проще на выделенной виртуалке. Так что решил с эмулятором не продолжать. В моем случае патч лучше решил задачу - образ чистого сервера 1с от пролеченного разделяет один слой.

[lacos1]

Сабжа никто не пробовал в docker сажать и оттуда ключи раздавать?

Приветствую. Пару лет назад пробовал. Прототип не особо понравился, не стал допиливать.

Опишу задачу, которую ставил перед собой и пытался решить.
У меня на руках были файлы установки платформы (deb/run) и постгреса (deb). Цель - собрать отдельные docker-образы для субд (postgresql), платформы (1c-enterprise) и веб-сервера (apache).
Ну и образ с лекарством - по задумке он должен был быть один, раздача лицензий серверу 1с происходить через сокет /tmp/.aksusb (иной вариант раздачи не рассматривался).

В целом, запустить задуманное оказалось не трудно, сервер 1с в изолированном контейнере был удовлетворен лицензиями от лекарства.
Нюансы:
1. для установки драйверов контейнеру требуется больше привилегий
2. из нюанса выше следует, что второй такой контейнер может и будет конфликтовать с первым, т.к. оба работают в пространстве ядра хостовой системы. также может начаться путаница, чьи ключи на каком эмулированном usb-устройстве висят из-за неопределенной очередности запуска таких контейнеров
3. два пакета, т.е. два сервиса, значит нужен промежуточный сервис, который будет крутить их внутри вместе, - я выбрал образ ubuntu с systemd
4. мне не удалось организовать точечный проброс сокет-файла /tmp/.aksusb из контейнера с лекарством контейнеру с сервером, поэтому сделал для них общий том /tmp
5. обновление хостовой системы приводило к неработоспособности контейнера с лекарством, т.к. внутри него требовалось выполнить установку пакета с файлами ядра соответствующей версии, чтобы драйвер с помощью dkms собрался

Итог: образы субд, платформы и веб-сервера получились хорошо. С лекарством, меня устраивало выполнить сборку на основе образа ubuntu с systemd и скриптами автоматизировать нюанс 5, но остальные (1,2,4) - не давали гибкости docker-контейнеров, и смысл терялся, проще на выделенной виртуалке. Так что решил с эмулятором не продолжать. В моем случае патч лучше решил задачу - образ чистого сервера 1с от пролеченного разделяет один слой.

[m491c]

Здравствуйте. А есть просто патч КОРП для Linux? Т.е. буду использовать настоящие программные лицензии ПРОФ, но есть необходимость в двух маленьких плюшках КОРП, это обновление с веб сервера и требование назначения функциональности, чтобы вынести на отдельные порты конфигуратор и толстого клиента.

[BeySoN]

Всем доброго времени суток! Мог бы кто пнуть в нужном направлении? Не где не могу найти пароль для архива. Кто может сказать или надо как-то заслужить (быть активным пользователем форума или создать темы или какое-то количество благодарностей и т.п.)?

[ilya.sh]

Всем доброго времени суток! Мог бы кто пнуть в нужном направлении? Не где не могу найти пароль для архива. Кто может сказать или надо как-то заслужить (быть активным пользователем форума или создать темы или какое-то количество благодарностей и т.п.)?

Стандартный пароль к архивам на форуме всегда один и тот же: ruboard.
Других паролей нет.

[HPDX2300]

Чё-то тема замерла.
Даю "волшебный пендаль" для оживления.
В этой теме делились своими знаниями грамотные программисты - закончился этап доведения до рабочего состояния hasp-эмулятора и все заскучали, а у меня ещё столько идей (некоторые я реализовал самостоятельно, но помолчу из скромности, да и не всё можно писать публично ибо написанное тут читается и изучается сектантами).
Для винды один чушкан, который "mimo унитаза сца ...", сваял поделку уни-длл - вся шобла влюбленных в винду пищит от радости (хотя этот же чушкан подсунул им малварь hpdx-lib).
На ру-борде ничё дельного не почитать в теме "аптека для ленивых" - сплошное нытьё типа "у меня не встаёт...чё мне делать-то?" (ему отвечают: используй правую руку вместо левой)

Тема "патчера памяти процесса" оч.перспективна для изготовления таблеток от жадности, и те, кто умеет пользоваться линуксовыми дебагерами, знают, что системные библиотеки делают такой патчинг при каждом запуске процесса, желающие узнать "о чём это я намекаю?" ищите в поисковике "Relocation Processing".
Все исходники линукса есть, есть хороший дебагер IDA (не без недостатков).

Хотел я проделать финт с 32-битным унипатчем (1С_UP.ехе) для линуксовой либы бэкбейс.so 32-бита разрядности, но пока ещё не нашел участок кода куда его впихнуть - там сильно мешают релоки, попадающие в тело унипатча, скрипт должен убирать несколько релоков, но его код становится от этого "чудесатее". Пока изучал в дебагере "Relocation Processing", дошел до идеи допилить либу /lib/ld-linux.so.2 (это ссылка на /lib/ld-2.17.so) до "патчера памяти процесса".

Начните с экспериментов "в песочнице" - в вирт.машине установите любимый линукс, пересоберите из исходников glibc с отладочной информацией, установите дебагер IDA-free-7.6 (более новый не советую, но это на ваше усмотрение).
В меню "Debugger" -> "Debugger options" включите 2-е галки "Suspend on debugging start" (или "Suspend on process entry point") и "Suspend on library load/unload"
Откройте модуль толстого клиента 1cv8, начните отладку, нажав F9, и выведите окно загруженных модулей процесса - меню "Debugger" -> "Debugger windows" -> "Module list".
В окне "Module list" на первой строке вверху написано имя файла запускаемого приложения (1cv8).
Жмём F9 для продолжения выполнения процесса, когда дебагер остановится при наступлении события "LIB_LOADED", то в окне "Module list" во второй строке сверху будет написано имя файла только что загруженной либы, но ещё не очончательно загруженной - смотрите в окно исполняемого кода - IDA остановился внутри функции dl_open_worker в либе ld_2.17.so, ещё не исправлены релоки (т.е. впереди будет патчинг памяти процесса в качестве примера) и не выполнен код инициализации библиотеки (секции .init и .init_array), вот удобный момент патчить память процесса - для этого вам придется дописать код glibc (а именно код загрузчика в некоторых файлах dl-*.с в папке elf). После сборки можно не выполнять make install, а проверить в дебагере работу нового загрузчика.
Проверять в отладчике, отлаживая процесс загрузчика с параметром:
32-битный загрузчик ld-2.17.so /opt/1cv8/i386/8.3.25.1445/1cv8
или 64-битный загрузчик ld-2.17.so /opt/1cv8/х86_64/8.3.25.1445/1cv8
после make install создаются ссылки на файлы загрузчиков
/lib/ld-linux.so.2 -> /lib/ld-2.17.so
/lib64/ld-linux-x86-64.so.2 -> /lib64/ld-2.17.so
либы ld-2.17.so хоть и названы одинаково, но это разной разрядности загрузчики.
Чтобы не часто заниматься сборкой/отладкой надо продумать вопрос - как сообщать загрузчику инфу "в какой либе чё искать и чем заменять", полагаю это может быть текстовый файл где-нибудь в файловой системе.

[HPDX2300]

... установите дебагер IDA-free-7.6 (более новый не советую, но это на ваше усмотрение)...

в IDA-free-8.4 есть приятная опция дебагера "Disable ASLR" - адреса загрузки модулей в памяти процесса не будут меняться при перезапуске процесса, но и без этой опции точки останова в либах можно делать сохраняемыми - просто включайте им галку "Module relative" и они будут работать, даже если изменился базовый адрес загрузки модуля в память

[HPDX2300]

подробности в отдельной теме, вопросы/обсуждение лучше прямо тут (в ЛС тока конфиденциально, т.е. то, что не должны прочесть сектанты)