универсальный патчер памяти процесса для линукса

[HPDX2300]

создал отдельную тему, чтобы написанное в теме "как ломануть 1C 8.3 for Linux" не захламлялось пустяковыми постами. все значимые посты будут скопированы здесь, их обсуждение можно продолжать в теме "как ломануть 1C 8.3 for Linux" Тема "патчера памяти процесса" оч.перспективна для изготовления таблеток от жадности, и те, кто умеет пользоваться линуксовыми дебагерами, знают, что системные библиотеки делают такой патчинг при каждом запуске процесса, желающие узнать "о чём это я намекаю?" ищите в поисковике "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]

В линуксе есть возможность доустановить для любого пакета его отладочную информацию. Я проделал это с glibc, чтобы появились файлы с debug-инфой для загрузчика /usr/lib64/ld-2.17.so

на снимке МС в правой панели рядом с /usr/lib64/ld-2.17.so появилась ссылка на ld-2.17.so.debug,
а левая панель МС открыта в папке реального расположения файлов .debug

документация и сам загрузчик сообщают, что его можно запускать, указав в качестве параметра имя файла приложения.
вот я запускаю загрузчик в терминале:

[user@hostname lib64]$ ./ld-2.17.so 
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
			object we can handle
  --inhibit-cache       Do not use /etc/ld.so.cache
  --library-path PATH   use given PATH instead of content of the environment
			variable LD_LIBRARY_PATH
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
			in LIST
  --audit LIST          use objects named in LIST as auditors

хочу отлаживать в дебагере процесс загрузки толстого клиента для примера:

/usr/lib64/ld-2.17.so  /opt/1cv8/x86_64/8.3.25.1374/1cv8

потренируюсь на оригинальном ld-2.17.so, в дальнейшем я буду отлаживать пересобранный загрузчик.

IDA-free-8.4 не захотела начать отладку ld-2.17.so, выругалась:
Input file is a dynamic library, it cannot be run by itself.
Please specify the host application (Debugger, Process options)

в файле ida64 сделал исправление (patch) {0F 85 -> 90 E9}:
offset:19D90B: 0F 85 5D FC FF FF jnz -0x3A3 ; HACK: jnz -> jmp {0F 85 -> 90 E9} to debug ld.so

либа /usr/lib64/ld-2.17.so скопирована с именем /usr/lib64/_my_ld т.к. почти наверняка я захочу её патчить в процессе изучения, ida64 пропатчена, согласилась выполнять отладку /usr/lib64/_my_ld
в меню "Debugger" -> "Process options..." указан параметр процесса Parameters: /opt/1cv8/x86_64/8.3.25.1374/1cv8

установленная отладочная информация для библиотек glibc, в отладчике проявляет себя именами функций, типами параметров и локальных переменных, структурами с именами полей:



наиболее интересные для изучения функции:
ld.so:_dl_open
libc.so:__mprotect