企业官网建设流程全解析

CTFshow 的 pwn 系列做到 033 的 FORTIFY_SOURCE，其实已经是不少初学者开始觉得"怎么突然硬起来了"的分水岭。前面的 ret2text、ret2syscall、栈溢出基础都还好说，最多就是对着 IDA 找关键函数、算偏移、拼 ROP chain，但 FORTIFY_SOURCE 这个开关一打开，你会发现同样一段代码，编译出来之后的机器码跟之前完全不一样，硬编码的 gets 变成 __gets_chk、strcpy 变成 __strcpy_chk，你原来算好的偏移可能直接废掉。

我这边借着 CTFshow pwn 033 这题，把 FORTIFY_SOURCE Level 1 从头到尾拆一遍——它到底编译期做了什么、运行期靠什么拦你、在 pwn 题里面对我们解题的影响有多大、以及最关键的：如果题目开了 FORTIFY，你的利用思路要往哪个方向调整。这篇不只是复现 writeup，更多是让你搞清楚背后的机制，以后换一道题也能自己判断怎么打。

1. FORTIFY_SOURCE 到底是什么：一个被很多人误解的编译选项

先说人话版本：FORTIFY_SOURCE 是 glibc 和 GCC 配合提供的一套运行时缓冲区溢出检测机制，Level 1 是它的最低档防护。它的套路不是"禁止你溢出"，而是"在你确实想溢出的时候，尽可能让你撞到检查然后崩掉"——对攻击者来说，这玩意儿比单纯禁用一个危险函数更烦，因为表面上啥都没变，代码还是能跑，但你踩线的那一下它直接终止进程。

1.1 编译器做的手脚：函数替换的三种情况

要理解 FORTIFY_SOURCE，先要看你的代码是怎么被编译的。假设你在源码里写了：

char buf[8]; strcpy(buf, input);

没有 FORTIFY 的时候，编译器直接把这个 strcpy 调用翻译为对 libc 里strcpy的调用，符号就是strcpy。

开了-D_FORTIFY_SOURCE=1之后，只要 GCC 能在编译期确定目标缓冲区的大小（比如局部数组、全局数组这种编译期就知道长度的对象），它就会把调用替换为带_chk后缀的版本：

strcpy(buf, input); // 编译后变成 __strcpy_chk(buf, input, 8);

注意这个8，它是在编译期算出来的目标缓冲区大小。如果 GCC 在编译期无法确定缓冲区大小（比如指针传进来的、malloc 出来的堆内存），那就分两种情况：

这就是为什么很多 CTF 题目开了 FORTIFY，但照样有漏洞——因为漏洞往往发生在编译器"看不到"大小的地方，比如经典的read(0, heap_ptr, n)这种，heap_ptr是堆指针，编译器不知道它指向的对象大小，FORTIFY 对这类调用基本无能为力。

1.2 FORTIFY Level 1 只做边界检查，不重排结构体

这里必须先纠正一个常见的说法。很多教程说"FORTIFY_SOURCE 会把结构体重排、把函数指针移到只读区"，这其实是Level 2才引入的一部分行为，而且不是全部。Level 1 的职责非常聚焦：

• 对显式传入目标缓冲区大小的函数（strcpy、memcpy、sprintf、gets、read 等）做_chk替换，运行时检查目标长度是否超过编译期记录的大小。
• 对于 printf 系列，__printf_chk会检查格式串中%n的使用（Level 1 是禁止%n写入不可写段，Level 2 才整体禁止%n）。
• 不改变任何变量布局，不移动结构体字段，不把指针挪到只读区。

所以 Level 1 下，你之前在普通编译题里练的偏移计算、ROP 构造思路大体还是能用，只是多了几道运行时检查，得想办法绕过去或者触发不了检查。

2. 从 CTFshow pwn 033 看题：一道典型的 FORTIFY 入门关

这题我没有把完整的源码和 IDA 反编译贴出来（避免直接搬运 writeup 造成的刷屏感），但题目考察的核心模式非常典型，我把它还原成下面这个等价场景，你对照自己的题目就能对上号。

2.1 题目场景还原：编译期可读的栈缓冲区

假设题目给了这样的关键代码：

int __cdecl main(int argc, const char **argv) { char buf[64]; setbuf(stdout, NULL); puts("Welcome to FORTIFY challenge"); printf("Input: "); read(0, buf, 0x100u); return 0; }

然后编译命令大概是：

gcc -o pwn033 pwn033.c -fstack-protector-all -D_FORTIFY_SOURCE=1

这道题实际编译时还开了栈保护（canary），这个我们后面会专门说。单看 FORTIFY 的部分，核心就是read(0, buf, 0x100u)——注意，read确实在 FORTIFY 的监控范围，但它的_chk替换有个前提：编译器必须知道这次 read 的目标是哪个对象、对象多大。

buf是栈上的 64 字节数组，编译期可知大小，所以整行代码会被替换成：

__read_chk(0, buf, 4096, 64);

__read_chk的签名是这样的：

ssize_t __read_chk(int fd, void *buf, size_t nbytes, size_t buflen);

第四个参数buflen就是编译器记录的目标缓冲区大小（64），第三个参数nbytes是你传入的期望读取长度（0x100）。

然后__read_chk内部会做这样一个判断：

if (nbytes > buflen) { __chk_fail(); // 直接 abort }

回到题目：nbytes = 0x100 = 256，buflen = 64，256 > 64，所以只要一调用这个 read，程序就立刻触发 __chk_fail 崩掉。

这就产生了一个看似矛盾的局面：你连输入都还没真正发出去，程序就退了。这正是 FORTIFY Level 1 最典型的"编译期可检测漏洞"特征——只要目标缓冲区大小在编译期是确定的，并且你请求的长度超过它，运行时就一定触发检查。

2.2 但这里有个关键歧义：read 真的被替换了吗

上面这段是"如果编译器确实替换成 __read_chk"的推论。实际 CTFshow pwn 033 里，你拿到二进制后用 IDA 看，往往是看不到 __read_chk 的，看到的还是 write 进去的 read 的 plt、libc/lib/x86_64-linux-gnu/libc.so.6里的普通read。

这就牵出 FORTIFY 的一个非常容易搞混的技术细节：read和write这类系统调用封装，在很多编译配置下并不会被替换成_chk版本。原因在于它们本质上是对系统调用的薄封装，glibc 的实现里并没有在read符号上做_chk的强绑定，或者说 GCC 对read的_chk替换依赖的是头文件里是否声明了对应的__read_chk内建函数。

实际上，很多 CTF 题目的 FORTIFY 环境里，read确实还是普通 read，但strcpy、sprintf、gets这类 C 库字符串函数会被替换。所以你不能凭"开了 FORTIFY 就假设 read 也被检查"。

正确做法是：拿到题目后，先 IDA 看外部函数表，确认哪些函数变成了_chk后缀。如果外部函数表里只有__printf_chk、__memcpy_chk，那说明编译期真正被 FORTIFY 约束的只有那少数几个函数，其他没带_chk的仍然随意利用。

CTFshow pwn 033 这道题，我见过的版本里，由于它的溢出点如果走 read，那 read 并没有被替换成__read_chk，所以接下来我们讨论的才是真正的解题点：漏洞点不在 read 那次输入，而在更后面的某个基于栈的字符串函数拷贝。

为了把机制讲透，我下面用strcpy和sprintf两条典型 FORTIFY 利用路线来分析，这也是 pwn 题里最常遇到的两种。

3. 两条典型的 FORTIFY 利用路线：栈上拷贝与格式化串

3.1 路线 A：strcpy/memcpy 的编译期大小替换

常见题目模式是：

char dest[64]; char src[256]; // ... src 可以被输入填满 ... strcpy(dest, src);

编译器看到dest是局部数组 64 字节，于是替换为：

__strcpy_chk(dest, src, 64);

__strcpy_chk 内部会逐字节拷贝 src 到 dest，一旦发现拷贝长度超过 64（包括末尾的\0），就调用__chk_fail。等于说：你不能通过这个 strcpy 实现溢出，它会精确卡在你写满 64 字节后、准备写第 65 字节之前。

这种情况应该怎么办？三个方向：

1. 放弃这条拷贝路径，找别的溢出点。比如源码里如果还有第二个未受保护的read或gets（gets 一般也被替换成__gets_chk，但某些情况下编译器确定不了时就不替换），优先用那里。
2. 寻找可溢出的间接写入。例如 strcpy 之后如果还有printf("%s", dest)，而 dest 已经被填满但没有\0终止（实际上_chk会补\0），这条路不好走。
3. 返回地址之前还有足够空间就做 ROP，但前提是 strcpy 拷贝时没触发检查。比如 dest 是 64，你 src 也确实短于 64，然后靠其他方式把多余数据填充到返回地址区域——但这就得找别的写手段了。

所以面对_chk函数，核心思路是：不要把宝押在被检查的那次拷贝上溢出，而是把它当成一次"正常写入"，想办法利用程序后面读出的数据、或者另一个未检查的调用点来构造覆盖。

3.2 路线 B：printf 的 __printf_chk 与 %n 限制

FORTIFY 下的printf会变成__printf_chk(1, format, ...)。第一个多出来的参数1表示"这是 stdout"。对于 Level 1，__printf_chk的限制只有一个比较关键：当格式串里出现%n时，目标地址不能指向只读段。实际上 glibc 的__printf_chk实现中，如果检测到%n配合的指针指向了只读段（比如指向某个字符串常量、或者 GOT 表中的地址），就直接报错。

这条限制对格式化字符串攻击的影响很大。之前你如果是用%n改 GOT、改返回地址，在 FORTIFY Level 1 下要小心：GOT 表所在的内存页是可写的，所以%n改 GOT 一般不会被这个检查拦住；但如果目标地址落在只读段，比如你想用%n改某个字符串字面常量所在地址，就会触发检查。

不过更常见的影响是：__printf_chk对格式串本身的解析没有本质变化，%x、%p、%s泄露栈内容依然正常工作。所以格式化字符串泄露在 FORTIFY Level 1 下几乎不受影响。

这个结论对 pwn 033 这类题目意义很大：如果题目里存在格式化字符串漏洞，你可以照常泄露栈上数据、泄露 canary、泄露 libc 地址，唯一要规避的就是"用 %n 写只读段"这种操作。

3.3 一个实操判断技巧：如何快速知道题目卡点在哪

拿到一个开了 FORTIFY 的 pwn 题，我建议按下面流程扫一遍：

1. checksec看编译保护开关，特别确认 FORTIFY 级别（通常是 Fortified 或者 Fortified 未显示具体级别的情况）。
2. IDA 打开，看 External functions 列表里有没有__xxx_chk。有哪几个就说明哪几个被替换了。
3. 对每个_chk函数，关注它的第四个参数（对于 read/recv 是 buflen）或第三个参数（对于 strcpy/strncpy 是 dest 大小）。
4. 找出用例中没有被替换的输入/拷贝路径，那才是可利用的溢出点。
5. 如果所有输入点都被替换了，那就得思考"溢出是否真的必要"——比如是不是可以借助栈上已有的数据布局来劫持控制流。

4. FORTIFY 叠加 Canary：pwn 033 里最常见的组合拳

CTFshow pwn 033 之所以是"前置基础"的倒数第二类题，是因为它通常会同时开栈保护和 FORTIFY。两个保护叠加，很多初学者就彻底懵了。这一节我们把两层保护分开看，再合起来分析入口。

4.1 Canary 拦的是"溢出后改返回地址"这个动作

栈保护（Stack Canary，对应编译选项-fstack-protector-all）的原理是：函数入口处从 FS 段（TLS）取一个随机值压入栈，放在返回地址之前；函数退出时会检查这个值有没有被改变。如果你溢出覆盖了返回地址，几乎必然要先覆盖这个 canary，一覆盖，检查就失败，程序 abort。

它的针对性非常明确：只防"连续覆盖到返回地址"的线性溢出。如果你通过任意地址写、或者只改返回地址中间几个字节（且不碰 canary），它就不起作用。

4.2 FORTIFY 拦的是"一次读/写超过目标大小"这个动作

FORTIFY 则不同，它在每次调用_chk函数时，用编译期记录的大小做判断——不管你之后要覆盖什么，只要这次调用请求的字节数超过了编译期大小，就当场失败。

所以在开了 Fortify 的题里，我们常看到这种"双保险"设计：

• FORTIFY 负责把显式的read/strcpy/memcpy请求卡死，让你没法一次写入超长数据。
• Canary 负责在你通过"看起来合法长度、但实际利用多次写入/逻辑漏洞"构造的溢出到达返回地址前拦一道。

两道闸门配合下来，单纯靠"read 输入 0x100 到 64 字节缓冲区"这种经典模型就直接死了。

4.3 但这两道闸门都有缝隙

先说 FORTIFY 的缝隙：编译期只知道大小的地方才检查，不知道大小的调用不检查。最常见的就是堆上分配的指针：

char *p = malloc(64); read(0, p, 0x100); // p 是 malloc 返回值，编译器不知道指向的对象大小

这种情况下，GCC 对 malloc 返回值的处理有很多历史版本差异。老版本 GCC 在 FORTIFY 下可能不替换 read；新版本有时会因为malloc的属性知道了大小而替换成__read_chk(0, p, 0x100, 64)。CTF 题目编译环境多样，你得看实际二进制。

另一个缝隙：循环内的小步写入。比如：

char dst[64]; int i = 0; while (input[i]) { dst[i] = input[i]; i++; }

这种逐字节拷贝不是strcpy，不在 FORTIFY 的静态替换范围内，所以照样能溢出。

再说 Canary 的缝隙：如果你先通过格式化字符串漏洞把 canary 泄露出来，然后在后续溢出时把 canary 原样写回，栈保护就形同虚设。泄露 canary 用的是%p或者%s，这在 FORTIFY Level 1 下不受影响，所以这条结合路线是可行的。

pwn 033 这道题的常见解法里，很多时候就是先找一个格式化字符串或者可控制输出内容的点来泄露 canary/libc，然后再利用那个未受保护的写入点去覆盖返回地址。如果你发现题目里所有拷贝都被_chk拦死了，那就需要找"表面上不涉及超长拷贝、但实际造成写入"的逻辑漏洞。

5. 完整解题步骤：如何在实战中确认 FORTIFY 状态并展开利用

这一节我直接给出一套可复用的流程，以 CTFshow pwn 033 这类前置基础题为场景。你手头如果有题目二进制，跟着做一遍就会很清楚。

5.1 第一步：checksec 和 IDA 交叉确认

checksec ./pwn033

输出里关注这几个字段：

然后 IDA 打开，在 Imports 窗口搜chk。你可能会看到：

• __printf_chk
• __memcpy_chk
• __strcpy_chk
• __read_chk

注意：只要看到任何一个_chk函数，说明 FORTIFY 已生效，但只有被调用的那几个是"生效点"。

5.2 第二步：定位未被 FORTIFY 覆盖的输入/输出点

对每个输入函数做三个判断：

1. 它在源码层面的目标对象是不是编译期可知大小的对象？
2. 如果是，它的实际调用是否带上了_chk后缀？
3. 如果不是，那它就是你的主要攻击面。

常见"漏网"点：

• scanf系列，__isoc99_scanf不受 FORTIFY 影响。
• fgets有更严格的检查，但它本身就是受限读取。
• gets通常会被替换成__gets_chk，但在 FORTIFY 实现里，gets其实是从 glibc 2.16 开始被移除的，直接用gets编译可能直接报错，题目一般不这么出。
• 自己实现的my_read、input函数，内部是read且编译器确定不了大小的话，就不会被检查。

找到攻击面之后，传统的栈溢出模型才成立。

5.3 第三步：构造利用链的常见次序

我这里给一个保守但稳定的利用次序：

1. 泄露 canary：利用任意格式化字符串或越界输出点，读取保存 canary 的栈地址。canary 在 x64 下通常是栈上rbp-0x8的位置，低 1 字节为\x00。
2. 泄露 libc 地址：借助 GOT 表里某个已解析函数地址，或者格式化字符串直接泄露__libc_start_main的返回地址。
3. 计算 one_gadget 或 system 地址。
4. 触发溢出：把整个 payload 拼成padding + canary + padding + retaddr，其中 retaddr 指向利用链目标。
5. 如果题目里 FORTIFY 拦截了某次输入，则寻找另一个写点完成最后一步覆盖。比如你有两个输入点：第一个被_chk拦截，第二个是未保护的read，那就用第二个写点来打。

5.4 第四步：绕不过去的典型情况与对策

如果所有输入点都被 FORTIFY 覆盖了，那基本可以确定题目考察的不是"传统溢出"，而是下面几个方向之一：

• 逻辑漏洞：比如整数溢出导致的长度混淆、类型混淆，最终让某个函数复制长度判断失效。
• 堆利用：FORTIFY 对堆溢出几乎不设防（堆对象的大小不是编译期常量），所以 UAF、double free、fastbin dup 等堆利用手段基本不受影响。
• 劫持_chk_fail：有一种思路是覆盖 GOT 表中的__chk_fail函数指针，把程序原本的"检测失败跳转"劫持到我们想要的函数（比如 system("/bin/sh")）。但这个思路在 PIE+Full RELRO 下不可行，因为 GOT 只读。前置基础题通常不开 Full RELRO，所以存在机会。

__chk_fail劫持这个思路我单独强调一下——它几乎是 FORTIFY 题目专属的利用方式。原理是：当__xxx_chk检测到溢出时，它不直接 abort，而是调用__chk_fail@plt。如果你能通过一个未受保护的溢出点把 GOT 表里__chk_fail的地址改成system的地址，那么当某个_chk函数触发检查时，程序就会跳进system执行。当然前提是你能传参，也就是还要构造好调用参数。这种情况很少出现在纯 pwn 前置基础题，但作为思路了解很有价值。

6. 实测常见的编译差异：为什么同样代码在不同环境表现不一样

很多读者在复现 CTFshow pwn 033 时，会遇到"我本机编译的二进制和题目都不一样"的情况。这是必然的，因为 FORTIFY 的替换行为高度依赖 GCC 版本、glibc 版本、头文件声明和编译参数。我把几个关键差异列出来：

这就解释了为什么网上奇奇怪怪的 writeup 里有说"这题 FORTIFY 没生效"的、有说"read 被 check 了"的——他们大概率拿的不是同一套编译产物。

实操建议：看题时先看它给的 libc 版本和 pwn 环境。CTFshow 这类在线平台通常固定了编译环境，以平台给出的二进制为准。在自己的 Ubuntu 上随便gcc编译复现，很容易得出错误结论。

另一个容易踩的坑是编译参数里的优化级别。gcc -D_FORTIFY_SOURCE=1如果不开-O，GCC 可能会警告：

warning: _FORTIFY_SOURCE requires compiling with optimization (-O)

意思很直接：FORTIFY 在没开优化时很可能部分失效。题目如果开了 FORTIFY，几乎一定是带-O1或-O2编译的。你用-O0复现，看到的反汇编会非常不一样。

7. 以 pwn 033 为跳板：FORTIFY 题目的一般化利用心法

到了这一步，你应该能明白 FORTIFY 并不是多高深的东西，它的核心逻辑就一句话：编译器在编译期记录对象大小，运行时检查请求是否越界。而我们做 pwn 的思路，本质上是寻找"编译器不知道大小"或者"程序自己提供了一个绕过检查的通道"。

我总结了四个一般化原则，适用于几乎所有开了 FORTIFY 的题目：

1. 以_chk函数列表为准，不要以源码直觉为准。同一个read在有的环境被检查，有的没有，IDA 里的函数名是唯一事实。
2. FORTIFY 不能防"多次小步写入"和"堆上的越界"。所以堆题基本无视 FORTIFY，栈题则需要找循环写入、数组索引错误等位置。
3. 能用格式化字符串泄露就不怕 FORTIFY。泄露类操作几乎不受影响，唯一注意别用%n写只读区。
4. 如果题目同时开了 Canary + FORTIFY，优先考虑泄露而非爆破。爆破 canary 在 64 位下不现实，配合格式化字符串泄露才高效。

CTFshow 033 的最后一问，我记得很多 writeup 里是利用了__stack_chk_fail和 FORTIFY 的组合跳转，也有人是干脆绕开了 FORTIFY 找系统调用点。哪种都行，核心是你得先清楚当前二进制到底哪次 IO 是"自由"的。

7.1 一个小实验帮你加深理解

如果你手边有 Linux 环境，可以做个最小验证：

// test.c #include <stdio.h> #include <string.h> int main(int argc, char **argv) { char buf[16]; strcpy(buf, argv[1]); printf("%s\n", buf); return 0; }

编译两个版本：

gcc -o test0 test.c gcc -o test1 test.c -O2 -D_FORTIFY_SOURCE=1 objdump -d test1 | grep chk

第二个版本里你大概率会看到__strcpy_chk@plt的调用。再用 gdb 分别跑./test1 AAAA...（超长参数），观察普通版 segfault 而 fortified 版在__strcpy_chk里直接 abort 或调用__chk_fail。这个小的对比实验，比背十遍理论都有用。

7.2 关于 __chk_fail 的进阶利用提示

__chk_fail在 libc 里的实际行为是调用__fortify_fail，再调用abort。但在编译产物里，它是以 plt 形式被引用的，所以如果你能改 GOT：

• 修改__chk_fail@got为system@plt或one_gadget。
• 同时让某个_chk函数在被调用时rdi/rsi里恰好是/bin/sh的地址（这种情况下参数可能是源缓冲区指针）。

这种技巧属于 FORTIFY 下比较偏门的"借力打力"，在纯前置基础题里出现的概率不大，但在更高级的 CTF 里偶尔能看到。读者当作扩展知识了解即可，不必在 033 上死磕这条路。

8. 从 CTF 到现实：FORTIFY 在真实程序里的价值与局限

写到最后，我还是想聊一下这个保护机制在实际工程里的意义，因为你理解它存在的理由之后，做 pwn 题时会有更多预判。

FORTIFY_SOURCE 是一个低成本、高收益的漏洞缓解措施。它不需要改动源码，只要重新编译时加一个宏和一个优化级别，就能拦下一大批"经典且机械"的缓冲区溢出。现实世界里的很多漏洞其实是开发者用strcpy、sprintf、gets留下的，FORTIFY 能把这些直接拉闸。

但它也只是一个"缓解措施"，不是安全边界。它的局限非常明显：

• 一旦对象大小不是编译期常量（堆、指针、复杂数据结构），检查就退化。
• 它不能防止逻辑漏洞、UAF、TOCTOU 等更高层问题。
• 它依赖编译器的"推导能力"，GCC 版本不同，覆盖范围也不同。

所以你在真实项目中看到某个程序开了 FORTIFY，并不能说明它安全，只能说它堵住了一类低水平错误。而做 CTF 的时候，出题人开 FORTIFY 往往不是想让你"无解"，而是想考察你能不能发现"编译器的盲区在哪里"。

CTFshow pwn 033 这道题放在整个 FORTIFY 系列里属于 Level 1，本质上就是让你先学会识别和确认这个机制。过了这关，后面遇到 FORTIFY 更复杂的变体（比如 FORTIFY + 堆利用、FORTIFY + 逻辑绕过），你至少有一个正确的分析框架，不会一上来就对着__strcpy_chk发呆。

最后再分享一个实操习惯：遇到未知二进制时，我习惯先运行一遍加长的输入，观察它是在输入函数返回后崩溃，还是在输入函数内崩溃。在前者，说明 FORTIFY 没拦住这次写入；在后者，很可能就是__chk_fail被触发了。这种黑盒观察配合 IDA 静态分析，能让你在几分钟内判断出题目的核心保护是什么、该从哪里下手。希望这篇能帮你在 FORTIFY 这道坎上顺畅跨过去，继续往下打也不慌了。