我在库&中有glibc提供的相同的覆盖open().我首先在库中设置了LD_PRELOAD,因此当进程调用open()时,将调用库中定义的open.
问题:-glibc中还有其他几个函数,一旦示例为getpt(),就会调用open(),当getpt()调用open()时,将调用glibc中定义的open(),我将如何使getpt ()调用在我的library()中定义的open().
限制:-我没有选择编译glibc的选项.
解决方法:
正如tmcguire正确指出的那样,从posix_openpt到__open的调用是对内部符号的调用,并且不能插入.
实际上,glibc开发人员认为此调用是实现细节,您无需进行任何更改.
I am looking at compile time solution
你不能拥有它.
than run time solution cause run time solution will have performance impact.
运行时解决方案不必对性能有任何影响(除了调用open而不是glibcs的开销外).
我只知道库插入glibc内部调用的一种方式:运行时修补.这个想法是为了
>找到libc.so.6 open的地址(这是__open的别名),
>在运行时找到glibc .text节的边界
>扫描以查找__open指令
>对于任何此类指示
> mprotect它所在的页面可写
>计算一条名为CALL my_open的新指令,并将其修补为原始指令的“顶部”
> m保护页面回读和执行
这很丑陋,但在i * 86(32位)Linux上可以正常使用,在C *中,CALL可以“到达” 4GB地址空间内的任何其他指令.对于x86_64而言,它不起作用,其中CALL仍限于/ 2GB,但是从库到glibc的距离可能会更多.
在这种情况下,您需要在libc.so.6中找到一个合适的蹦床,您可以将原始的CALL重定向到该蹦床,并可以将寄存器间接JMP放置到最终的目的地.幸运的是,由于函数对齐,libc.so.6通常具有多个大小适当的未使用的NOP区域.
标签:gcc,override,glibc,ld,linux
来源: https://codeday.me/bug/20191121/2055603.html