每个函数加载的glibc基地址不同。

问题描述 投票:0回答:1

我试图计算一个二进制文件的库的基地址.我有printf,putes ecc的地址,然后我减去它的偏移量,得到库的基地址.我对printf,putes和signal这样做,但每次我得到的基地址都不一样。这个 帖子,但我也无法得到正确的结果。

ASLR被禁用。

这是我取函数库地址的地方。

gdb-peda$ x/20wx 0x804b018
0x804b018 <[email protected]>:     0xf7e05720      0xf7e97010      0x080484e6      0x080484f6
0x804b028 <[email protected]>:       0xf7e3fb40      0x08048516      0x08048526      0xf7df0d90
0x804b038 <[email protected]>:     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

然后我找到了信号的偏移量和put来计算基础libc地址。

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

我期待的是 base_with_signal_offset = base_with_puts_offset = 0xf7dd8000但事实并非如此,我做错了什么?EDIT(为了让你明白我从哪里得到这些偏移量)。

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
linux reverse-engineering glibc dynamic-linking
1个回答
1
投票

我期望base_with_signal_offset = base_with_puts_offset = 0xf7dd8000。

在你的计算中,有三个数字。

&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.

对于第一个数字 -- &puts_at_runtime,你使用的是来自于 [email protected] 导入存根。该值只能保证已被解析(指向实际的 putslibc.so)如果你有 LD_BIND_NOW=1 环境中的设置,或者您将您的可执行文件与 -z now 链接器标志,或者说你居然叫 puts 已经。

也许最好是 print &puts 在GDB中,最后一个数字--&first_executable_pt_load_segment_libc是正确的。

最后一个数字--&first_executable_pt_load_segment_libc是正确的(因为 info shared 显示 libc.so.6 .text 节起 0xf7df0610,介于 0xf7dd80000xf7fad000.

所以综合来看,唯一的错误就是你用错了版本的 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 对于 puts0xf7df7d20 - 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

QED。

© www.soinside.com 2019 - 2024. All rights reserved.