53

所以大家可能都知道glibc/lib/libc.so.6可以像普通的可执行文件一样在shell 中执行，在这种情况下它会打印其版本信息并退出。这是通过在 .so 中定义一个入口点来完成的。在某些情况下，将其用于其他项目也可能很有趣。不幸的是，您可以通过 ld 的 -e 选项设置的低级入口点有点太低级：动态加载程序不可用，因此您无法调用任何适当的库函数。出于这个原因，glibc 通过这个入口点中的裸系统调用来实现 write() 系统调用。

我现在的问题是，任何人都可以想出一种好方法，如何从该入口点引导一个完整的动态链接器，以便可以访问其他 .so 的函数？

4

3 回答 3

55

更新 2：请参阅 Andrew G Morgan 的稍微复杂一点的解决方案，该解决方案适用于任何 GLIBC（该解决方案libc.so.6本身也可以使用（自永远以来），这就是您可以运行它的原因./libc.so.6（它在以这种方式调用时打印版本信息））。

更新 1：这不再适用于较新的 GLIBC 版本：

./a.out: error while loading shared libraries: ./pie.so: cannot dynamically load position-independent executable

2009年的原始答案：

使用选项构建共享库-pie似乎可以为您提供所需的一切：

/* pie.c */
#include <stdio.h>
int foo()
{
  printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
  return 42; 
}
int main() 
{ 
  printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
  return foo(); 
}


/* main.c */
#include <stdio.h>

extern int foo(void);
int main() 
{ 
  printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
  return foo(); 
}


$ gcc -fPIC -pie -o pie.so pie.c -Wl,-E
$ gcc main.c ./pie.so


$ ./pie.so
in main pie.c:9
in foo pie.c:4
$ ./a.out
in main main.c:6
in foo pie.c:4
$

PS glibcwrite(3)通过系统调用实现，因为它没有其他地方可以调用（它已经是最低级别了）。这与能够执行无关libc.so.6。

于 2009-09-20T17:13:56.280 回答
6

我一直在寻找对此的支持pam_cap.so，并找到了这个问题。正如@EmployedRussian 在他们自己帖子的后续文章中指出的那样，接受的答案在某个时候停止工作。花了一段时间才弄清楚如何让这项工作再次发挥作用，所以这里有一个工作示例。

这个工作示例涉及 5 个文件，以显示一些相应的测试是如何工作的。

首先，考虑这个简单的程序（调用它empty.c）：

int main(int argc, char **argv) { return 0; }

编译它，我们可以看到它是如何解析我系统上的动态符号的，如下所示：

$ gcc -o empty empty.c
$ objcopy --dump-section .interp=/dev/stdout empty ; echo
/lib64/ld-linux-x86-64.so.2
$ DL_LOADER=/lib64/ld-linux-x86-64.so.2

最后一行设置了一个 shell 变量以供以后使用。

以下是构建我的示例共享库的两个文件：

/* multi.h */
void multi_main(void);
void multi(const char *caller);

和

/* multi.c */
#include <stdio.h>
#include <stdlib.h>
#include "multi.h"

void multi(const char *caller) {
    printf("called from %s\n", caller);
}

__attribute__((force_align_arg_pointer))
void multi_main(void) {
    multi(__FILE__);
    exit(42);
}

const char dl_loader[] __attribute__((section(".interp"))) =
    DL_LOADER ;

（2021-11-13 更新：强制对齐是为了帮助__i386__代码与 SSE 兼容- 没有它，我们很难调试glibc SIGSEGV崩溃。）

我们可以如下编译运行它：

$ gcc -fPIC -shared -o multi.so -DDL_LOADER="\"${DL_LOADER}\"" multi.c -Wl,-e,multi_main
$ ./multi.so
called from multi.c
$ echo $?
42

因此，这是一个.so可以作为独立二进制文件执行的程序。接下来，我们验证它是否可以作为共享对象加载。

/* opener.c */
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    void *handle = dlopen("./multi.so", RTLD_NOW);
    if (handle == NULL) {
        perror("no multi.so load");
        exit(1);
    }
    void (*multi)(const char *) = dlsym(handle, "multi");
    multi(__FILE__);
}

也就是说，我们动态加载共享对象并从中运行一个函数：

$ gcc -o opener opener.c -ldl
$ ./opener
called from opener.c

最后，我们链接到这个共享对象：

/* main.c */
#include "multi.h"

int main(int argc, char **argv) {
    multi(__FILE__);
}

我们编译和运行它的地方如下：

$ gcc main.c -o main multi.so
$ LD_LIBRARY_PATH=./ ./main
called from main.c

（注意，因为multi.so不在标准系统库位置，我们需要覆盖运行时使用LD_LIBRARY_PATH环境变量查找共享对象文件的位置。）

于 2021-07-11T18:46:10.970 回答
1

我想您将ld -e指向一个入口点，然后该入口点将使用dlopen()函数系列来查找和引导动态链接器的其余部分。当然，您必须确保它dlopen()自己是静态链接的，或者您可能必须实现足够的自己的链接器存根来获取它（使用系统调用接口，mmap()就像 libc 本身正在做的那样。

这些对我来说都不是“好”的。事实上，仅仅阅读 glibc 源代码（以及ld-linux源代码，作为一个例子）就足以评估工作的规模对我来说听起来很老套。这也可能是便携性的噩梦。ld-linuxLinux 如何实现与在 OpenSolaris、FreeBSD 等下如何实现链接之间可能存在重大差异。（我不知道）。

于 2009-09-20T03:26:38.817 回答