欺骗Linux:可执行文件和依赖库通过LD_PRELOAD

Cheating Linux: executables and dependent libraries via LD_PRELOAD

本文关键字：LD PRELOAD 依赖 Linux 可执行文件 欺骗      更新时间：2023-10-16

很抱歉这个标题，我实在想不出其他什么来描述这个问题

好的，事情是这样的:我试图在Linux下使用一个专有的免费软件应用程序(因此问题;如果我有源代码，我可以重建它)。此外，我尝试在不受支持的Linux版本上运行它，应用程序的几乎所有组件都是单独工作的，但不是一起工作的(如果应用程序完全运行，它们应该一起工作)。

让我澄清一下。有一个GUI，在不支持的操作系统中启动得很好。然后，从这个GUI中，您可以调用一堆命令行工具——有用的是，GUI还会吐出在每种情况下被调用的命令行。

现在，从GUI中调用其中一些命令会失败—但是，由于我调用了实际的命令行(假设为:"extprogram -arg1 1 -arg2 2 ...")，因此我可以从终端中重复这些命令。因此，我发现应用程序作为一个整体携带它自己的libc库;使用这些库，(一些)命令(从终端运行)往往会失败——然而，我发现从命令行，这通常适用于那些失败的命令:

LD_PRELOAD=/usr/lib/libstdc++.so.6 extprogram -arg1 1 -arg2 2 ...
# or alternatively, this works too:
# LD_LIBRARY_PATH=/usr/lib extprogram -arg1 1 -arg2 2 ...

(换句话说，使用系统libstdc++而不是应用程序提供的libstdc++，倾向于修复问题)

,

所以，现在如果我能说服GUI用"LD_PRELOAD"/"LD_LIBRARY_PATH"来调用这些工具-我想，一切都会很好…

不幸的是，GUI不调用脚本，将进一步调用这些可执行文件，我可以直接改变(只要我能看到通过grep ping) -表面上，它是GUI可执行文件创建系统调用;我试过' strace '-ing，但我找不到像临时脚本或任何我可以改变的东西…

,

所以，我想也许我可以"欺骗"做一个可执行的bash脚本;因此，我移动了可执行文件—并创建了一个脚本，该脚本应该调用移动的可执行文件，并加上LD_: 

mv extprogram extprogram.old
cat > extprogram <<EOF
LD_LIBRARY_PATH=/usr/lib extprogram $@
EOF

…但这行不通;显然，GUI应用程序识别出某些东西是不对的。

,

所以，我在想-是否有可能以某种方式，也许，有一个C/c++代码"包装器"，会以某种方式"加载"这个可执行文件，但在一个"环境"有"LD_LIBRARY_PATH=/usr/lib"设置-并传递它的参数(并返回它的返回值)?然后，我就可以在操作系统上本地构建这个"包装器"，并使用与原始可执行文件相同的名称-并且在不触及原始可执行文件(除了重命名)的情况下使整个事情正常工作。

提前感谢您的任何回答，
干杯!

你很接近了。您忘记了如何使脚本可执行。而且你调用了错误的外部程序。最后，我将使用旧脚本的绝对路径，因为您不知道GUI的CWD将是什么。

mv extprogram extprogram.old
cat > extprogram <<EOF
#!/bin/sh
LD_LIBRARY_PATH=/usr/lib exec /psth/to/extprogram.old "$@"
EOF
chmod +x extprogram

使用系统libstdc++而不是应用程序提供的libstdc++，倾向于修复问题

我很想知道使用应用程序提供的libstdc++.so.6会导致什么问题，但是如果系统解决了问题，那么一个更简单的解决方案是删除(重命名)麻烦的库，而不是做整个shell包装解决方案。

如果应用程序找不到"坏"库，那么它很有可能会找到系统库。

相关文章：