缓冲区溢出攻击不显式标记，需通过segmentation fault、stack smashing detected、堆损坏提示等异常信号及core dump中eip异常、栈内可疑字符串等内存破坏痕迹综合识别。
直接看日志本身通常找不到“缓冲区溢出攻击”字样——这类攻击不留下明文标记，而是通过异常行为和内存破坏痕迹间接暴露。关键不是找关键词，而是识别程序崩溃背后不符合正常逻辑的内存异常模式。
重点排查崩溃日志中的三类典型信号
打开系统日志（如 /var/log/syslog 或 dmesg -T 输出），逐行扫描以下特征：
- Segmentation fault (core dumped) 或 signal 11：这是最常见线索，尤其当同一进程在短时间内反复出现，且崩溃地址高度可疑（如落在栈段、堆段或未映射区域）
- *** stack smashing detected ***：说明程序启用了 -fstack-protector，该提示是栈保护器主动拦截溢出的铁证，不是误报
- “corrupted size vs. prev_size” 或 “malloc(): unsorted double linked list corrupted”：指向堆溢出，常见于使用 malloc+strcpy 组合且未校验长度的场景
结合 core dump 进行内存现场还原
若系统生成了 core 文件（确认 ulimit -c 非零），用 gdb 加载分析：
- 运行 gdb ./target_binary core，输入 info registers 查看 esp/ebp/eip 是否明显异常（如 eip 指向栈地址 0xbffffxxx 或堆地址 0x0804axxx）
- 执行 x/20xw $esp 查看栈顶附近数据，观察是否有连续可读字符串（如 “AAAA…”，“\x90\x90\x90…”）或疑似 shellcode 的机器码片段
- 用 bt 查回溯，确认崩溃是否发生在 gets、strcpy、sprintf 等危险函数调用之后
交叉验证运行时环境与程序配置
单看日志容易误判，必须同步检查程序本身的防护状态：
- 用 checksec --file=./target_binary 检查是否关闭了 NX bit（栈/堆可执行）、ASLR（地址随机化）、stack canary —— 全关环境极利于溢出利用
- 用 objdump -d ./target_binary | grep "gets\|strcpy\|sprintf" 定位是否调用高危函数，再结合源码确认有无长度校验
- 查看服务启动方式：是否以 root 权限运行？是否监听外部网络端口？这两点决定攻击成功后危害等级
排除常规原因，锁定可疑输入路径
缓冲区溢出必有超长输入，需逆向追踪数据来源：
- 若为网络服务，检查对应端口的历史连接记录（netstat -tulnp + tcpdump -w capture.pcap port XXX），筛选出发送超长 payload 的 IP
- 若为本地命令行工具，检查 shell 历史（history）或审计日志（ausearch -m execve -i | grep target_binary）
- 特别注意含空字节（0x00）的崩溃——gets 和 strcpy 遇到它会截断，但攻击者常故意构造含 0x00 的 payload 来绕过某些简单过滤
