拿到一个栈溢出崩溃样本，编写第一反应不是漏洞利用写 exploit，而是代码先搞清楚这个崩溃能不能稳定复现。我见过太多人一上来就对着内核 dump 猛写 ROP chain，时需结果发现触发条件依赖堆风水，注意换台机器就废了。编写稳定性永远排在利用成功率前面——一个 50% 成功率但每次都能跑通的漏洞利用漏洞，比 95% 成功率但重启就崩的代码漏洞有价值得多。

确定可复现之后，时需得判断漏洞类型。注意栈溢出、编写堆溢出、漏洞利用UAF、代码类型混淆，时需每种对应的注意利用路径完全不同。UAF 你得先想好怎么控制释放后的那块内存，是占位还是喷射。堆溢出则要看分配器行为——glibc 的 tcache 和 fastbin 差异巨大，2.31 和 2.35 的利用手法几乎不通用。别拿着一篇 2019 年的博客就去打 2024 年的目标，先 ldd --version 看一眼。

写代码的时候，硬编码地址是大忌。ASLR 开着的情况下，任何绝对地址都活不过一次重启。泄露信息这一步必须做扎实：格式化字符串、堆地址回显、部分覆写，能拿到什么就用什么。我曾经调试一个 CTF 题，泄露出来的 libc 基址低 12 位始终为 0，说明页对齐没问题，但高 4 位每次不同——那就只能爆破 1/16 的概率，这种时候 exploit 里得写重试循环，而不是假设一次成功。

偏移计算别靠猜。用 cyclic 模式跑一遍，看崩溃时 EIP/RIP 被哪四个字节覆盖，这是基本功。但堆漏洞的偏移往往更隐蔽——chunk size 字段被改了多少、next 指针偏移几个字节，这些得结合源码或反汇编确认。我习惯在 gdb 里挂 pwndbg，手动 heap 命令看 chunk 布局，比盲调快得多。

Payload 构造阶段，注意坏字符。\x00、\x0a、\x0d 经常被输入函数截断，写 shellcode 或 ROP 链之前先确认哪些字节能安全传输。遇到 strcpy 这种遇到 \x00 就停的函数，地址里带零字节的 gadget 直接排除。别等 exploit 跑飞了才回头查这个。

还有一点常被忽略：目标环境的 libc 版本和实际加载的库是否一致。本地调试用系统 libc，远程靶机可能是 musl 或者旧版 glibc，one_gadget 的约束条件完全不同。最稳妥的办法是把目标 libc 拖下来，用 patchelf 指定加载，本地复现远程环境。否则你本地打通了，远程一发就 segfault，白忙活。

最后，别追求一步到位的 getshell。先拿到可控的 RIP，再想办法执行 system("/bin/sh")，中间每一步都验证。我写 exploit 的习惯是每完成一个阶段就单独跑一次，确认寄存器状态符合预期再往下走。这样出问题的时候，你知道是哪一步崩的，而不是对着几千字节的 payload 发呆。