准确识别ELF文件使用的libc.so版本，LibcSearcher 工具的使用

一、问题起因

在做 ctf-wiki 的x86栈溢出的 ret2libc 的例题3时，使用作者的 exp 拿不到 shell，个人认为解题思路没有问题，应该是 LibcSearcher 这个python 库不太靠谱的问题，尝试网页查询 libc ，结果跟LibcSearcher 库的结果一样。

---

二、解决办法

找到自己系统使用的 libc 版本全名（一般在系统里面就是 libc.so.6 ，就一个主版本号，致命的是还没有软连接指向它，使用 github 上的 LibcSearcher 项目的功能，能够识别到真正的 libc 的全名！！），再做其他操作（比如查各个函数的地址啥的）

---

三、实验

第一步：先看可执行文件加载的是系统的那一个 libc.so 文件

我刚开始就是一个 ldd 命令，以为用的是/lib32/libc.so.6 这个共享库文件，但我发现这样不够准确后面我就先加载可执行文件，再看他的地址映射信息，这里面的共享库信息总不可能错结果路径是 /usr/lib32/libc.so.6，而且这个文件也只有主版本号，没有软链接指向它

第二步：使用 LibcSearcher 工具识别 本机的 libc 共享库

网上有很多识别 libc 版本的方法，比如直接执行 libc、ldd --version、getconf GNU_LIBC_VERSION等但是查询出来的信息跟 LibcSearcher  数据库中的名称完全对不上LibcSearcher  这个工具识别 libc 版本的思路很简单，就是它维护了一个 版本名与hash值的键值对，通过对本机的共享库计算hash，再去数据库中查hash值相同的那个共享库是啥就ok了（这个原理是我自己的推测，因为LibcSearch 这个工具依赖 MD5 、hash等工具，具体部署请浏览 github的readme），这种方式就会很准确，下面是使用方式：

step 1：识别

命令：    ./identify  +  共享库绝对路径

可以看见平台架构、主次版本、系统都出来了，至此的话识别就结束了（其他库的应该也是一样的操作，我自己没有试）

step 2:简单查看泄露符号的地址

命令：   ./dump + 上一步查到的共享库全称

如果说这一步的结果中，没有你想要的符号，你可以把共享库下载下来，用 objdump 查看所有符号

step 3:下载，查看所有符号

命令：   ./download + 上一步查到的共享库全称

 下载会单独放在一个目录中，进入这个目录中就可以 随便调试了，所有函数的文件偏移（应该是在elf文件中偏移，我没有理解错的话）都可以看见了