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

[HPDX2300]

после редактирования первого поста ему пришел пипец - всё в одну строку.
повторяю его с дополнениями:

Пока изучал в дебагере "Relocation Processing", дошел до идеи допилить либу /lib/ld-linux.so.2 (это ссылка на /lib/ld-2.17.so) до "патчера памяти процесса".

Начните с экспериментов "в песочнице" - в вирт.машине установите любимый линукс, доустановите debug-символы и исходники для пакета glibc (репозитории Debuginfo, Sources), установите дебагер IDA-free-7.6 (более новый не советую, но это на ваше усмотрение).

Запустив дебагер IDA, в меню "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).

Включаем в меню "Debugger" -> "Use source-level debugging", если вы доустановили исходники glibc.

Жмём F9 для продолжения выполнения процесса. Когда дебагер остановится при наступлении события "LIB_LOADED", то в окне "Module list" во второй строке сверху будет написано имя файла либы, с которой сейчас работает загрузчик ld-linux-x86-64.so.2



снимок сделан в момент динамической загрузки первого модуля - xml2.so, либа ещё не очончательно загружена - смотрите в окно исходного кода - IDA остановился внутри функции dl_open_worker в файле исходника dl-open.c на 301 строке.

фрагмент исходника dl-open.c с номерами строк:

227:  _dl_debug_initialize (0, args->nsid);
228:
229:  /* Load the named object.  */
230:  struct link_map *new;
231:  args->map = new = _dl_map_object (call_map, file, lt_loaded, 0,
232:                            mode | __RTLD_CALLMAP, args->nsid);
      полагаю _dl_map_object делает отображение (mapping) файла в виртуальную память процесса

267:  /* Load that object's dependencies. */
268:  _dl_map_object_deps (new, NULL, 0, 0,
269:                   mode & (__RTLD_DLOPEN | RTLD_DEEPBIND | __RTLD_AUDIT));
      полагаю _dl_map_object_deps читая заголовок ELF-файла, замаппит в память процесса статически слинкованные либы

297:  /* Notify the debugger all new objects are now ready to go.  */
298:  struct r_debug *r = _dl_debug_initialize (0, args->nsid);
299:  r->r_state = RT_CONSISTENT;
300:  _dl_debug_state ();
301:  LIBC_PROBE (map_complete, 3, args->nsid, r, new);

суть 4-х строк 298-301 - уведомить дебагер о том, что "all new objects are now ready to go",
в строке 301 "map_complete" подсказывает, что дебагер уведомляется о событии "mapping выполнен"

В либе xml2.so ещё не исправлены релоки (т.е. впереди будет патчинг памяти процесса в качестве примера) и не выполнен код инициализации библиотеки (секции .init и .init_array)

Полагаю, что удобный момент патчить память процесса - после "relocation processing", но до выполнения инициализации библиотеки (секции .init и .init_array). Релоки будут уже исправлены и мне не придется с ними бороться - мой код запишет новое поверх старого и оно уже не будет "исправляться".

после "mapping processing" начинается выполнение "relocation processing"

307:  /* Only do lazy relocation if `LD_BIND_NOW' is not set.  */
308:  int reloc_mode = mode & __RTLD_AUDIT;
309:  if (GLRO(dl_lazy))
310:    reloc_mode |= mode & RTLD_LAZY;

      // выполнен "mapping processing"

554:  /* Notify the debugger all new objects have been relocated.  */
555:  if (relocation_in_progress)
556:    LIBC_PROBE (reloc_complete, 3, args->nsid, r, new);

  // +++  вот тут я внедрю код исправления орфографических ошибок в приложении - набрали, блядь, неграмотных по объявлению

      // начинается выполнение "initializer functions"
558:  /* Run the initializer functions of new objects.  */
559:  _dl_init (new, args->argc, args->argv, args->env);

[HPDX2300]

заметил опечатку (давно пора спать) исправляю:

после "mapping processing" начинается выполнение "relocation processing"

307:  /* Only do lazy relocation if `LD_BIND_NOW' is not set.  */
308:  int reloc_mode = mode & __RTLD_AUDIT;
309:  if (GLRO(dl_lazy))
310:    reloc_mode |= mode & RTLD_LAZY;

выполнен "relocation processing"

