Чё-то тема замерла.
Даю "волшебный пендаль" для оживления.
В этой теме делились своими знаниями грамотные программисты - закончился этап доведения до рабочего состояния 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 хоть и названы одинаково, но это разной разрядности загрузчики.
Чтобы не часто заниматься сборкой/отладкой надо продумать вопрос - как сообщать загрузчику инфу "в какой либе чё искать и чем заменять", полагаю это может быть текстовый файл где-нибудь в файловой системе.