解析pwn题中附带的文件（持续更新）

解析pwn题中附带的文件

环境对pwn题至关重要，有时候本地打不通但服务器可以打通，有时候却恰恰相反，这些都与pwn题的环境有关

在一个pwn题中，除了有一个服务器上的样本文件以外，还有一些其他文件

这些文件就是题目作者交给我们的“题目环境”

我已经在“题目环境”这一块吃了不少亏了，主要是不知道这些文件是干什么的，又或许不明白这些文件的用法，所以我打算学习一下这些文件的用途，在此记录

libc.so是glibc库的软链接，一般为 libc.so.6 ，一个类似于WINDOWS下的一个快捷指向型的文件

但是pwn题中给的libc.so.6可不是软链接，而是glibc库本身

软链接 libc.so.6 所链接的glibc就是“/lib/i386-linux-gnu”中的 libc.so.6

//在本机进行操作时，程序会默认libc.so.6为glibc库，但题目文件是不是这个库就不一定了

如果pwn题给出了glibc库那就简单了，可以直接用ELF模块引入

当操作系统加载一个动态链接的应用程序时，它必须找到并加载它执行该应用程序所依赖的动态库（以so为后缀的文件），而 ld-linux.so 是链接器的运行时的组件，是专门负责寻找库文件的库，ld-linux.so将按一定顺序找到libc.so.6库再给cat调用

// ld-linux.so的位置是写死在程序中的，gcc在编译程序时就写死在里面了

程序默认的 ld-linux.so 就是“/lib/i386-linux-gnu”中的 ld-linux.so.2

如果pwn题给出了ld-linux.so，那么它一定在链接器上动了手脚，需要用patchelf修改链接器组件为题目给出的ld-linux.so，以保证环境一致

1
2
3

$ patchelf --set-interpreter /lib/my-ld-linux.so.2 my-program
#'/lib/my-ld-linux.so.2'：ld-linux.so文件的路径
#'my-program'：pwn题样本文件的名称

libc-A.BC.so 和 libc.so.6 是同一个东西（都是glibc共享库）

只不过libc-A.BC.so的命名方式更加规范：

lib表示库文件，so表示动态链接，A为主版本号，B为次版本号，C为发布版本号

标准命名可以方便pwn手一下子定位libc版本，但是有些pwn题为了隐藏libc版本，就故意把glibc库文件统一命名为libc.so.6

如果pwn题给出了libc-A.BC.so，那就连libc版本都不用测了，直接用patchelf改

1
2
3

$ patchelf ./my-program --replace-needed libc.so.6 ./other-libs
#'/other-libs'：设置rpath的路径
#'my-program'：pwn题样本文件的名称

程序会优先从rpath中获取程序的glibc库

ld-A.BC.so 和 ld-linux.so 是同一个东西（都是链接器组件）

ld表示链接器组件，so表示动态链接，A为主版本号，B为次版本号，C为发布版本号

同样，用patchelf修改链接器组件

1	$ patchelf --set-interpreter /lib/my-ld-linux.so.2 my-program

这个就比较高端了，seccomp 又被称为沙盒，是一种保护机制

libseccomp 是一个 C 语言开发的 Linux 内核系统调用过滤帮助库，很多容器项目都使用到它，比如 containerd、docker、runc

libseccomp.so 就是 libseccomp 所使用的动态链接

libseccomp.so.2 就是 libseccomp.so 的常用版本，如果pwn题中出现了libseccomp.so.2，就说明它开了沙盒的

如果只是单纯的ROP题目，libseccomp.so.2可有可无，因为有专门的工具用于检查沙盒，但是如果题目设计到堆就不同了，如果使用了 libseccomp.so.2 来开保护沙盒，那么会在程序中创建各个堆块，这可能会导致远程和本地的堆空间的布局不一致

目前没有找到什么解决的办法