Подключить свою библиотеку либо расширить секцию кода?

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

Как раз это и имею ввиду. Смотрю в текущей либе имеются и используюстя функции dlopen, dlsym, думаю это как раз то-что надо, только вот пока не писал никогда библиотеки, только небольшие программы под gcc (CodeBlock, Win, Ubuntu). В планах в свободное место текущей библиотеки, вставить код загрузки новой (пока не существ.), дальше вопрос - как использовать функции, аргументы и параметры из новой библиотеки. да и вообще много вопросов.

если функция прописана в таблице символов, то ставишь размер и адрес 0 в ELF, и она будет искаться в других загруженных либах

Пропатчить можно всё. Разберись как устроен формат .so, там вроде ничего сложного. Если секция кода в начале или в конце (по памяти) то её легко просто расширить (добавив байты в начало или в конец, чтобы смещения до данных не сбились), если в середине - думаю можно ещё одну исполняемую секцию с краю создать.

Если что, устройство .so ни разу не изучал, всё что выше - из общих соображений.

Так же как и любые другие функции. Для большинства современных архитектур и соглашений о вызовах - посредством инструкции call или её аналога.

Уже не первый день читаю, изучаю. Секция с кодом(. text) находится в середине, не получится ее расширить, я не смог по крайней мере, поэтому тут и спросил, кое какие данные добавил в секцию .rodara, пока работает, но больше не добавить туда. Пока изучаю как либы создавать на примерах

И кстати пытался добавить еще одну секцию с кодом, с помощью objcopy, она записалась и сдвинулось все остальное, видимо objcopy не умеет работать с такими данными, может я править не умею, но вариант со сторонней библиотекой вроде нравится.

Спасибо за отзывы

Куда сдвинулось? Как добавление секции с краю может что-то сдвинуть?

Он не то что сдвинул, после применения objcopy, он записал мою секцию кода поверх секций .symtab .strtab, попутно затер нулями такие как .data .bss что-то в этом роде.

Даже не стал проверять этот файл в работе, так как больше половины символов превратил в 00, на тот момент я и подумал что утилита работает только с объектными файлами, т.е. с кодом, могу ошибаться.

Добавлял таким методом: objcopy --add-section .sect=77.bin \ --set-section-flags .sect=code,contents,alloc,load,readonly \ lib.so newlib.so.

Плюс к этому выходной файл стал почти на 30Kb больше, хотя добавил всего 100 байт (для проверки)

Если подскажете как сделать правильно, буду благодарен, и не только на словах.

С Shared Library тоже пока не особо получается

Ну, я повторю, не изучал формат .so файлов, но скорее всего стал бы делать не через objcopy а вручную посмотрел его заголовки и подправил бы там нужные поля - тогда никаких непоняток с добавившимися 30кб или затёртыми данными не было бы. С виндовым PE такое вполне прокатывало давно.

Также как и вы стал сравнивать заголовки обеих файлов, хотел сравнить что изменилось. Думал в ручную добавить секцию.

Но изменения были только в трёх байтах, readelf показал что добавилась секция, вроде всё. Может конечно можно руками прописать, попробую еще почитать устройство elf.

Три байта это явно мало для метаданных секции - у неё как минимум размер и смещение (а скорее два - в файле и в памяти), и какие-нить флаги, всё по 4 байта, итого 12-16 байт минимум. А скорее больше.

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

Зачем динамическую? Элемент NEEDED в секцию .dynamic добавить куда проще. Есть даже command-line тулза.

А, ну да, или LD_PRELOAD.

Нашел как править и создавать свои секции. Создал секцию кода в конце библиотеки, занес туда некоторый код, сделал ссылку на него из оригинальной секции кода, в IDA все вроде нормально, запускаю отладчик и при переходе по ссылке -SegmentFault, и показывает что это секция BSS(Не иницилизированые данные), в общем убавил размер .BSS в таблице секций, снова в IDA все хорошо, а во время отладки Тоже-самое, видимо не только эта либа, но видимо и другие загружают свой .BSS сегмент по этому адресу, в общем пока не вижу выхода как «клепать» новую SO.

ld_preload https://habr.com/ru/post/199090/

Добавь в начало. BSS не надо убавлять, это переменные.

В начало - всмысле сдвинь всё вперёд (на одинаковое количество байт в памяти) и на освободившееся место сделай новую секцию. В .so должен быть PIC-код, который от таких сдвигов не ломается. Не знаю бывают ли там relocations (динамические патчи для не-PIC кода) если бывают то их тоже придётся пропатчить.

Спасибо всем, позже попробую эти варианты.

Подскажите, попробовал скомпилировать небольшой кусок кода в SO, получается не правильно видимо, так как IDA ругается:

This file contains non standart usage of relocations,

и почему-то нет разницы в выходном out.o файле, что так arm-none-eabi-gcc -fpic -c function.c, что без ключа -fPIC. По мануалам в сети - должна быть разница, пробую собирать так:

arm-none-eabi-gcc -fpic -c function.c

arm-none-eabi-gcc -shared -o function.so function.o

(откуда-то появляются «левые» функции: _start, bss_start, .init_proc, .term_proc )

Да как раз столкнулся с этим во время чтения манулов по компиляции коа для SHARED SO, используется ключ PIC (позиционно не зависимый) Попробую сегодня в начало вставить, посмотрю какие секции перед секцией . text

В динамических ELF код не в секциях, а в сегментах. Если нет свободного места в Program Headers, можно попробовать завести свой исполняемый сегмент вместо GNU_STACK или другого пустого незагружаемого сегмента.

Но лучше не править бинарник, а попытаться управлять процессом динамической загрузки и связывания.

readelf -l /bin/sh

Elf file type is DYN (Shared object file)
Entry point 0x5cd0
There are 13 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x00000000000002d8 0x00000000000002d8  R      0x8
  INTERP         0x0000000000000318 0x0000000000000318 0x0000000000000318
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000004360 0x0000000000004360  R      0x1000
  LOAD           0x0000000000005000 0x0000000000005000 0x0000000000005000
                 0x00000000000127f5 0x00000000000127f5  R E    0x1000
  LOAD           0x0000000000018000 0x0000000000018000 0x0000000000018000
                 0x00000000000058f0 0x00000000000058f0  R      0x1000
  LOAD           0x000000000001df30 0x000000000001ef30 0x000000000001ef30
                 0x0000000000001310 0x0000000000003f40  RW     0x1000
  DYNAMIC        0x000000000001eb08 0x000000000001fb08 0x000000000001fb08
                 0x00000000000001f0 0x00000000000001f0  RW     0x8
  NOTE           0x0000000000000338 0x0000000000000338 0x0000000000000338
                 0x0000000000000020 0x0000000000000020  R      0x8
  NOTE           0x0000000000000358 0x0000000000000358 0x0000000000000358
                 0x0000000000000044 0x0000000000000044  R      0x4
  GNU_PROPERTY   0x0000000000000338 0x0000000000000338 0x0000000000000338
                 0x0000000000000020 0x0000000000000020  R      0x8
  GNU_EH_FRAME   0x0000000000019f44 0x0000000000019f44 0x0000000000019f44
                 0x0000000000000804 0x0000000000000804  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10

Если через IDA правил, то она не применяет патчи ELF, только к коду/данным. Тоже с этим сталкивался, когда надо было завернуть внутрь либы функции, которых нет в libc - пришлось писать патчер.

Правил с помощью IDA PRO, после применения правок(поменял пару функций на свои), файл хорошо работает по сей день.

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

«has unexpected e_type»

Readelf показывает тип библиотеки: REL (Relocation), а надо такой тип: DYN (Shared object file)

Как собрать такой тип не могу понять. При компиляции использую ключи: -fPIC, shared

Скорее всего и ошибка открытия(загрузки), когда пытаюсь загрузить её из по андроид.

readelf -l - показывает НОЛЬ программных сегментов

readelf -S - показывает 10 секций (text, data, bss, symtab, strtab и т.д.)

DYN и EXEC( статические ) из REL собирают компоновщики, такие как ld

Все верно, нашёл у себя небольшой «косяк», компилировал с ключём ‘-c’, убрал его, теперь все хорошо, либа создаётся и загружается в память.

Увеличение основой библиотеки пока не стал проверять.