554:  /* Notify the debugger all new objects have been relocated.  */
555:  if (relocation_in_progress)            ^^^^^^^^^^^^^^^^^^^
556:    LIBC_PROBE (reloc_complete, 3, args->nsid, r, new);
                    ^^^^^^^^^^^^^^
  вот тут я внедрю код исправления орфографических ошибок в приложении - набрали, блядь, неграмотных по объявлению

      // начинается выполнение "initializer functions"
558:  /* Run the initializer functions of new objects.  */
559:  _dl_init (new, args->argc, args->argv, args->env);

[HPDX2300]

>вот тут я внедрю код исправления орфографических ошибок в приложении
неудачный выбор, надо было пораньше лечь спать.
правильное место для добавления своего кода - конец процедуры _dl_relocate_object, подробности будут позже.

А сейчас покажу на примере backbas.so x86_64 ver.25-1374 покажу "почему в случае unpatch-x64 не пришлось бороться с релоками?"

после применения unpatch.py к backbas.so:
выхлоп:

patching  25-1374/backbas.so  at offset=0xc80370

зная размер блока unpatch-x64 получаем смещения в файле начала и конца унипатча:
0000000000C80370: begin of unipatch-x64
0000000000C82D77: end of unipatch-x64

посмотрим "Section Headers" насчет таблиц релоков

$ readelf -W -e backbas.so
выхлоп:
....
Section Headers:                                                   ES=Entry Size
 [Nr] Name              Type        Address          Off    Size   ES Flg Lk Inf Al
 [ 0]                   NULL        0000000000000000 000000 000000 00      0   0  0
 [ 1] .note.gnu.build-id NOTE       0000000000000270 000270 000018 00   A  0   0  4
 [ 2] .dynsym           DYNSYM      0000000000000288 000288 007878 18   A  6   1  8
 [ 3] .gnu.version      VERSYM      0000000000007b00 007b00 000a0a 02   A  2   0  2
 [ 4] .gnu.version_r    VERNEED     000000000000850c 00850c 000220 00   A  6   7  4
 [ 5] .gnu.hash         GNU_HASH    0000000000008730 008730 000714 00   A  2   0  8
 [ 6] .dynstr           STRTAB      0000000000008e44 008e44 00fd3f 00   A  0   0  1
 [ 7] .rela.dyn         RELA        0000000000018b88 018b88 117a80 18   A  2   0  8 <== таблица релоков (Size/ES=117a80h/18h=BA70h=47728 entries)
 [ 8] .rela.plt         RELA        0000000000130608 130608 005aa8 18  AI  2  25  8 <== таблица релоков (Size/ES=5aa8h/18h=3C7h=967 entries)
 [ 9] .gcc_except_table PROGBITS    00000000001360b0 1360b0 050690 00   A  0   0  4
 [10] .rodata           PROGBITS    0000000000186740 186740 46aa14 00 AMS  0   0 64
 [11] .eh_frame_hdr     PROGBITS    00000000005f1154 5f1154 031c84 00   A  0   0  4
 [12] .eh_frame         PROGBITS    0000000000622dd8 622dd8 1223b4 00   A  0   0  8
 [13] .text             PROGBITS    0000000000747000 746000 6F0A8A 00  AX  0   0 4096 <== unipatch-x64 там
 [14] .init             PROGBITS    0000000000E37A8C E36A8C 00001F 00  AX  0   0  4
 [15] .fini             PROGBITS    0000000000E37AAC E36AAC 000009 00  AX  0   0  4
 [16] .plt              PROGBITS    0000000000E37AC0 E36AC0 003C80 00  AX  0   0 16
 [17] .fini_array       FINI_ARRAY  0000000000E3C740 E3A740 000008 08  WA  0   0  8 <== первый релок там
 [18] .init_array       INIT_ARRAY  0000000000E3C748 E3A748 000650 00  WA  0   0  8 <== там основная масса релоков

посмотрим таблицу релоков:

$ readelf -W -r backbas.so
выхлоп:
Relocation section '.rela.dyn' at offset 0x18b88 contains 47728 entries:

    Offset             Info             Type
0000000000E3C740  0000000000000008 R_X86_64_RELATIVE
0000000000E3C748  0000000000000008 R_X86_64_RELATIVE
0000000000E3C750  0000000000000008 R_X86_64_RELATIVE
0000000000E3C758  0000000000000008 R_X86_64_RELATIVE
более 47000 записей пропущено для краткости

релоки применяются по смещению 0xE3C740 и далее, а код унипатча находится в файле с 0xC80370 по 0xC82D77
т.е. никакой релок не попадает в код HASP_API64 - удачное стечение обстоятельств.