Загруженный glib c базовый адрес отличается для каждой функции - PullRequest
0 голосов
/ 01 мая 2020

Я пытаюсь вычислить базовый адрес библиотеки двоичного файла. У меня есть адрес printf, помещает e cc и затем я вычитаю его смещение, чтобы получить базовый адрес библиотеки. Я делал это для printf, put и signal, но каждый раз получал новый базовый адрес. Я также попытался сделать то, что написано в этом сообщении, но я также не смог получить правильный результат.

ASLR отключен.

здесь я беру адрес библиотечной функции:

gdb-peda$ x/20wx 0x804b018
0x804b018 <signal@got.plt>:     0xf7e05720      0xf7e97010      0x080484e6      0x080484f6
0x804b028 <puts@got.plt>:       0xf7e3fb40      0x08048516      0x08048526      0xf7df0d90
0x804b038 <memset@got.plt>:     0xf7f18730      0x08048556      0x08048566      0x00000000

тогда у меня:

gdb-peda$ info proc mapping
process 114562
Mapped address spaces:

        Start Addr   End Addr       Size     Offset objfile
         0x8048000  0x804a000     0x2000        0x0 /home/ofey/CTF/Pwnable.tw/applestore/applestore
         0x804a000  0x804b000     0x1000     0x1000 /home/ofey/CTF/Pwnable.tw/applestore/applestore
         0x804b000  0x804c000     0x1000     0x2000 /home/ofey/CTF/Pwnable.tw/applestore/applestore
         0x804c000  0x806e000    0x22000        0x0 [heap]
        0xf7dd8000 0xf7fad000   0x1d5000        0x0 /lib/i386-linux-gnu/libc-2.27.so
        0xf7fad000 0xf7fae000     0x1000   0x1d5000 /lib/i386-linux-gnu/libc-2.27.so
        0xf7fae000 0xf7fb0000     0x2000   0x1d5000 /lib/i386-linux-gnu/libc-2.27.so
        0xf7fb0000 0xf7fb1000     0x1000   0x1d7000 /lib/i386-linux-gnu/libc-2.27.so
        0xf7fb1000 0xf7fb4000     0x3000        0x0
        0xf7fd0000 0xf7fd2000     0x2000        0x0
        0xf7fd2000 0xf7fd5000     0x3000        0x0 [vvar]
        0xf7fd5000 0xf7fd6000     0x1000        0x0 [vdso]
        0xf7fd6000 0xf7ffc000    0x26000        0x0 /lib/i386-linux-gnu/ld-2.27.so
        0xf7ffc000 0xf7ffd000     0x1000    0x25000 /lib/i386-linux-gnu/ld-2.27.so
        0xf7ffd000 0xf7ffe000     0x1000    0x26000 /lib/i386-linux-gnu/ld-2.27.so
        0xfffdd000 0xffffe000    0x21000        0x0 [stack]

и:

gdb-peda$ info sharedlibrary
From        To          Syms Read   Shared Object Library
0xf7fd6ab0  0xf7ff17fb  Yes         /lib/ld-linux.so.2
0xf7df0610  0xf7f3d386  Yes         /lib/i386-linux-gnu/libc.so.6

Затем я нашел смещение сигнала и положил для расчета базовый адрес lib c.

base_with_signal_offset = 0xf7e05720 - 0x3eda0 =  0xf7dc6980
base_with_puts_offset = 0xf7e3fb40 - 0x809c0 = 0xf7dbf180

Я ожидал base_with_signal_offset = base_with_puts_offset = 0xf7dd8000, но это не так. Что я делаю не так? РЕДАКТИРОВАТЬ (чтобы вы поняли, где я получил эти смещения):

readelf -s /lib/x86_64-linux-gnu/libc-2.27.so  | grep puts

