虽然网上有许多介绍调试相关技巧的文章了，但是有一些自己踩到的坑还很少被指出来，所以在这里作一点总结。

1.gdb.attach的方式:

用这个方式来断点的缺点是不好断到main函数，因为使用process()申请进程后可能马上就会进入到main函数内。

正常情况下使用方式如下：

在发送数据之前使用gdb.attach来执行断点命令(这里的debug和sdl分别是我的项目，一个exp的模板对gdb.attach和sendline的封装)，然后pause。使用场景一般是我们想查看发送的数据对内存的影响，如果不加pause的话一般会断在read函数的某处。

运行exp会弹出上图右方的gdb终端，然后在左边的终端按任意键，看到自己要发送的内存发送过后，接着在右边终端输入c（继续）的命令，便能够正常断点

接下来就可以像正常的gdb调试一样查看stack，heap，单步调试之类的了

​ 然而以上的正常使用是我在身处错误的调教姿势很长时间后才猛然发现的，事实上有一下两个大坑

​ 问题（1）运行exp后不弹出新的窗口，如下图

目前所知的比较好解决方法有两个：

一个是将gdb的插件pwndbg替换为peda，peda就能正常弹出窗口。其实可以给root和普通用户分别安装pwndbg和peda，因为插件是安装在用户主目录的，所以不同用户启动gdb时能有启动不同插件的效果。

另外一个就是安装tmux终端，这是一个终端的分屏软件，这个解决方法网上大概都有教程了。在tmux终端下执行exp后会自动分屏出现一个gdb的界面 。

问题（2）一直处于Wating for debugger状态导致无法正确断点

这种状态有些情况下能断到read的地方，而不是自己想断的位置，并且不能单步调式。

我现在在解决这个问题后才发现自己在过去几个月的打pwn之路中一直在承受着这不完全调试状态下的痛苦，顿时就重燃希望了有木有（虽然该不会的题还是不会）

解决方法可以参考这位师傅的文章，修改pwntools相关函数下的内容，师傅分析的很详细，不过只是复制粘贴完事的话还是很快的https://blog.csdn.net/weixin_43483799/article/details/118885208

2.使用gdb.debug断点

用这种断点方式能够轻易做到方法1做不到的时是（断main）

使用方法就是用gdb.debug替换掉以前的process来创建进程

`p=gdb.debug('./pwn','b main')

希望这篇文章能够帮助到因为一些环境错误而不能正常调试并饱受折磨的师傅们:pray:

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课