type
status
date
slug
summary
tags
category
icon
password
作为一位在苦苦搬砖的pwn手,对于IO的利用有十分的痛苦不好言说所以,今天把大部分有关libc版本的问题汇总到这篇文章之中,用于以后的利用。
 
第一个命令
这个可用用来判断题目给的libc版本的具体版本。
 
然后可以使用
 
这个命令来直接patchelf 题目,注意在patchelf完之后,gdb中是没有程序的符号表的,因此我们还需要手动进行连接符号表,
 
 
notion image
这里可以看见符号表在这里面
 
然后我们就可以直接在gdb中使用如下命令进行连接
要注意,这个是一次性的,每一次打开gdb都要进行输入,并且直接输入这个有可能不行。
 
如果在exp脚本中可以使用用如下命令进行,这样在每一次脚本中打开gdb都可以连接符号表
 
如果在gdb中使用如下命令
说明没有成功,此时可以使用
 
检查 build‑id 信息 使用如下命令检查 ld 和 libc 的 build‑id:
 
得到如下结果
之后执行如下命令也能直接强行连接符号表,不过这个方法太复杂,不建议。
 
这里我最推荐的办法为在gdb的执行文件中直接添加命令来进行辅助,
 
打开gdb配置文件
写入刚刚我们用来连接符号表的命令,
这样在我们下次打开gdb时就会自行帮我们连接符号表,不过在平时不用的时候要把这个命令注销,避免程序在执行其他没有patchelf 的程序出现问题。
 
 
 
同时如果我要调试某一个出程序的源码也可以通过向这个文件里写入命令进行
当然这个命令也可以在gdb启动时输入执行
这个命令还有问题在于之前我看的文章说只要到glibc-2.31文件就行,但我测试发现好像要到具体的程序文件才行,就像malloc里面有mallco函数的源码,可以在gdb进入其中时显示,但其他函数就不行要重新换,不知道这是为什么。
 
 
以上的除了那个源码的调试之外都是建立在使用patchelf并直接到glibc_all_in_one中的版本才有的,当题目中给的附件并没有在glibc_all_in_one就好像不能直接用,要在网上去找到相对应的libc版本的符号表.debug文件。
 
 
如果题目给的程序不同可以使用如下命令进行连接,不过这样的程序就不能找到对应得符号表,要在网上找来下载就行。
 
 
参考文章
 
house of系列2024年度总结(下)与2025规划
Loading...