gcc天问之路

gcc链接器

探坑之路

因为要为malloc的漏洞利用写demo，需要不同版本的共享库，之前一直再逃避写demo这件事，一直用的可执行文件，利用patchelf来更改链接器路径，但是为了深入学习还是得自己写demo，需要掌握编译链接的全过程。

一定要记住GUN不止GCC，gcc的时候也不是仅仅用gcc，遵从stfm的原则，想深入了解一下汇编链接的全过程去查看了一下gcc的文档，好无知，哈哈哈，明明更改动态链接库的版本需要的是ld，为什么要看gcc的文档呢，还是因为-Wl选项救了我，一看解释居然是给链接器传递参数。哈哈哈。接着赶快去看linker的文档，主要用上了这两个选项：

--rpath=...
--dynamic-linker=....

–rpath选项按文档上说是链接时查找的共享对象，但是我对这个共享库也知道甚少，因此对于其也仅仅会用的状态。

–dynamic-linker选项按文档的解释是更改linker的可执行文件，彻底激发了我的好奇心，原来linker可以被直接使用的，一直以为是个库，哈哈哈哈，无知的我。然后就去查了ld的文件类型。结果：

l@L:/usr/bin$ file ld
ld: symbolic link to x86_64-linux-gnu-ld
l@L:/usr/bin$ file x86_64-linux-gnu-ld
x86_64-linux-gnu-ld: symbolic link to x86_64-linux-gnu-ld.bfd
l@L:/usr/bin$ file x86_64-linux-gnu-ld.bfd
x86_64-linux-gnu-ld.bfd: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=c93d251e4e665bc9768ef05ba3086b166e95ec2b, for GNU/Linux 3.2.0, stripped
l@L:/usr/bin$ file /lib64/ld-linux-x86-64.so.2
/lib64/ld-linux-x86-64.so.2: symbolic link to /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
l@L:/usr/bin$ file /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=4186944c50f8a32b47d74931e3f512b811813b64, stripped

盲菜ld这个东西是一个封装后的可以被人使用的程序，但是本质来看还是ld-linux-x86-64.so.2，调用其会出现：

l@L:/usr/bin$ /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 --help
Usage: /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked 'ld.so', the program interpreter for dynamically-linked
ELF programs.  Usually, the program interpreter is invoked automatically
when a dynamically-linked executable is started.

You may invoke the program interpreter program directly from the command
line to load and run an ELF executable file; this is like executing that
file itself, but always uses the program interpreter you invoked,
instead of the program interpreter specified in the executable file you
run.  Invoking the program interpreter directly provides access to
additional diagnostics, and changing the dynamic linker behavior without
setting environment variables (which would be inherited by subprocesses).

坑越来越深，哈哈哈。

不过还是先记录下更改链接器的选项，不然又得查了：

gcc top_chunk_demo1.c -Wl,--rpath=/home/l/how2heap/glibc-all-in-one/libs/2.23-0ubuntu3_amd64 -Wl,--dynamic-linker=/home/l/how2heap/glibc-all-in-one/libs/2.23-0ubuntu3_amd64/ld-2.23.so

无端猜测

本来挖出来的坑很多，要不就趁此机会把elf文件类型和编译过程真正搞通透，为未来的逆向打好基础，因为最近在学编译原理，一想，我还是把编译原理学完再说吧，效率高一点，编译原理目前是学到了yacc，以我浅薄的知识盲猜一下这个gcc的linker过程，汇编啥的不说了，所谓动态链接我猜测就是类似于python的解释过程，因为我在上述挖坑时看elf段意外发现了interpret这个段，楞一看这玩意跟解释器啥区别，之前一听解释器居然完全没联想起来，我一想动态连接，这玩意不就是在运行时需要啥拿啥吗，这python的解释器也是边解释边运行啊，编译模式的编译器，解释模式的编译器各有优点，这GUN怎么都有啊。。。。。难道时两者有点的结合？？我不知道，等学完编译原理再来补下面的吧，哈哈哈。