Question

我想验证运行程序时使用的动态链接器是否是通过 file、readelf -l 或 ldd 提及的那个。我的动机源于在机器上的不同空间中存在多个动态链接器，它们不应该混合和匹配。

到目前为止，我发现验证动态链接器的最佳方法是通过 gdb。通过查看 info proc mappings 的输出，我可以确定哪个动态链接器被映射到地址空间并正在使用。我尽量避免使用 gdb，因为它需要我通过它运行测试套件和其他东西。

使用 LD_DEBUG 环境变量似乎是一种替代解决方案，它允许我在程序执行之后（或期间）轻松保存日志以进行验证。但是，我不确定哪个选项会给我最好的信息。我认为 scopes 或 libs 可能是不错的选择，但 libs 并不总是提到动态链接器。例如，这是一个简单的 hello world 程序的输出：

$ LD_DEBUG=libs ./test0
     24579: find library=libc.so.6 [0]; searching
     24579:  search cache=/etc/ld.so.cache
     24579:   trying file=/lib/x86_64-linux-gnu/libc.so.6
     24579:
     24579:
     24579: calling init: /lib/x86_64-linux-gnu/libc.so.6
     24579:
     24579:
     24579: initialize program: ./test0
     24579:
     24579:
     24579: transferring control: ./test0
     24579:
hello world
     24579:
     24579: calling fini: ./test0 [0]
     24579:
$ LD_DEBUG=libs ./test0-gnu-cross
     24581: find library=libc.so.6 [0]; searching
     24581:  search path=/usr/local/gnu-cross/x86_64-linux-gnu/lib/glibc-hwcaps/x86-64-v4:/usr/local/gnu-cross/x86_64-linux-gnu/lib/glibc-hwcaps/x86-64-v3:/usr/local/gnu-cross/x86_64-linux-gnu/lib/glibc-hwcaps/x86-64-v2:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell/avx512_1/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell/avx512_1:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/avx512_1/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/avx512_1:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls:/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell/avx512_1/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell/avx512_1:/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell:/usr/local/gnu-cross/x86_64-linux-gnu/lib/avx512_1/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib/avx512_1:/usr/local/gnu-cross/x86_64-linux-gnu/lib/x86_64:/usr/local/gnu-cross/x86_64-linux-gnu/lib     (RPATH from file ./test0-gnu-cross)
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/glibc-hwcaps/x86-64-v4/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/glibc-hwcaps/x86-64-v3/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/glibc-hwcaps/x86-64-v2/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell/avx512_1/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell/avx512_1/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/haswell/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/avx512_1/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/avx512_1/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/tls/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell/avx512_1/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell/avx512_1/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/haswell/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/avx512_1/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/avx512_1/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/x86_64/libc.so.6
     24581:   trying file=/usr/local/gnu-cross/x86_64-linux-gnu/lib/libc.so.6
     24581:
     24581:
     24581: calling init: /usr/local/gnu-cross/x86_64-linux-gnu/lib/ld-linux-x86-64.so.2
     24581:
     24581:
     24581: calling init: /usr/local/gnu-cross/x86_64-linux-gnu/lib/libc.so.6
     24581:
     24581:
     24581: initialize program: ./test0-gnu-cross
     24581:
     24581:
     24581: transferring control: ./test0-gnu-cross
     24581:
hello world
     24581:
     24581: calling fini: ./test0-gnu-cross [0]
     24581:

如您所见，使用标准 Debian/GNU 工具链构建并使用系统动态链接器的程序 test0 并未说明这一点。

scopes 选项看起来更有帮助，但我不明白输出在说什么：

$ LD_DEBUG=scopes ./test0
     24577:
     24577: Initial object scopes
     24577: object=./test0 [0]
     24577:  scope 0: ./test0 /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
     24577:
     24577: object=linux-vdso.so.1 [0]
     24577:  scope 0: ./test0 /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
     24577:  scope 1: linux-vdso.so.1
     24577:
     24577: object=/lib/x86_64-linux-gnu/libc.so.6 [0]
     24577:  scope 0: ./test0 /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
     24577:
     24577: object=/lib64/ld-linux-x86-64.so.2 [0]
     24577:  no scope
     24577:
hello world
$ LD_DEBUG=scopes ./test0-gnu-cross
     24576:
     24576: Initial object scopes
     24576: object=./test0-gnu-cross [0]
     24576:  scope 0: ./test0-gnu-cross /usr/local/gnu-cross/x86_64-linux-gnu/lib/libc.so.6 /usr/local/gnu-cross/x86_64-linux-gnu/lib/ld-linux-x86-64.so.2
     24576:
     24576: object=linux-vdso.so.1 [0]
     24576:  scope 0: ./test0-gnu-cross /usr/local/gnu-cross/x86_64-linux-gnu/lib/libc.so.6 /usr/local/gnu-cross/x86_64-linux-gnu/lib/ld-linux-x86-64.so.2
     24576:  scope 1: linux-vdso.so.1
     24576:
     24576: object=/usr/local/gnu-cross/x86_64-linux-gnu/lib/libc.so.6 [0]
     24576:  scope 0: ./test0-gnu-cross /usr/local/gnu-cross/x86_64-linux-gnu/lib/libc.so.6 /usr/local/gnu-cross/x86_64-linux-gnu/lib/ld-linux-x86-64.so.2
     24576:
     24576: object=/usr/local/gnu-cross/x86_64-linux-gnu/lib/ld-linux-x86-64.so.2 [0]
     24576:  no scope
     24576:
hello world