Я получаю:

    191: 00000000000809c0   512 FUNC    GLOBAL DEFAULT   13 _IO_puts@@GLIBC_2.2.5
   422: 00000000000809c0   512 FUNC    WEAK   DEFAULT   13 puts@@GLIBC_2.2.5
   496: 00000000001266c0  1240 FUNC    GLOBAL DEFAULT   13 putspent@@GLIBC_2.2.5
   678: 00000000001285d0   750 FUNC    GLOBAL DEFAULT   13 putsgent@@GLIBC_2.10
  1141: 000000000007f1f0   396 FUNC    WEAK   DEFAULT   13 fputs@@GLIBC_2.2.5
  1677: 000000000007f1f0   396 FUNC    GLOBAL DEFAULT   13 _IO_fputs@@GLIBC_2.2.5
  2310: 000000000008a640   143 FUNC    WEAK   DEFAULT   13 fputs_unlocked@@GLIBC_2.2.5

1 Ответ

1 голос
/ 01 мая 2020

Я ожидал, что base_with_signal_offset = base_with_puts_offset = 0xf7dd8000

В ваших вычислениях есть 3 числа:

&puts_at_runtime - symbol_value_from_readelf == &first_executable_pt_load_segment_libc.

Вывод readelf показывает, что вы получили один из них почти правильно: значение puts в 64-битном /lib/x86_64-linux-gnu/libc-2.27.so действительно 0x809c0, но это , а не библиотека, которую вы фактически используете. Вам нужно повторить то же самое для фактически используемой 32-битной библиотеки: /lib/i386-linux-gnu/libc-2.27.so.

Для первого числа - & put_at_runtime вы используете значение из заглушки импорта puts@got.plt , Это значение гарантированно будет разрешено только (указывают на фактическое значение puts в libc.so), если у вас установлено LD_BIND_NOW=1 в среде, или вы связали свой исполняемый файл с флагом компоновщика -z now, или вы фактически вызвали puts уже.

Может быть лучше print &puts в ГБД.

Последний номер - & first_executable_pt_load_segment_lib c правильный (потому что info shared показывает, что libc.so.6 .text раздел начинается с 0xf7df0610, который находится между 0xf7dd8000 и 0xf7fad000.

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

В моей системе:

#include <signal.h>
#include <stdio.h>
int main() {
  puts("Hello");
  signal(SIGINT, SIG_IGN);
  return 0;
}
gcc -m32 t.c  -fno-pie -no-pie
gdb -q a.out
... set breakpoint on exit from main
Breakpoint 1, 0x080491ae in main ()
(gdb) p &puts
$1 = (<text variable, no debug info> *) 0xf7e31300 <puts>
(gdb) p &signal
$2 = (<text variable, no debug info> *) 0xf7df7d20 <ssignal>
(gdb) info proc map
process 114065
Mapped address spaces:

    Start Addr   End Addr       Size     Offset objfile
     0x8048000  0x8049000     0x1000        0x0 /tmp/a.out
     ...
     0x804d000  0x806f000    0x22000        0x0 [heap]
    0xf7dc5000 0xf7de2000    0x1d000        0x0 /lib/i386-linux-gnu/libc-2.29.so
    ...
(gdb) info shared
From        To          Syms Read   Shared Object Library
0xf7fd5090  0xf7ff0553  Yes (*)     /lib/ld-linux.so.2
0xf7de20e0  0xf7f2b8d6  Yes (*)     /lib/i386-linux-gnu/libc.so.6

Учитывая вышеизложенное, мы ожидаем, что readelf -s даст нам 0xf7e31300 - 0xf7dc5000 == 0x6c300 для puts и 0xf7df7d20 - 0xf7dc5000 == 0x32d20 для signal соответственно.

readelf -Ws /lib/i386-linux-gnu/libc-2.29.so | egrep ' (puts|signal)\W'
   452: 00032d20    68 FUNC    WEAK   DEFAULT   14 signal@@GLIBC_2.0
   458: 0006c300   400 FUNC    WEAK   DEFAULT   14 puts@@GLIBC_2.0

КЭД.

...