现在越来越多的人开始学习缓冲区溢出方面的原理和应用，这是一件好事，我们在使用别人写的Exploit去Hacker这儿Hacker那儿的时候，应该努力做到知其然，知其所以然。但是很多人在看了几篇即使是看上去很简单的栈溢出方面的文章后便敲起了退堂鼓，因为通篇大量gdb调试的命令和汇编代码让学习看上去变得枯燥无比，但是这方面知识的学习就是这样的。我写这篇文章的目的是总结一下在漏洞发掘中常用的一些gdb命令，降低一下新手入门时的门槛，希望能对大家有所帮助。这篇文章与一般的介绍gdb使用的文章有一定区别，因为那些文章的侧重点是使用gdb去调试一般的应用程序，而本文的则偏重于使用gdb去发掘漏洞时候常用的一些命令。鉴于本人大愚若智，本文如有疏漏之处，敬请mail to me.
运行 gdb
在 shell中，可以使用 'gdb' 命令并指定程序名作为参数来运行 gdb，例如 ‘gdb ./vuln'或者直接是‘gdb vuln’；或者在 gdb 中，可以使用 file 命令来装入要调试的程序，例如 'file vuln'。这两种方式都假设您是在包含程序的目录中执行命令。如果是为了调试core文件，则应用命令‘gdb `executable-file` `core-file`’，例如‘gdb ./vuln core’,如果系统不生成core文件，则可以使用命令‘ulimit -c 9999’打开这个功能。装入程序之后，可以用 gdb 命令 'run' 来启动程序。
绑定一个已有的进程
在shell中，一般使用ps －ax命令来查看目前系统里正在run的所有进程，最前面的一列就是对应的进程号，在gdb里我们可以这样绑定一个正在run的程序进行调试，首先利用上面的那个命令取得进程号，然后打开gdb：
[s5Eal@Heart]# gdb
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
(gdb) attach 734 <-你要调试的程序的进程号
Attaching to process 734
查询内存
(gdb) x/d ‘地址’ 或者 x '地址' 显示10进制内容
(gdb) x/100s '地址' 显示由此地址开始的100个字节的十进制内容
(gdb) x 0x0804846c 显示0x0804846c处的十进制内容
(gdb) x/s '地址' 显示此地址内容对应的字符串
(gdb) x/105 0x0804846c 显示0x0804846c处开始的105个字节对应的字 符串内容
(gdb) x/x '地址' 显示16进制的地址内容
(gdb) x/10x 0x0804846c 显示0x0804846c处开始的10个字节的地址内容
(gdb) x/b 0x0804846c 显示0x0804846c处一个byte的内容
(gdb) x/10b 0x0804846c-10 显示0x0804846c-10处10个byte的内容
(gdb) x/10b 0x0804846c+20 显示0x0804846c+20处20个byte的内容
(gdb) x/20i 0x0804846c 显示0x0804846c 处开始的20个汇编指令的内容
显示可执行文件的所有分段的地址
(gdb) maintenance info sections 或者
(gdb) mai i s
例子：
[s5Eal@lHeart]# gdb vul
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) maintenance info sections
Exec file:
`/root/vul', file type elf32-i386.
0x080480f4->0x08048107 at 0x000000f4: .interp ALLOC LOAD READONLY DATA HAS_C
ONTENTS
0x08048108->0x08048128 at 0x00000108: .note.ABI-tag ALLOC LOAD READONLY DATA
HAS_CONTENTS
0x08048128->0x08048158 at 0x00000128: .hash ALLOC LOAD READONLY DATA HAS_CON
TENTS
0x08048158->0x080481c8 at 0x00000158: .dynsym ALLOC LOAD READONLY DATA HAS_C
ONTENTS
0x080481c8->0x08048222 at 0x000001c8: .dynstr ALLOC LOAD READONLY DATA HAS_C
ONTENTS
0x08048222->0x08048230 at 0x00000222: .gnu.version ALLOC LOAD READONLY DATA
HAS_CONTENTS
0x08048230->0x08048250 at 0x00000230: .gnu.version_r ALLOC LOAD READONLY DAT
A HAS_CONTENTS
0x08048250->0x08048258 at 0x00000250: .rel.dyn ALLOC LOAD READONLY DATA HAS_
CONTENTS
0x08048258->0x08048278 at 0x00000258: .rel.plt ALLOC LOAD READONLY DATA HAS_
CONTENTS
0x08048278->0x08048290 at 0x00000278: .init ALLOC LOAD READONLY CODE HAS_CON
TENTS
0x08048290->0x080482e0 at 0x00000290: .plt ALLOC LOAD READONLY CODE HAS_CONT
搜寻heap，bss，got区的内容
(gdb) maintenance info sections
0x08049570->0x08049588 at 0x00000570: .bss ALLOC
0x00000000->0x00000654 at 0x00000570: .stab READONLY HAS_CONTENTS
0x00000000->0x00001318 at 0x00000bc4: .stabstr READONLY HAS_CONTENTS
0x00000000->0x000000e4 at 0x00001edc: comment READONLY HAS_CONTENTS
0x08049588->0x08049600 at 0x00001fc0: .note READONLY HAS_CONTENTS
(gdb) x/1000s 0x08049600 // 显示 heap内容
(gdb) x/1000s 0x08049570 // 显示 bss 内容
...
下断点
(gdb) disassemble main
Dump of assembler code for function main:
0x8048400 <main>: push %ebp
0x8048401 <main+1>: mov %esp,%ebp
0x8048403 <main+3>: sub $0x408,%esp
0x8048409 <main+9>: add $0xfffffff8,%esp
0x804840c <main+12>: mov 0xc(%ebp),%eax
0x804840f <main+15>: add $0x4,%eax
0x8048412 <main+18>: mov (%eax),%edx
0x8048414 <main+20>: push %edx
0x8048415 <main+21>: lea 0xfffffc00(%ebp),%eax
...
(gdb) break *0x8048414
Breakpoint 1 at 0x8048414
(gdb) break main
Breakpoint 2 at 0x8048409
(gdb)
删除断点
(gdb) delete breakpoints // or
(gdb) d b
Delete all breakpoints? (y or n) y
(gdb)
在stack区搜寻shellcode或者返回地址或者其他内容
(gdb) break '函数名或者地址'
(gdb) break main
Breakpoint 1 at 0x8048409
(gdb) run
Starting program: /root/vuln
Breakpoint 1, 0x8048409 in main ()
(gdb) x/1000s '地址' // 打印此地址开始的100个字符串
(gdb) p $esp // 查看寄存器esp的内容
$2 = (void *) 0xbffff454
(gdb) x/1000s $esp // 搜寻从esp开始向后的1000个字符串的内容
(gdb) x/1000s $esp-1000 // 搜寻从esp开始向前面的1000个字符串的内容
(gdb) x/1000s 0xbffff4b4 // 搜寻从0xbffff4b4开始向后的1000个字符串的内容
显示寄存器内容
(gdb) break main
Breakpoint 7 at 0x8048409
(gdb) r
Starting program: /home/hack/homepage/challenge/buf/basic
Breakpoint 7, 0x8048409 in main ()
(gdb) info registers
eax 0x1 1
ecx 0x8048298 134513304
edx 0x8048400 134513664
ebx 0x400f6618 1074751000
esp 0xbffff4b4 0xbffff4b4
ebp 0xbffff8bc 0xbffff8bc
esi 0x4000aa20 1073785376
edi 0xbffff924 -1073743580
eip 0x8048409 0x8048409
eflags 0x286 646
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
(gdb)
显示动态函数指针地址 (常用在return into libc exploits的构造中):
(gdb) break main
Breakpoint 1 at 0x8048409
(gdb) r
Starting program: /home/hack/homepage/challenge/buf/./basic
Breakpoint 1, 0x8048409 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} 0x40052460 <system>
(gdb) p strcpy
$5 = {char *(char *, char *)} 0x4006e880 <strcpy>
显示堆栈
(gdb) backtrace
(gdb) bt
#0 0x8048476 in main ()
#1 0x40031a5e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93
摘自红色黑客联盟(http://www.7747.net/) 原文：http://www.7747.net/Article/200501/3705.html