ruzzy
作者 trailofbitsruzzy 是一款面向纯 Ruby 代码和 Ruby C 扩展的、基于覆盖率引导的 Ruby fuzzing 技能。使用 ruzzy 指南可搭建受支持的 Linux 环境、验证 sanitizer 接线是否正确，并为 Security Audit 工作流构建实用的 fuzzing 流程。
该技能得分 82/100，适合需要 Ruby fuzzing 指南的用户收录。仓库明确了目标、使用场景和可运行的快速开始，方便代理快速判断是否匹配。不过它还不算开箱即用：在现有证据中，安装部分并不完整，也没有配套脚本或参考文件；但核心工作流已经足够完整，适合纳入目录。
- 明确聚焦于 Ruby 和 Ruby C 扩展的覆盖率引导 fuzzing，触发意图清晰。
- 包含基于内置 toy example 的具体快速开始测试，便于代理验证技能是否可用。
- 提供了实用的安装前置条件和平台支持说明，降低采用时的试错成本。
- 现有证据中看不到安装命令，因此配置过程可能仍需要人工理解。
- 该仓库看起来只是单个 SKILL.md，没有脚本、参考资料或资源文件，限制了更深入的操作指导。
ruzzy 技能概览
ruzzy 是用来做什么的
ruzy 技能帮助你使用 Ruzzy——一个基于 libFuzzer、采用覆盖率引导的 Ruby fuzzing 工具。它面向那些想对 Ruby 代码，尤其是 Ruby C 扩展，进行 fuzzing，并借助 sanitizer 做崩溃检测的人。如果你需要的不是随便扫一眼仓库，而是一条更具体的 ruzy install 和使用路径，那么这个技能更适合安全测试工作，而不是通用的 Ruby 自动化。
适合哪些人使用
如果你属于下面几类人，就适合使用 ruzzy 技能：
- 测试带原生扩展的 Ruby gem
- 查找 Ruby C 代码中的内存破坏或未定义行为
- 用 fuzzing 验证解析器、序列化器或输入处理路径
- 判断 Ruzzy 是否适合 Security Audit 工作流
如果你只需要单元测试、简单的性质测试，或者不针对原生代码目标的黑盒应用测试，那么它的价值就没那么高。
它的不同之处
Ruzzy 的定位是 Ruby 覆盖率引导 fuzzing 的可用于生产的方案。实际区别在于，它会从代码覆盖率和 sanitizer 中给你反馈，因此比“随便扔随机输入试试”的通用做法更擅长发现硬崩溃。主要代价是配置成本：你需要合适的 Ruby、clang 和 Linux 环境，而且目标本身也必须是真正能被 fuzz 的。
如何使用 ruzzy 技能
安装并验证环境
进行 ruzy install 时，先从该技能和仓库里的 SKILL.md 开始。仓库说明 Ruzzy 支持 Linux x86-64 以及 AArch64/ARM64。对于 macOS 或 Windows，你需要用 Dockerfile 或开发环境方案，而不是原生安装。
一个实用的安装检查可以这样做：
export ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0:use_sigaltstack=0"
LD_PRELOAD=$(ruby -e 'require "ruzzy"; print Ruzzy::ASAN_PATH') \
ruby -e 'require "ruzzy"; Ruzzy.dummy'
如果这个测试运行按预期崩溃，说明构建和 sanitizer 的接线是正确的。
把模糊目标转成可用提示
要获得好的 ruzy usage，不要只笼统地说“帮我 fuzz 我的 gem”。你需要给技能足够多的信息，让它能选出入口点和 harness。最好包含：
- 目标 gem 或仓库名
- 你是在 fuzz 纯 Ruby 还是 C 扩展
- 要驱动的方法、解析器或 API
- 样例输入格式
- 你更关注崩溃、卡死还是覆盖率增长
更好的输入示例：
“请用 ruzzy 为这个 Ruby C 扩展做 Security Audit。目标是
MyGem::Parser.parse，它接收字符串 payload，并且可能进入原生代码。请帮我搭一个最小 harness，并为畸形的类 JSON 输入准备 seed corpus。”
仓库里先看什么
先看 SKILL.md，然后重点检查这些部分：
- When to Use
- Quick Start
- Installation
- Platform Support
如果你需要调整工作流，先读安装命令和仓库内联引用，再把示例照搬到自己的项目里。最大的上手阻碍通常是平台不匹配，或者 fuzz 的抽象层级选错了。
实战中有效的工作流
一个靠谱的 ruzy guide 流程是：
- 确认平台以及 Ruby/clang 依赖条件
- 验证 ASAN preload 配置
- 选择一个小而稳定的入口点
- 围绕这个入口点构建最小 harness
- 先短时间 fuzz，再逐步扩大覆盖面
如果是 Security Audit 工作，初始范围要尽量收窄。一个边界清晰、稳定的目标，通常比一口气 fuzz 整个应用面更有价值。
ruzzy 技能 FAQ
ruzzy 只适合原生扩展吗？
不是。这个技能既支持纯 Ruby 代码，也支持 Ruby C 扩展，但当原生代码参与时，它的优势最明显。如果你的目标只是应用逻辑测试，普通测试套件或基于性质的测试可能更简单。
ruzzy 安装难吗？
在受支持的 Linux 系统上，ruzy install 路径本身比较直接，但环境细节很关键。clang、Ruby 和 sanitizer 配置必须彼此匹配。如果你在 macOS 或 Windows 上，通常要用 Docker 或开发环境，而不是直接原生安装。
什么时候不该用 ruzzy？
如果目标无法被反复驱动、你没法隔离出稳定的输入入口点，或者代码高度依赖外部服务，就不该用 Ruzzy。这种情况下，fuzzing 信号会很弱，配置成本也会大于收益。
初学者适合用吗？
适合，但前提是你已经知道要测哪个函数或解析器。如果你还在摸索目标面，Ruzzy 不是最容易上手的第一个安全工具。初学者最好的起点是先跑玩具示例，再逐步改造一个小 harness。
如何改进 ruzzy 技能
把目标收窄
质量提升最大的地方，就是把目标收窄。不要只说“fuzz my gem”，而是明确到具体可调用面、期望输入类型和你关心的失败类型。比如，“找出 decode(input_string) 在处理畸形 UTF-8 和嵌套分隔符时的崩溃”就比泛泛的请求强得多。
用真实输入和边界情况做 seed
当你提供有代表性的 seeds 时，Ruzzy 往往能得到更好的结果，尤其是目标输入具有结构化特征时。建议包括：
- 3–10 个有效样例
- 畸形变体
- 边界样例，比如空字符串、超大 buffer、截断数据
这一点比长篇说明更重要，因为初始语料会直接塑造探索路径。
围绕崩溃、卡死和覆盖率持续迭代
第一次运行后，先改进 harness，再去扩展运行时长。如果看到崩溃，就提取最小复现；如果看到卡死，就收紧超时并简化状态；如果覆盖率停滞，就减少初始化开销，并从 harness 中移除不必要的依赖。ruzy usage 真正对 Security Audit 工作产生效果，靠的就是这种反馈闭环。