用途：对比同一二进制文件（DLL、ELF、驱动）在补丁前后的版本，找出安全更新改动了什么，将 CVE 公告或补丁公告转化为具体的易受影响代码，评估新版本中的“静默修复”是否关闭了安全漏洞。
适用与不适用：需要同一二进制文件的两个版本（架构相同，最好编译器相同）。仅分析单个无补丁对照的二进制，应使用 analyzing-binaries；构建实际利用程序，属于 exploiting-memory-corruption 或相关 Web 技能；只有源码差异（如 GitHub 提交、变更日志）时，用 reviewing-code-changes；二进制需先脱壳时，先用 unpacking-protected-binaries。
获取两个可对比的二进制：微软自 Windows 10 起补丁以正向/反向增量下发，MSU 中为压缩增量而非完整 DLL，需先展开 MSU/cab 并把增量应用到基线二进制上重建完整补丁文件（PatchExtract / delta_patch.py 方式，驱动 msdelta API）；直接对比原始增量或基线不匹配会产生垃圾结果。其他软件通常可直接对比两个发布构建或两个包版本。
寻找变更函数：使用二进制比较工具并按相似度而非从上到下阅读结果。BinDiff（开源，通过 IDA 或 Ghidra 的 BinExport）匹配函数并给出相似度分数，关注略微变化（相似度略低于 1.0）的函数，而非全新或消失的函数；Diaphora（IDA）提供同样能力并有伪代码差异视图；ghidriff 提供基于 Ghidra 的可脚本化无头/CI 式比较。注意噪声：编译器变化、函数重排或无关功能会放大差异，ASLR 和地址偏移不是真实改动，应过滤出逻辑变化。
读修复、还原漏洞：新增代码是线索。常见形态包括：拷贝或索引前新增边界或长度检查（补丁前存在溢出或越界）、符号性或整数变化（如改用 size_t、增加溢出检查，指向整数缺陷）、新增空指针/状态检查（指向 UAF、竞态或未初始化使用）、对解析输入的字段/类型标签/长度做校验（解析器信任了攻击者可控数据）、释放后重排或置空（UAF 或双重释放）。阅读补丁后函数确认新增约束，再看补丁前函数确认约束缺失，这一对即漏洞。
反向推导触发条件：变更函数只是线索，需追踪攻击者可控输入如何到达补丁前代码（哪个 API、消息、文件字段或数据包，处于何种状态）。若无法从不信任输入构造到该代码的路径，可能只是加固而非可达漏洞，应如实说明。路径成立时，该可达触发即交给漏洞利用开发。
阅读外部资料：可用 curl -sL "https://defuddle.md/<url>" 以 Markdown 获取公开公告、规范和厂商报告（路径中协议可选），会剥离页面样板并返回全文。不适用于：JSON 和 API 响应需直接原始获取；需认证或 JavaScript 渲染的页面应直接获取；不得将对手基础设施（钓鱼链接、C2、恶意软件托管）、客户主机或交战 URL 经此转发，请求会离开本机到第三方，且会暴露给对手运营者。部分站点会拦截提取器并返回错误块（例如来自 freedesktop.org 的 {"error":"Failed to fetch: 418 I'm a teapot"}），这是获取被拒，不是来源不存在，应直接重新获取 URL 再下结论。
常见误区：200 个变更函数多数是编译器与布局噪声，按相似度排序过滤逻辑变化，安全修复通常只有一到几个函数；直接对比 MSU 会得到无意义结果，Windows 下发的是增量，需先重建完整补丁二进制；函数变化不等于漏洞，需证明可达性；公告说 RCE 不代表就是该 RCE，应从新增检查确认缺陷类别；同一漏洞不代表旧利用仍有效，修复可能改变相邻代码、偏移和对象布局，需针对实际持有的补丁前构建重新确认原语。