duangsuse::Echo

#Learn #Lowlvl_backend #sysadmin #android
在学会手动使用 GCC 工具链链接 native ELF 对象文件后 duangsuse 也终于知道为什么在 ./a.out 的时候 bash 会在明明有文件的时候说找不到文件

科普一下，曾经在手机上遇到过的
首先我们有一个 Hello, world! C 程序的代码

#include <stdio.h>

int main(int argc, char **argv) {
  printf("Hello, world!!!\n");
}

clang a.c -fno-stack-protector -std=c99 -o hello -Xlinker —verbose | grep found

found ld-linux-x86-64.so.2 at /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

然后我们就获得了一个输出的 ELF 可执行文件 hello

file hello

hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped

./hello
Hello, world!!!

接下来就是魔改链接器 ld 参数的时候了，首先我们先准备好 helloworld 准备自己链接

clang a.c -c -fno-stack-protector -o hello -std=c99
file hello
hello: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
链接！

dlinker=foo #/lib64/ld-linux-x86-64.so.2
ld -lc -m elf_x86_64 -dynamic-linker $dlinker -o a.out /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crt1.o /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crti.o /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../.. -L/usr/lib/llvm-4.0/bin/../lib -L/lib -L/usr/lib hello -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/crtend.o /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crtn.o # 参数可从 clang hello --verbose 里抄

file a.out

a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter foo, for GNU/Linux 3.2.0, not stripped

./a.out
bash: ./a.out: 没有那个文件或目录
???
明明有这个文件啊

然后我们尝试一下 IPython

import ctypes
ctypes.cdll.LoadLibrary('./a.out')

OSError: ./a.out: cannot dynamically load executable
🌚 无法加载（因为亲定的解释器不存在）
那如果尝试加载一个不存在的文件呢
ctypes.cdll.LoadLibrary('./foo')
OSError: ./foo: cannot open shared object file: No such file or directory

那么我们用 elvish.io 再尝试一下，到底彻底找不到和这种「找不到」有啥区别

./a.out
Exception: fork/exec ./a.out: no such file or directory
./no_such_file
Exception: exec: "./no_such_file": stat ./no_such_file: no such file or directory

那么问题就解决了吗，你为 x86_64-pc-linux-gnu 编译的 ELF 可执行文件，默认使用 /lib64/ld-linux-x86-64.so.2 链接执行
可是到了 Android 上默认动态链接器是 /system/bin/linker ，没有 /lib64/ld-linux-x86-64.so.2
当然找不到解释器无法加载了.... 🙈
ps. 这里默认测试是在 x86_64 架构的 Android 上进行的

补充：
找不到的解释器 ldd 在我的垃圾 Debian x86_64 上默认使用 /lib64/ld-linux-x86-64.so.2 替代
所以我刚才正好编译完了一个 edb 顺便来看看
edb:

Failed to open and attach to process:
execv() failed: 没有那个文件或目录.

18 viewsedited 06:42

duangsuse::Echo

^之后 duangsuse 自然套路

echo "#!/lib64/ld-linux-x86-64.so.2\n" > fooo
cat a.out >> fooo
然后妄想可以正常运行了 🙈
./fooo: error while loading shared libraries: ./fooo: invalid ELF header

16 views07:14

duangsuse::Echo

另外你们不要以为 /lib64/ld-linux-x86-64.so.2 是一个库，它是一个 CLI 工具(helper program)，要不然怎么链接程序呢（删掉
/lib64/ld-linux-x86-64.so.2

Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
   object we can handle
  --inhibit-cache       Do not use /etc/ld.so.cache
  --library-path PATH   use given PATH instead of content of the environment
   variable LD_LIBRARY_PATH
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
   in LIST
  --audit LIST          use objects named in LIST as auditors