linux - 覆盖 libc open() 库函数

Question

我的库中有 glibc 提供的相同覆盖的 open() 并且我首先在我的库中设置了 LD_PRELOAD，所以当进程调用 open()，我的库中定义的 open 被调用。

问题:- glibc 中还有其他几个函数调用 open()，一旦这样的例子是 getpt()，当 getpt() 调用open()，glibc 中定义的open() 被调用，我如何使getpt() 调用在我的 library() 中定义的 open()。

约束:- 我没有编译 glibc 的选项。

Answer 1

正如 tmcguire 正确指出的那样，从 posix_openpt 到 __open 的调用是对 internal 符号的调用，不能插入。

实际上，glibc 开发人员将此调用视为实现细节，您无权更改。

I am looking at compile time solution

你不能拥有它。

than run time solution cause run time solution will have performance impact.

运行时解决方案不需要有任何性能影响(除了调用 open 而不是 glibc 的开销)。

我只知道库插入 glibc 内部调用的一种方法:运行时修补。这个想法是为了

• 找到libc.so.6 open(__open的别名)的地址，
• 在运行时定位glibc.text段的边界
• 扫描它以获取 CALL __open 指令
• 对于任何此类指令
  • mprotect 页面可写
  • 计算一条新指令，即 CALL my_open 并将其修补到原始指令的“顶部”
  • mprotect页面返回读取和执行

这很丑陋，但它适用于 i*86(32 位)Linux，其中 CALL 可以“到达”4GB 地址空间内的任何其他指令。它不适用于 x86_64，其中 CALL 仍然限于 +/- 2GB，但从您的库到 glibc 的距离可能不止于此。

在这种情况下，您需要在 libc.so.6 中找到一个合适的蹦床，您可以将原始 CALL 重定向到它，并且可以在其中放置一个register-indirect JMP 到你的最终目的地。幸运的是，由于函数对齐，libc.so.6 通常有多个大小合适的未使用的 NOP 区域。