总而言之，我想找到一种验证正在使用的动态链接器的好方法。除非您能想到更好的选择，否则 LD_DEBUG 似乎是一个不错的选择，但我很难理解如何在这种情况下有效地使用它。

感谢您的帮助:)

Answer 1

不需要实际运行可执行文件来确定它将使用的 ELF 解释器。

我们可以使用静态工具，并保证我们可以获得完整路径。

我们可以结合使用 readelf 和 ldd。

如果我们使用 readelf -a，我们可以解析输出。

readelf 输出的一部分：

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         00000000000002e0  000002e0
       000000000000001c  0000000000000000   A       0     0     1

注意 .interp 部分的地址。它是 0x2e0。

如果我们打开可执行文件并查找该偏移量，我们可以读取 ELF 解释器字符串。例如，这里是 [我将称之为] fileBad：

000002e0: 2F6C6962 36342F7A 642D6C69 6E75782D  /lib64/zd-linux-
000002f0: 7838362D 36342E73 6F2E3200 00000000  x86-64.so.2.....

请注意，该字符串似乎有点奇怪……稍后会详细介绍……

在“程序标题：”部分，我们有：

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x00000000000002a0 0x00000000000002a0  R      0x8
  INTERP         0x00000000000002e0 0x00000000000002e0 0x00000000000002e0
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/zd-linux-x86-64.so.2]

再次注意 0x2e0 文件偏移量。这可能是获取 ELF 解释器路径的更简单方法。

现在我们有了 ELF 解释器的完整路径。

我们现在可以执行 ldd /path/to/executable 并且我们将获得它正在/将要使用的共享库的列表。我们将为 fileGood 执行此操作。通常，这看起来像[已编辑]：

linux-vdso.so.1 (0x00007ffc96d43000)
libpython3.7m.so.1.0 => /lib64/libpython3.7m.so.1.0 (0x00007f36d1ee2000)
...
libc.so.6 => /lib64/libc.so.6 (0x00007f36d1ac7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f36d23ff000)
...

这是一个普通的可执行文件。以下是 ldd 的 fileBad 输出：

linux-vdso.so.1 (0x00007ffc96d43000)
libpython3.7m.so.1.0 => /lib64/libpython3.7m.so.1.0 (0x00007f36d1ee2000)
...
libc.so.6 => /lib64/libc.so.6 (0x00007f36d1ac7000)
/lib64/zd-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f3f4f821000)
...

好的，解释一下……

fileGood 是标准的可执行文件 [/bin/vi 在我的系统上]。但是，fileBad 是我制作的副本，我在其中修补了一个不存在的文件的解释器路径。

从 readelf 数据中，我们知道解释器路径。我们可以检查该文件是否存在。如果它不存在，事情[显然]很糟糕。

根据我们从 readelf 得到的解释器路径，我们可以找到解释器 ldd 的输出行。

对于好的文件，ldd 给了我们简单的解释器解析：

/lib64/ld-linux-x86-64.so.2 (0x00007f36d23ff000)

对于坏文件，ldd 给了我们：

/lib64/zd-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f3f4f821000)

因此，ldd 或内核检测到缺少的解释器并替换了默认解释器。

如果我们尝试从 shell 执行 fileBad，我们会得到：

fileBad: Command not found

如果我们尝试从 C 程序执行 fileBad，我们会收到 ENOENT 错误：

No such file or directory

由此我们知道内核没有在我们执行exec*时尝试使用“默认”解释器系统调用。

所以，我们现在知道我们为确定 ELF 解释器路径所做的静态分析是有效的。

我们可以确信我们提出的路径是[将是]ELF解释器的路径， >kernel 将映射到进程地址空间。

为进一步保证，如果需要，请下载内核源代码。查看文件：fs/binfmt_elf.c

我认为这就足够了，但要回答您的最高评论中的问题

<块引用>

有了这个解决方案，我就不必在程序终止之前争先恐后地读取 /proc/<pid>/maps 了吗？

没有必要比赛。

我们可以控制 fork 进程。我们可以设置子进程在[系统调用] ptrace 下运行，这样我们就可以控制它的执行（注意ptrace 是gdb 和strace 使用的）。< /p>

在我们fork之后，但在我们exec之前，子进程可以请求exec的目标休眠，直到有进程通过ptrace附加到它为止。

因此，父级可以在目标可执行文件执行单个指令之前检查 /proc/pid/maps [或其他任何东西]。它可以通过 ptrace 来控制执行[并最终分离以允许目标正常运行]。

<块引用>

有没有办法预测接下来会生成什么 PID，然后在 /proc 中等待它的创建？

鉴于您问题的第一部分的答案，这有点有争议。

没有没有方法可以[准确]预测我们pid的过程的fork。如果我们可以确定系统将使用下一个的pid，则不能保证我们会赢得与另一个进程竞争，该进程执行 fork [在我们之前] 并“获得”我们“认为”将是我们的 pid。

Answer 2

您可以为此使用 LD_DEBUG=scopes

我机器的输出示例：

LD_DEBUG=scopes ./hello
     17513:
     17513:     Initial object scopes
     17513:     object=./hello [0]
     17513:      scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
     17513:
     17513:     object=linux-vdso.so.1 [0]
     17513:      scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
     17513:      scope 1: linux-vdso.so.1
     17513:
     17513:     object=/lib/x86_64-linux-gnu/libc.so.6 [0]
     17513:      scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
     17513:
     17513:     object=/lib64/ld-linux-x86-64.so.2 [0]
     17513:      no scope
     17513:
Hello world

寻找没有作用域的对象。此外，LD_DEBUG 只有几个值，请检查它们here 并进行实验。

如何验证程序运行时使用的动态链接器？

2 个答案: