Seep-Reverse-Lab 案例拆解（项目D）：AOB 双态签名迁移法如何攻克跨版本重编译位移

Seep-Reverse-Lab 是一个 Agent-Native 的多平台逆向工程与客户端授权审计工作台。本文拆解其中"项目D"案例：当目标程序被重编译、所有代码偏移全部漂移后，如何借助AOB 特征码（Signature）双态签名迁移法，在多个版本间快速、唯一地重新定位 15 个授权校验位点，并保证 PE 文件绝不被写坏——一套新手也能照着做的可复现流程。

一、一次"架构倒退"带来的昂贵教训 🧨

逆向补丁工具最怕的不是"找不到位置"，而是把文件写坏。项目D 案例的起点就是一次典型的架构倒退：

Gen 2 的致命假设是"镜像布局固定"：补丁位点写死为 build 10 的绝对偏移，并把文件无条件截断到 6,189,056 字节。该体积恰好等于 build 10 的节区表末尾——对老版本恰好正确；但体积更大的新版本走到这里，尾部节区就被拦腰砍断，Windows 直接报"不是有效的 Win32 应用程序"（错误 193）。

核心教训：用一个隐含的版本假设换取短期精确性，目标一重编译就会全线崩溃。

二、版本差异性质判定：是"重写"还是"平移"？🔍

迁移位点前，先回答关键问题：新旧版本到底是同源重编译，还是代码重写？案例用节区逐字节相似度矩阵做了快速体检（reverse-engineering.md §2）：

.text相同率仅 5.78% 极具迷惑性。但进一步用64 字节窗口在 ±0x8000 范围内滑动搜索最佳匹配，画出位移曲线后发现：位移在−896 ~ +64之间非均匀跳变，且.text起始 128 字节几乎全同、跳转目标差值恰好等于.textVSize 增长量。

结论：同源重编译，代码整体位移 + 局部增删。固定偏移方案必然失效，必须改用 AOB 特征码扫描。

三、跨版本定位：滑动汉明距离法 📐

有了"已知版本位点 + 新版本文件"，如何找到位点在新版本中的新位置？案例采用滑动汉明距离（脚本 02_locate_points.py）：

1. 以旧版位点为中心取64 字节窗口；
2. 在新版本文件上滑动比对，逐字节统计差异数（汉明距离）；
3. 取距离最小者作为新版位点。

判据非常硬：64 字节窗口下，随机匹配的期望汉明距离 ≈62；而实测命中距离仅1–6——置信度极高。

14/14 全部唯一命中，且位点字节与期望完全一致。注意数据段位移是+512（与代码段相反）——.text增长把后续节区整体后移了。

⚠️ 反例警示：不要用"分块哈希锚点"建全局偏移映射。大二进制中重复块会导致误锚定，案例实测产出过+1,755,424这种荒谬位移。

四、AOB 双态签名生成：三条铁律 ⚙️

定位完位点，还不能直接写特征码。案例沉淀出三条规则（生成脚本 03_gen_signatures.py）：

规则一：特征码必须取"多版本共同稳定区"。向位点左右扩展时，每个字节必须在所有已采集版本中一致。实战教训：用 11.2 单版本生成的特征码，在 11.3 上 13/14 命中，唯一失败那条的右扩展 4 字节恰好是重定位指针（38 83 69 00→30 83 69 00，差 8）。改用三版本共同稳定区后自动收窄，问题消失。

规则二：双态唯一性校验。为每个位点生成两份特征码——原始态（含期望字节）与已补丁态（含补丁字节）。两份特征码在"原始 / 已补丁"两种状态的所有版本中都必须唯一命中（命中数 == 1），否则不可用。

规则三：相邻位点必须合并。数据段两个位点相距仅 4 字节（0x378CDC与0x378CE0），拆成两条后特征码互相包含，唯一性校验必然失败；合并为单条 8 字节条目后即通过。

还有一个隐蔽陷阱：链接器的COMDAT 折叠让"守护线程 D"与"看门狗关联函数"的函数序言逐字节相同，靠序言锚定会双命中——只能向左侧前一个函数尾部扩展来锚定，这条特征码因此仅 14 字节，是全表最短的。

五、语义验证：反汇编交叉印证 🧩

字节匹配对了，语义对了吗？案例用 capstone 对每个位点做三版本指令序列比对（归一化掉地址与跳转目标），并找到了最有价值的印证——全局地址咬合：

mov eax, dword ptr [0x779CDC] ; → 文件偏移 0x378CDC（补丁点 14a） ... mov dword ptr [0x779CE0], eax ; → 文件偏移 0x378CE0（补丁点 14b）

代码段指令引用的两个全局地址，恰好落在数据段两个补丁点的文件偏移上——三点语义完全咬合，证明位点分析无误。最终结论：目标程序本次更新对授权校验机制本身零变更，差异仅为代码位置平移与重定位地址。完整位点清单见 algorithm.md。

六、工程保障：PE 绝不能被写坏 🛡️

定位与语义都正确后，案例补齐了六层"防写坏"设计，全部实现在零外部依赖的 C# 引擎 Program.cs 中：

其中"版本一致性守卫"在回归测试中当场拦下一次真实事故：测试误触真实安装目录时，正是它阻止了旧版本主程序覆盖新版本安装。回归测试套件（PatchEngineTests.cs，61 项断言全绿）覆盖校验和复现、三版本端到端、差异白名单、陈旧 BAK、负向用例（节区截断 / 特征码不符 / 空文件 / 非 PE → 拒绝且零写入）。

七、版本扩展流水线：9 个脚本走完闭环 🚀

案例把整套方法论固化为路径可移植的流水线（tools/README.md），目标软件发新版本时按 6 步执行：

安装包 → 提取 → 判性质 → 迁位点 → 生特征码 → 验语义 → 端到端 → 拼接源码

关键判据速查：汉明距离 ≤ 8（> 12 说明代码已实质变更，需重新逆向）；双态唯一性命中数 == 1；差异字节 ⊆ 白名单。依赖仅pip install numpy capstone pefile。

八、总结：三个可带走的方法论 💡

1. 固定偏移是版本假设——目标一重编译，非均匀位移（本例 −896 ~ +64）会让所有绝对偏移失效；AOB 特征码扫描才是跨版本定位的正解。
2. 特征码要"宽进严出"：取多版本共同稳定区、做双态唯一性校验、合并相邻位点、警惕 COMDAT 折叠造成的序言撞车。
3. 写坏比找不到更致命：PE 结构门禁、原子写入回滚、差异字节白名单，加上对照组实验排除假阳性，才能让补丁产物"敢上生产"。

项目D 案例完整材料（含三版本偏移对照表、Frida 运行时定位法）可在 Tool/cases/项目D/README.md 中查阅。