buuctf|warmup_csaw_2016 1：从checksec到栈溢出的实战解析

1. 初识靶场与文件：从下载到基础分析

大家好，我是老张，一个在安全圈摸爬滚打了十来年的老家伙。今天咱们不聊那些高大上的理论，就从一个实实在在的CTF题目入手，手把手带你走一遍从拿到文件到最终拿到flag的完整流程。这个题目就是BUUOJ平台上的 warmup_csaw_2016，一个非常经典的栈溢出入门题。别看它名字叫“热身”，里面包含的知识点可一点都不“热”，而是实打实的二进制安全基础。很多新手朋友一看到二进制、逆向、漏洞利用这些词就头大，觉得门槛太高。别怕，今天我就用最“白话”的方式，带你一步步拆解它，保证你听完之后能自己动手复现出来。

咱们先说说这个题目的背景。它源自一个非常著名的CTF比赛——CSAW，这个比赛里的题目质量都很高，经常被各大练习平台收录。BUUOJ（北京联合大学在线评测系统）就是一个非常好的国内CTF练习平台，里面集成了大量国内外赛事的原题。我们今天的任务，就是攻破这道题。首先，你得有个地方能运行这个程序。通常，我会在自己的Linux虚拟机里搞一个专门的CTF环境，装好必要的工具，比如pwntools、checksec、gdb、IDA这些。如果你还没有搭建环境，别着急，先跟着我的思路走，理解每一步在做什么，环境搭建我们后面可以单独再聊。

拿到题目的第一步，永远是先“看看”它是个什么东西。题目一般会提供一个可执行文件，或者一个网络服务的地址。对于这道题，我们假设你已经从平台上下载了一个名为warmup_csaw_2016的文件（可能没有扩展名）。这时候你别急着双击运行（Linux下也运行不了），我们得用工具先给它做个“体检”。这个体检医生就是 file 命令。你在终端里输入 file warmup_csaw_2016，它会告诉你这个文件的“底细”。比如，它会输出这是不是一个ELF文件（Linux下的可执行文件格式），是32位的还是64位的，有没有被strip掉符号信息（就是调试用的函数名、变量名等）。对于这道题，file命令会明确告诉你：这是一个64位的ELF可执行文件。知道是64位非常重要，因为这直接影响我们后续构造攻击载荷（payload）时地址的长度和寄存器的使用。

光知道位数还不够，我们还得看看这个程序身上穿了哪些“防弹衣”。在CTF和安全研究中，现代编译器通常会为程序开启一些保护机制，比如栈不可执行（NX）、地址空间布局随机化（ASLR）、栈溢出保护（Canary）等等。这些机制就像游戏里的关卡，增加了我们利用漏洞的难度。怎么快速查看这些保护呢？这就轮到我们的第二位体检医生——checksec 工具出场了。checksec通常集成在pwntools这个Python库中。你可以在终端输入 checksec warmup_csaw_2016。输出的结果可能会是这样的：

Arch:     amd64-64-little
RELRO:    Partial RELRO
Stack:    No canary found
NX:       NX disabled
PIE:      No PIE (0x400000)
RWX:      Has RWX segments

我来给你翻译一下这份“体检报告”：

• Arch: 架构是amd64，也就是64位，字节序是小端（little）。这个我们知道了。
• RELRO: 部分开启。这是一种保护全局偏移表（GOT）的机制，部分开启通常影响不大，完全开启（Full RELRO）会使得GOT表只读，阻止一些攻击。
• Stack: No canary found: 栈保护（Canary）没有开启！这是个重大利好。Canary就像栈上的一个“哨兵”，如果发生栈溢出破坏了它，程序就会崩溃，阻止攻击。现在没开，意味着我们可以肆意地覆盖栈上的数据。
• NX: NX disabled: NX（不可执行）保护被关闭了！又一个重大利好。NX保护意味着栈和堆这些数据区域不能执行代码。如果开启了，我们即使把恶意代码（shellcode）放到栈上，CPU也不会去执行它。现在关闭了，理论上我们可以把代码放在栈上并执行。
• PIE: No PIE: 地址空间布局随机化（PIE）没有开启！这是第三个利好。PIE开启后，每次运行程序，其代码段、数据段的基地址都会随机变化。没开的话，程序中所有函数、变量的地址都是固定的、可预测的，我们就能在攻击脚本里硬编码这些地址。

总结一下这份报告：这个