摘要
7884 结构归纳推理引擎是一套从二进制样本中自动推断协议与文件格式结构定义的软件系统。它不依赖预置的格式模板，而是通过对多个样本进行横向比较、特征分析和统计归纳，逐步逼近样本背后真实的结构规则。引擎采用 32 阶段自适应管线架构，集成了感知分析、结构归纳、自反驳验证、蒙特卡洛搜索、知识迁移等能力，并可直接输出模糊测试脚本，形成"分析—归纳—验证—测试"的完整工作闭环。
本文档面向技术决策者与安全研究人员，介绍 7884 引擎的设计思路、系统能力边界、工程特性及其在格式逆向领域中的定位。文中所述内容均基于公开可验证的工程事实，不涉及核心算法推导与内部实现细节。
一、背景与问题域
在网络安全、数据恢复、数字取证和协议逆向工程等领域，分析人员经常面临一个共同的难题：面对一个未知的二进制文件或网络协议数据流，如何快速理解其内部结构——哪些字节是头部字段，哪些是数据载荷，字段之间存在怎样的约束关系？
传统做法通常有两种路径：一是依靠人工经验逐字节观察分析，效率低且易出错；二是使用基于已知格式模板的解析工具，但这类工具只能处理已收录的格式，对新格式或私有格式无能为力。
7884 引擎尝试提供第三条路径：不预设模板，而是让机器从样本中"观察"和"归纳"。给定一组同类样本，引擎尝试回答几个基本问题：
- 样本中哪些位置存在确定的字段边界？
- 不同字段之间是否存在大小、偏移或数值上的关联？
- 是否存在可重复出现的结构模式（如 TLV、记录数组）？
- 哪些区域可能是载荷数据，哪些是结构化元信息？
- 字段间的校验和覆盖范围与算法是什么？
这些问题并不容易回答，7884 引擎目前的回答质量也远非完美。但它在持续的工程迭代中逐步缩小了"人工分析"与"自动推断"之间的差距，这是本文档希望如实记录的内容。
二、设计理念
2.0 愿景与定位
安全行业在过去几十年中投入了大量精力为已知格式编写解析器、模板和规则——本质上是在给已知格式"追债"。每出现一种新格式或私有协议，分析人员就需要从零开始人工逆向。7884 引擎尝试回答的问题是：能否让机器自动完成这一过程？
我们的目标是将任意未知二进制文件自动转化为结构化描述——不是对已有工具的改良，而是探索一条不同的技术路径。
不限格式
不预设任何格式的结构模板。引擎通过通用归纳机制处理样本，无论它是公开标准还是从未见过的私有协议。内置的格式特征库仅用于初步识别线索，不提供结构定义。
不靠人写规则
不需要用户编写二进制模板（BT）、结构定义（KSY）或模糊测试脚本（Peach XML）。引擎从样本中自行归纳。
不是分析，是制造
引擎的输出不是一份"分析报告"，而是可直接用于下游工具链的结构化产物——010 Editor 模板、Peach 脚本、Kaitai 定义、YARA 规则等。
我们不认为自己在和谁竞争。手工模板工具、模糊测试引擎和 LLM 方案解决的是不同层面的问题——不是更好，是不同。如果一定要说有什么对手，那唯一的对手是"品类认知"——让更多人理解"自动结构归纳"这件事本身的价值。关于与各类方案的具体差异，请参见第十五章。
2.1 通用启发式，而非专有模板
7884 引擎在架构层面确立了一条核心原则：禁止为任何特定格式编写专用解析代码。这意味着引擎不会内置 BMP 头部解析器、不会预设 ELF 格式布局、不会为任何已知或未知格式安排"特例"处理路径。所有格式推断能力的提升，必须通过改进通用的启发式算法来实现。
这一设计的考量在于：专有格式解析虽然能快速获得高精度，但无法迁移到未知格式；而通用启发式方法虽然起步艰难，但一旦积累起足够的归纳能力，就能覆盖任意格式——包括那些尚未被收录或从未公开的私有协议。
2.2 数据驱动，而非规则驱动
引擎内部维护了一个包含 20,085 种文件格式特征的轻量级数据库。需要说明的是，这个数据库并不存储每种格式的完整模板定义，而是记录格式的 Magic 签名、典型偏移模式、常见约束关系等外围线索。这些线索的作用类似于"提示"而非"答案"——引擎据此调整通用归纳策略的方向，而不是直接套用预先定义好的格式结构。
2.3 置信度驱动，而非二元判断
在结构归纳过程中，引擎不做"这个字段一定是什么"的绝对判断，而是为每个推断结果赋予一个置信度分数。系统内部设有从"早期探索"到"收敛稳定"的多级状态，只有当多个维度的证据指向同一结论时，引擎才会将结果标记为可用。这种设计允许引擎在信息不足时保持审慎，在有足够证据时才做出判断。
2.4 闭环验证，而非单向输出
引擎的设计目标不是仅输出一个结构定义就结束，而是构建一个"分析—归纳—验证—测试"的完整闭环。归纳出的结构定义可以直接用于模糊测试样本生成，生成的样本又可以反过来验证结构定义的正确性。这种闭环设计使得引擎的输出不再是"一次性结论"，而是可以被持续验证和改进的"工作假设"。
2.5 零先验：纯黑盒路线
7884 引擎在架构层面确立了一项根本性的约束：不从目标程序中获取任何信息。它不需要源码、不需要可执行文件、不需要插桩、不需要调试符号、不需要运行时日志，甚至不需要知道目标程序是什么语言编写的。
引擎的全部知识来源只有一个——样本本身。这意味着在以下场景中，7884 是少数仍然可用的方案：
- 闭源固件中的未知格式（无源码、无反汇编条件）
- 嵌入式系统中的私有协议（无法插桩、无法接入覆盖率反馈）
- 已停止维护的遗留系统中的数据格式（无可执行程序）
- 加密隧道内部的协议结构（仅有样本，零上下文）
选择这条路径的代价是巨大的。没有覆盖率反馈指引方向，没有运行时信息帮助验证，引擎必须在黑暗中独自摸索。相比之下，插桩引导的灰盒方案在短期回报上远远领先。
然而我们相信：纯黑盒才是未来 20-50 年的主流方向。原因有三：
- 安全对抗不断升级 — 未来的目标系统将更加封闭、更加碎片化，插桩条件越来越苛刻，而纯黑盒方案在任何场景下都能启动。
- AI 能力的底层制约 — LLM 等上层智能系统的输入质量受限于底层数据的结构化程度。纯黑盒自动结构归纳可能是 AI 大规模进入安全领域的"最后一公里"基础设施。
- 规模化的必然要求 — 人工编写模板的方式无法跟上格式爆炸的速度。纯黑盒方案是唯一具备规模化潜力的路径——不依赖人类的领域知识，只依赖样本本身。
我们很清楚当前纯黑盒归纳的质量远不如插桩辅助方案，也知道这条路可能需要十年甚至更长时间才能走通。但这正是我们选择它的原因——如果纯黑盒结构归纳这条路能走通，它解决的问题是目前任何其他方案都无法替代的。我们愿意把赌注押在这条赛道上。
三、系统架构概览
7884 引擎采用管线化架构设计，输入样本依次经过多个处理阶段，每个阶段负责一个独立的推断任务。整体架构可划分为以下层次：
输入层
样本加载、容器穿透（ZIP/GZIP/TAR）、预解码
感知层
数据区域检测、文本分类、编码识别、格式轮廓感知
归纳层
结构聚类、字段分析、关系发现、候选生成与融合
推理层
蒙特卡洛搜索、自反驳验证、交叉验证、贝叶斯推断
输出层
多格式结果生成（二进制模板、模糊测试脚本、可视化报告等）
知识层
增量学习、历史知识迁移、先验知识集成、格式特征库
管线由调度器（Pipeline Orchestrator）统一管理，根据样本特性动态决定各阶段的执行策略——部分阶段始终执行，部分阶段仅在条件满足时触发，还有部分阶段按需调用。这种设计避免了对所有样本一刀切地执行全部流程，从而在一定程度上控制了不必要的计算开销。
完整工作流
从样本输入到模糊测试，形成可验证的完整闭环
四、归纳管线
引擎的核心归纳过程分为 32 个可独立调度阶段。以下仅从功能角度描述其宏观流程，不涉及各阶段内部的具体算法实现。
| 阶段 | 类别 | 功能描述 |
|---|---|---|
| 样本加载 | 始终执行 | 多线程加载样本，提取基础特征（熵值、类型识别、浮点检测、变长边界推断） |
| 容器穿透 | 条件触发 | ZIP/GZIP/TAR 递归解包，压缩炸弹防护 |
| 感知分析 | 始终执行 | 数据/文本区域感知，熵曲线分析，格式轮廓识别 |
| 聚类 | 自适应 | 根据样本相似度进行聚类分组（支持多种聚类算法） |
| 字段分析 | 自适应 | 字段边界检测、模式识别、类型推断 |
| 关系发现 | 自适应 | 字段之间的数值、偏移、大小等约束关系探索 |
| 嵌套搜索 | 自适应 | 深层嵌套与重复结构检测（TLV、自引用、循环） |
| 自反驳 | 条件触发 | 尝试用已有结论否定自身，检验推断的鲁棒性 |
| 搜索优化 | 条件触发 | 蒙特卡洛树搜索，探索候选结构空间 |
| 候选融合 | 条件触发 | 多候选结构的集成与投票合并 |
| 数据合并 | 条件触发 | 置信度驱动的字段合并决策（合并/封装/保持独立） |
| 评估与排名 | 始终执行 | 多维度质量评估，结果排序与输出 |
| 增量学习 | 条件触发 | 知识持久化与历史经验迁移 |
* "自适应"表示引擎根据样本复杂度与中间结果的置信度自动决定是否执行该阶段。
五、感知分析能力
感知分析是管线的前置环节，负责在进入复杂归纳流程之前，对样本进行初步"体检"。引擎在这一环节主要完成以下工作：
数据区域感知
基于熵曲线（256 字节窗口）和多种步长检测策略，识别载荷区域、容器的可能边界。支持 44 种格式轮廓的初步识别和容器模式检测（PE、ELF、Mach-O）。
文本感知
对样本中的文本区域进行分类（30 种以上的文本格式类别），检测编码类型（UTF-8、UTF-16、GBK 等），提取文本结构特征。
区域优先级管理
当样本中不同区域类型发生重叠时，按"文本 > 载荷 > 二进制"的优先级进行裁决，并提供细粒度的区域子类型分类（头部/载荷/调色板/表格/二进制）。
加密/压缩检测
基于统计特征判断样本是否经过加密或压缩处理，避免在不可分析区域上浪费计算资源。
六、容器穿透能力
许多实际场景中的二进制样本并非"裸格式"，而是被封装在容器（如 ZIP、GZIP、TAR）内部。引擎内置了容器穿透能力，能够递归解包嵌套容器，暴露其中的真实数据。
| 功能 | 实现概况 |
|---|---|
| DEFLATE 解压 | 完整实现 RFC 1951（支持 Stored / Fixed Huffman / Dynamic Huffman） |
| 容器格式 | ZIP、GZIP、TAR 完整解包，含 CRC32 校验 |
| 递归穿透 | 最大支持 16 层嵌套解包 |
| 安全防护 | 压缩炸弹防护：100 MB 单文件上限 / 1 GB 总量上限 / 1000:1 最大压缩比 / 1000 成员上限 |
| 重打包 | 支持 GZIP STORE 方法与 ZIP 成员替换，用于模糊测试样本的加壳输出 |
容器穿透能力的意义在于：协议逆向的样本往往来自真实网络流量或文件系统，直接暴露在容器外层的可能性很低。如果引擎只能分析"裸格式"，其实用价值将大打折扣。
七、验证与自反驳机制
结构归纳的输出是否可信，取决于验证机制的严谨程度。7884 引擎在验证环节投入了较大的工程努力，构建了多层次的验证体系。
7.1 自反驳验证
自反驳是 7884 引擎中一个较为独特的验证机制。其核心思想是：在得到一个归纳结论后，引擎会主动尝试寻找证据来否定这个结论。如果反驳失败（即找不到足够强的否定证据），则结论的置信度得到增强；如果反驳成功，引擎会降低该结论的置信度或将其标记为不确定。
这种"以己之矛攻己之盾"的思路，与科学方法论中的"可证伪性"原则一脉相承。它使得引擎的输出不是"因为没发现错误所以正确"，而是"因为尝试了否定但未成功，所以暂时可信"——两者的认识论基础是不同的。
7.2 交叉验证
引擎支持从不同的归纳路径出发，独立得出各自的结论，然后比较这些结论之间的一致程度。如果多条路径指向相同或高度相似的结构定义，则结果的可靠性自然更高。这种机制在样本数量充足时效果更为明显。
7.3 合并质量验证
引擎在字段合并环节设有独立的质量验证阶段，通过精确率、召回率和 F1 分数三个指标来评估合并决策的质量。这一验证机制确保了合并操作不会导致结构信息的非预期丢失。
八、关系发现能力
字段间的约束关系是格式定义中最有价值的信息之一。一个字段表示另一个字段的大小、某个字段指向另一个字段的偏移、两个字段的值满足某种数学关系——这些约束关系的发现，能够将零散的字段定义串联成有机的结构描述。
7884 引擎目前支持 26 种关系类型的自动发现，涵盖以下几大类：
关系发现模块的输出会同时标注置信度，只有达到一定阈值的关系才会被纳入最终的结构定义。这一机制在 V10 版本中经历了较大幅度的重构——关系类型从 12 种扩展到 26 种，同时在 10 组 71 个标注关系的测试中，召回率从 70.4% 提升至 97.2%，误报率从 8.2% 降至 4.0%。
九、先验知识集成
7884 引擎支持与外部先验知识系统（IFFA）的集成——这是一个可选的外部模块，由用户决定是否启用。7884 引擎将 IFFA 的输出作为归纳过程中的"参考意见"而非"标准答案"来使用。
9.1 可信度分级
引擎对 IFFA 提供的信息按可信度分为三级：
| 可信度 | 处理方式 | 典型场景 |
|---|---|---|
| HIGH | 高权重采纳，作为归纳过程的强线索 | Magic Token 识别、文件大小关系 |
| MEDIUM | 正常权重采纳，作为参考信息 | 固定偏移字段 |
| LOW | 忽略，不纳入归纳过程 | 重复结构/嵌套（可靠性不足） |
9.2 集成策略
IFFA 集成遵循"辅助而非主导"的原则：
- 样本要求 — 3-16 个样本时启用 IFFA 分析；少于 3 个样本时自动跳过
- ZIP 排除 — 通过扩展名和魔数双重检测排除 ZIP 格式（IFFA 对压缩格式分析效果不佳）
- 超时保护 — IFFA 分析限时 3 分钟，超时自动终止
- 回退机制 — 当引擎自身归纳质量极低时，生成 IFFA 参考报告供人工审阅
十、知识迁移与增量学习
7884 引擎具备知识持久化和迁移能力——本次分析获得的经验可以在后续分析中复用，从而在相似格式上获得更快的收敛速度和更高的归纳质量。
知识持久化
每次分析完成后，引擎可将归纳结果序列化保存。历史知识以贝叶斯先验的形式加载到后续分析中，为归纳过程提供初始倾向。
置信度衰减
历史知识在加载时自动应用 0.8 倍的置信度衰减，防止旧经验过度影响新分析。衰减机制确保引擎对新的证据保持开放态度。
负迁移保护
当历史知识与当前样本的特征差异较大时，引擎会降低其影响力，避免不相关的历史经验导致归纳方向偏移。
增量改进
随着对同一类格式分析次数的增加，引擎对该格式的归纳质量通常会逐步提升。这是一种渐进式的学习过程，而非一次性训练。
十一、质量评估体系
7884 引擎的自我评估体系以 OVERALL 评分为核心，从多个维度衡量归纳结果的质量。引擎内部和外部评估分别采用不同的指标体系。
11.1 引擎内部评分
OVERALL 评分由五个维度加权构成：
引擎将评分结果映射为五个状态：收敛稳定（≥90%）、持续进步（≥70%）、仍在搜索（≥40%）、起步阶段（≥10%）和结构不稳定（<10%）。
11.2 外部评估框架
为客观衡量引擎输出的质量，我们建立了一套 12 项指标的外部评估框架，分四组对输出结果进行量化评分：
| 组别 | 指标 | 权重 | 评估内容 |
|---|---|---|---|
| A组 引擎健康 | R1 运行得分 | 10% | 退出码、输出文件完整性、JSON/XML 可解析性 |
| R2 语法合规 | 5% | 7 种输出文件的语法正确性 | |
| B组 结构完整 | R3 字段质量 | 15% | 头部字段保留率 + Payload 合并度（分区评分） |
| R4 头部保留 | 5% | 前 256 字节关键字段的保留情况 | |
| R5 关系保留 | 15% | 字段间约束关系的保留率 | |
| R6 语义保留 | 5% | 语义标签的一致性 | |
| C组 XML 质量 | R7 字节覆盖 | 15% | DataModel 对样本字节的覆盖比例 |
| R8 元素分布 | 5% | 元素类型的分布稳定性 | |
| R9 Fixup/Relation | 10% | 校验和修复与约束关系的保留 | |
| R10 属性退化 | 10% | 匹配元素的属性一致性 | |
| D组 综合评估 | R11 质量分 | 5% | 引擎自评质量分的变化趋势 |
| R12 多格式一致 | 5% | JSON 与 XML 输出的交叉验证一致性 |
该评估框架的一个设计特点是分区评分：将字段分为"头部字段"和"Payload 字段"分别评估——头部字段的合并意味着结构信息丢失（退化），而 Payload 字段的合并通常是正确的改进（减少碎片化）。这一区分避免了简单计数法对合并操作的误判。
十二、差分分析
当拥有多个同类样本时，引擎可以执行跨样本的差分分析，识别样本之间的结构差异。这一能力对于理解格式的版本演进、可选字段和变体结构具有实际价值。
引擎识别以下五类差分区域：
STABLE
跨样本稳定不变的区域
VARIABLE
值可变但结构固定的区域
INSERTION
部分样本独有的插入区域
DELETION
部分样本缺失的删除区域
VALUE_SHIFT
数值整体偏移的区域
差分分析的结果不仅输出为独立的差分报告，还会反馈到归纳管线中——稳定区域获得更高的结构置信度，可变区域被标记为候选的变长字段或可选字段。
十三、模糊测试工作流
7884 引擎的输出可以直接驱动模糊测试，形成"结构归纳 → 模糊测试 → 样本验证"的完整工作流。这是引擎设计中的一个重要闭环。
13.1 变异策略
引擎内置了 46 种变异策略，提供 Basic 和 Pro 两种引擎：
Basic 引擎
基础变异策略，覆盖常见的模糊测试需求：位翻转、字节替换、边界值插入、整数溢出等。
Pro 引擎
增强变异策略，利用结构定义中的关系信息和语义标签进行感知变异：基于 DiffType 的定向变异、数学公式关系感知变异等。
13.2 加壳输出
生成的模糊测试样本支持 GZIP 和 ZIP 加壳输出，使得测试样本可以直接用于测试那些需要从容器中读取输入的目标程序。
13.3 闭环验证
从结构归纳到模糊测试的完整闭环
十四、多格式输出
引擎的归纳结果可以通过多种格式输出，以对接不同的下游工具链：
010 Editor BT
二进制模板文件，用于 010 Editor 可视化浏览
Peach XML
模糊测试脚本，支持 46 种变异策略
Kaitai Struct
KSY 格式，可生成多语言解析代码
YARA
格式检测规则，用于样本识别与分类
Python
格式校验与约束验证脚本，含自动修复能力
HTML / JSON
可视化报告与结构化数据导出
输出格式的多样性考虑的是不同用户群体的工作习惯——安全研究人员、协议逆向工程师、模糊测试人员等各自使用不同的工具链，引擎不预设一种"最优输出"，而是尽可能覆盖主流工具的需求。
三种运行模式
| 模式 | 用途 | 输入 |
|---|---|---|
| Normal | 完整结构归纳分析 | 样本目录 |
| Fast | 从已有模型快速生成脚本 | 模型文件 + 单个样本 |
| Gen | 模糊测试样本生成 | Peach XML 文件 |
十五、定位与差异
7884 引擎的核心输出之一是模糊测试脚本，因此其最直接的竞争对象是模糊测试工具。以下将 7884 与当前主流的黑盒模糊测试方案进行对比，说明结构归纳路径带来的差异化价值。
15.1 与覆盖率引导模糊测试对比（AFL++ / libFuzzer / Honggfuzz）
AFL++、libFuzzer、Honggfuzz 等是当前最主流的覆盖率引导模糊测试工具。它们通过插桩目标程序获取代码覆盖率反馈，以此引导变异方向，在发现代码路径方面效率极高。
| 维度 | AFL++ / libFuzzer / Honggfuzz | 7884 引擎 |
|---|---|---|
| 测试前提 | 需要目标程序可执行且可插桩（白盒/灰盒） | 无需目标程序，仅需样本文件（纯黑盒） |
| 变异策略 | 覆盖率引导的随机变异（位翻转、算术、拼接等） | 结构感知变异（46 种策略，基于字段语义和约束关系） |
| 格式理解 | 不理解格式结构，变异是"盲目"的 | 先归纳结构再变异，变异"知道"字段边界和语义 |
| 校验和字段 | 随机变异大概率破坏校验和，导致样本被早期拒绝 | 自动发现校验和覆盖范围与算法，变异后自动修复 |
| 关系约束 | 无法感知字段间约束（如长度字段与数据区域的对应） | 26 种关系类型自动发现，变异时保持约束一致性 |
| 无源码场景 | 需 QEMU/Unicorn 模式模拟执行，性能损失严重 | 天然黑盒，不依赖目标程序执行 |
| 初始种子 | 需人工提供有效种子文件 | 从样本自动归纳结构，自动生成变异样本 |
15.2 与协议/结构感知模糊测试对比（Peach Fuzzer / Sulley / Boofuzz）
Peach Fuzzer、Sulley、Boofuzz 等是结构感知模糊测试工具，需要用户手工定义数据模型（DataModel）后才能开始测试。7884 引擎的模糊测试输出正是兼容这类工具的格式，但关键区别在于数据模型的来源。
| 维度 | Peach / Sulley / Boofuzz | 7884 引擎 |
|---|---|---|
| 数据模型来源 | 完全依赖人工编写 | 从样本自动归纳生成 |
| 模型编写成本 | 高——需要深入理解格式规范，耗时数小时到数天 | 低——提供样本后自动生成，数分钟内完成 |
| 未知格式 | 无法开始——没有规范就无法编写模型 | 可以直接启动——自动归纳提供初始模型 |
| 关系与约束 | 人工定义 size/count/offset 关系 | 26 种关系类型自动发现并注入 |
| 校验和修复 | 人工编写 Fixup 规则 | 自动发现校验和算法和覆盖范围，自动生成 Fixup |
| 迭代效率 | 格式变更需手动更新模型 | 重新分析样本即可更新模型 |
15.3 与 LLM 辅助模糊测试对比
近期，利用大语言模型（如 DeepSeek、GLM、GPT）辅助模糊测试成为一个活跃的研究方向。LLM 可以根据格式描述或样本生成变异策略，构成 7884 引擎在当前最值得关注的新兴竞争路径。
| 维度 | LLM 辅助模糊测试 | 7884 引擎 |
|---|---|---|
| 结构获取方式 | 从训练语料中"回忆"格式知识，或根据样本描述推测 | 从样本数值特征中归纳，不依赖训练语料 |
| 数值精度 | 字段偏移、大小等精确数值容易出错 | 数值级确定性输出，偏移/大小/关系均有确切值 |
| 一致性 | 同一输入多次生成可能产生不同模型 | 确定性管线，相同输入产生相同输出 |
| 多样本利用 | 通常单次处理单文件，多样本需人工编排 | 原生多样本横向比较，差分分析自动执行 |
| 私有协议 | 依赖训练数据中是否包含相似格式知识 | 不依赖训练数据，通用归纳机制直接分析 |
| 部署方式 | 需云端 API 或大显存 GPU | 本地单机运行，CPU 即可 |
| 输出形式 | 自然语言描述或代码片段，需人工整合到测试框架 | 直接输出 Peach XML / KSY / BT，开箱即用 |
| 上下文窗口 | 受 token 限制，大文件需截断或分片 | 无 token 限制，文件级完整分析 |
15.4 7884 引擎的独特定位
综合以上对比，7884 引擎在模糊测试领域的独特定位可以概括为：
- 零先验纯黑盒 — 不依赖源码、不依赖插桩、不依赖可执行程序，甚至不依赖任何目标程序信息。引擎的全部知识来源只有样本本身——在无法插桩或无可执行程序的场景下，这是少数仍然可用的方案。
- 结构感知而非盲目变异 — 先归纳格式结构，再基于字段语义和约束关系进行精准变异
- 自动建模而非手工编写 — 从样本自动生成 DataModel，无需人工编写模糊测试脚本
- 约束保持而非随机破坏 — 变异时自动维护字段间的大小、偏移、校验和等约束关系
- 闭环而非单向 — 归纳 → 模糊测试脚本 → 变异样本生成，完整闭环可验证
- 本地离线运行 — 无需云端 API，无需大显存 GPU，单机 CPU 即可完成分析
- 上游工具而非下游替代 — 7884 不试图替代任何现有工具。它位于模糊测试引擎的上游——为 Peach、AFL++、libFuzzer 等提供结构感知的输入，让这些工具在更好的起点上工作。
15.5 一些我们的理解
- 不追求替代覆盖率引导 — 7884 的结构感知变异与 AFL++ 的覆盖率引导是互补关系，不是替代关系。前者解决"变异什么"，后者解决"往哪变异"。
- 自动建模是起点而非终点 — 7884 自动生成的 DataModel 可以作为快速启动模糊测试的起点，但对于关键目标，仍建议在此基础上人工精调。
- 审慎优先于自信 — 当证据不足时，引擎倾向于输出保守的结果，而非强行给出可能误导的判断。
- 闭环优于单向 — 一个可以被模糊测试验证的结构定义，比一个无法验证的"完美"定义更有实用价值。
- 定义品类，而非跟随品类 — 我们不试图在现有工具的赛道上跑得更快，而是尝试开辟一条新的路径。这条路径是否正确、是否有足够的价值，需要时间和实践来回答。
- 押注纯黑盒 — 我们清楚地知道纯黑盒路径的回报周期远超灰盒/白盒方案，甚至在当前阶段它的输出质量远不如插桩辅助方案。但我们的判断是：安全对抗的终局一定是黑盒场景越来越多、插桩条件越来越苛刻。如果纯黑盒结构归纳这条路能走通，它解决的是未来 20-50 年的核心问题。我们选择把赌注押在这里，不是因为这条路容易，恰恰是因为它难。
十六、工程实现概况
编程语言
C11 (MSVC v143)，注重对底层二进制数据的直接操作能力
构建系统
MSBuild / Visual Studio 2022 (x64)
并行框架
OpenMP 2.0 + Win32 Threads，在多核 CPU 上实现并行加速
GPU 加速
CUDA 支持，在可用 GPU 上加速部分计算路径，自动在 GPU 与 CPU 之间切换
外部依赖
极简依赖：cJSON + SQLite3（amalgamation 内嵌），无需安装额外运行环境
格式特征库
内置 20,085 种常见文件格式特征（嵌入式 SQLite3 数据库，前缀树 O(k) 查找）
选择 C 语言而非更高级的语言，主要考虑的是对二进制数据的细粒度控制能力以及执行效率。代价是开发效率和代码可维护性不如高级语言，这是一个有意为之的取舍。
性能优化基线
引擎在关键路径上进行了多轮性能优化，以下是一次典型优化的效果记录：
| 模块 | 优化前 | 优化后 | 改善 |
|---|---|---|---|
| 交互式分析 | 14,902 ms | 1,147 ms | ↓92.3% |
| 结果生成 | 14,003 ms | 5,775 ms | ↓58.8% |
| 总耗时 | 32,024 ms | 17,789 ms | ↓44.4% |
* 以上数据来自特定测试场景，实际性能因样本复杂度和硬件配置而异。
十七、已知限制
以下列出当前版本已知的局限性和有意的设计取舍，供评估时参考：
Choice 分支推断
当前版本固定使用 4 分支泛化策略，不尝试精确推断分支数量。这是为了在模糊测试场景中获得更好的泛化效果而做出的设计取舍。
GPU 主力路径
GPU 加速桥接已实现，但 CPU 路径仍是主力计算路径。GPU 主要用于特定的并行计算任务（如大规模校验和碰撞）。
文本格式支持
引擎的归纳能力目前以二进制格式为主，对纯文本格式的支持仍需加强。这是一个持续改进的方向。
结果质量波动
对于高度混淆、加密或结构极度不规则的样本，引擎的输出质量可能波动较大。推荐在多个样本上观察结果的稳定性。
样本数量敏感
引擎依赖多样本横向比较，对于仅有一个样本的场景，部分归纳功能（如差异分析、IFFA 集成）无法生效。
大型样本处理
对超过百 MB 的超大样本，引擎的处理效率尚未充分优化，建议优先使用代表性样本片段进行分析。
十八、使用场景建议
基于当前的工程状态，以下场景可能适合使用 7884 引擎进行辅助分析：
- 未知协议/格式的初步探索 — 当分析人员面对一个前所未见的二进制格式时，引擎可以快速生成一个结构草图作为起点。
- 模糊测试前置准备 — 引擎输出的结构定义可直接作为模糊测试的输入模板，帮助模糊测试工具更精准地定位变异区域。
- 多版本格式差异分析 — 同类样本不同版本之间的结构差异可以通过引擎的差分分析模块快速定位。
- 格式知识归档 — 引擎可以将分析结果导出为多种格式，方便团队内部的知识传递和归档。
- 校验和逆向 — 引擎能够自动发现校验和的覆盖范围和算法类型（CRC32/CRC16/Adler32 等），对数据完整性分析有辅助价值。
结语
7884 结构归纳推理引擎是一个仍在快速演进的工程探索项目。它的目标不是证明自己比谁更强，而是探索一条不同的技术路径——让机器在不依赖任何先验知识的条件下，仅凭样本就能理解二进制文件的结构。
我们清楚地认识到，纯黑盒结构归纳是一条困难的路。没有覆盖率反馈指引方向，没有运行时信息帮助验证，引擎必须在黑暗中独自摸索。在当前阶段，它的输出质量远不如插桩辅助方案，也需要有经验的分析人员进行审核和修正。
但我们的判断是：安全对抗的终局一定是黑盒场景越来越多、插桩条件越来越苛刻。如果纯黑盒结构归纳这条路能走通，它解决的是未来 20-50 年的核心问题——不是锦上添花，而是底层基础设施。格式定义是模糊测试的氧气，没有氧气，模糊测试引擎再强也只是摆设。7884 正是那个给格式定义的人——它是模糊测试引擎的"上游母机"。
我们选择把赌注押在这里。不是因为这条路容易，恰恰是因为它难。
我们希望在 5 年或 10 年后再回看这份文档时，能够觉得当时的认知过于浅薄——那意味着这条路径真的走通了。