企业官网建设流程全解析

从崩溃到代码执行：Exploitarium中的PoC到底证明了什么？

【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and I've always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium

Exploitarium是一个开源的漏洞研究档案库，集中收录了公开发布的利用概念验证（PoC）与研究笔记，覆盖 FFmpeg、OpenSSH、Docker、Redis、libssh2 等知名项目。它不只告诉你"程序会崩溃"，而是用精心构造的 PoC 一步步证明：从崩溃走到可控代码执行，每一步到底证明了什么。

为什么"崩溃"不等于"漏洞被利用"

很多新手第一次看到崩溃报告时会产生误解：程序报错了，漏洞就"被打穿"了吗？

答案是否定的。安全研究中的 PoC 其实有三个层次，强度逐级递增：

💡 在 Exploitarium 中，大量 PoC 属于第二层——它们不做危险的事，只是"打开计算器"或"写一个标记文件"。这种良性验证（benign proof）是负责任漏洞研究的标准做法：既证明了代码执行可控，又不会造成破坏。

一个典型 PoC 长什么样：objdump 的计算器证明

以 objdump-dlx-calc-poc/ 为例，它演示了一条经典的"本地解析器崩溃转代码执行"路径：

1. 攻击者构造一个恶意的 ELF/DLX 目标文件（即payloads/目录下的一批二进制载荷）；
2. 受害者只用objdump -g查看这个文件；
3. objdump 解析时触发越界写入，最终执行到攻击者安排的代码——打开计算器。

这条链的巧妙之处在于：payloads/ 里有多组载荷文件，是因为在 ASLR 开启的情况下，单个载荷不能保证每次都命中，所以用多组"地址猜测"配合重试循环来提高成功率。详细分析见 docs/aslr-bypass-analysis.md。

🔍 对新手来说，重点不是背下每个偏移量，而是理解这个思路：崩溃 → 控制寄存器 → 调用系统函数，这是内存破坏利用的通用骨架。

每个目录里的 evidence 文件夹：证明的可信度

翻看仓库会注意到，不少 PoC 目录下都有一个evidence/文件夹，比如：

• evidence/local-verification.txt —— 本地验证过程记录
• evidence/stock-openssh-10.4p1.txt —— 官方原版 OpenSSH 上的复现输出
• SHA256SUMS.txt —— 文件校验和

这些文件的作用是可复现性证明：记录了测试的目标版本、构建方式、运行输出和哈希值。它回答的正是标题中的问题——"这个 PoC 到底证明了什么？"不是口头声称，而是"在我这个环境、这个版本、这份输出里，它成立"。

从 PoC 清单看漏洞研究的版图

仓库 README.md 中列出了全部条目，大致可以归为几类，也正好是一张漏洞研究地图：

• 🧩内存破坏类：FFmpeg 解码器越界写（ffmpeg-rasc-dlta-calc-poc/）、c-ares 释放后使用（c-ares-tcp-uaf-calc-poc/）——练习"崩溃到控制"的核心基本功
• 🌐Web 与协议类：Discourse 预认证绕过（discourse-scoped-api-key-preauth-bypass/）、Gitea/Gogs 的 Runner 与 Hook 利用（gitea-act-runner-container-options-poc/）
• 🐳容器与系统类：docker cp拷贝路径逃逸（docker-cp-copyout-destination-escape/）、OpenSSH agent 状态绕过（openssh-agent-lock-provider-bypass/）
• 🖥️桌面与应用类：Firefox RCE 链（firefox-152.0.6-stock-page-native-calc-poc/）、RustDesk 会话降级（rustdesk-session-permission-pocs/）

特别值得留意的是 docker-cp-copyout-destination-escape/README.md，它明确区分了"这是什么"和"这不是什么"——不是无交互逃逸、不是内核漏洞。这种精确界定 PoC 边界的写法，本身就是研究素养的体现。

新手如何阅读这个仓库

📚 给入门者的一条学习路线：

1. 先读cves.md（cves.md）：基于此仓库的研究已获 12 个 CVE 编号，证明 PoC 与正式漏洞报告之间的真实联系；
2. 挑一个"计算器"PoC 精读：比如 poc/cares_tcp_uaf_calc_poc.c，看它如何"良性地"证明代码执行；
3. 对照 evidence 验证：理解验证记录里每一项（版本、commit、输出）的意义；
4. 再挑战协议类 PoC：如 poc.py，体会通过合法协议命令完成完整利用链的难度。

安全提醒

⚠️ 仓库 README.md 中有明确的 ABUSE 声明：请勿在任何情况下将这些 PoC 用于恶意目的。这些内容属于善意公开披露的漏洞研究，目的是引导更多人进入安全研究领域。如果你复现了某个尚未修复的问题，不妨自己走一遍漏洞报告流程——作者也在 README 里"欢迎你来申报 CVE 并署名"。

总结：Exploitarium 中的每个 PoC 都是一份"证明文书"——它用可复现的最小实验，精确回答了从崩溃到代码执行链条上"当前证明了哪一环"的问题。对新手而言，它是比任何理论教程都直观的安全研究教材。

【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and I've always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium