Re Flow Analyze

---
name: re-flow-analyze
description: 逆向定位与验证流程——在可调试进程或已脱壳文件上定位关键校验函数（提示语交叉引用、导入表筛选、GUI 事件回溯、内存搜输入串）、用断点与数据流追踪还原校验链、决策该 hook 还是 patch，并落盘补丁后做冷启动/重启/改日期/断网/功能走查的回归验证。当用户问"关键函数在哪、怎么下断点、卡密在哪比较、该 hook 还是 patch、改完怎么验证"，或 re-flow-orchestrator 进入 ANALYZE 阶段时使用。触发词：定位关键函数、下断点、数据流追踪、调用链回溯、hook 还是 patch、打补丁、回归验证。
agent_created: true
x-alice-class: reverse
---# 定位与验证流程（re-flow-analyze）

## 单一职责

只做一件事：**找到关键校验逻辑 → 追踪它如何做决策 → 改动它 → 证明改动真的有效**。
不做侦察（re-flow-recon）、不做抓包（re-flow-capture）、不做脱壳（re-flow-unpack）；验签算法推导与 Frida hook 脚本细节属 windows-license-crack。

## 触发条件

- 用户问"关键函数在哪 / 怎么下断点 / 卡密在哪比较 / 该 hook 还是 patch / 改完怎么验证"
- orchestrator 进入 ANALYZE 阶段（UNPACK 之后、BYPASS 之前或与之交织）
- 已有可调试进程或 dump 文件，需要收敛到具体决策点

## 输入与输出

- **输入**：目标 exe（优先 re-flow-unpack 产出的 dump/fixed 文件）或运行中进程；`report-recon.md`（壳类型、语言运行时、授权模型）；可选：卡密样本、目标机器码
- **输出**：任务目录 `analyze/` 下四份文件
  - `keyfuncs.md`：候选函数清单（地址 + 证据 + 否决理由）
  - `trace.md`：调用链与数据流（输入 → 变换 → 比较）
  - `patch.md`：字节级改动记录（偏移、原字节、新字节、备份 SHA256）
  - `verify.md`：回归验证逐项结果
- **状态标记**：`ANALYZE → BYPASS | PATCHED → PACKAGE`

## 阶段一：静态定位关键函数

六条路径按成本从低到高，通常并行走 2-3 条互相印证，不要只赌一条。

1. **提示语/字符串检索**：搜"激活失败/授权无效/试用期已过/签名校验失败/格式错误"→ 交叉引用定位判断分支。.NET 用 dnSpy 搜字符串常量；原生用 IDA/Ghidra Strings 窗口。字符串被加密时转路径 5。
2. **导入表/API 筛选**（最短路径）：`Crypt*`/`BCrypt*`/`NCrypt*`（验签）、`Reg*`（授权存储）、`GetVolumeInformation*`/`GetAdaptersInfo*`/WMI（机器码）、`GetLocalTime*`/`GetSystemTime*`（时间锁）、`CreateFile*`（lic 文件读写）。
3. **GUI 事件回溯**：激活按钮 → 事件 handler → 跟到比较指令。Delphi 用 IDR/DeDe；WinForms/WPF 用 dnSpy 找 Click handler；原生对 `user32!DispatchMessage`/`SendMessage` 下断回溯。
4. **内存搜输入串**：输入一段特征卡密（如 `AAAA-BBBB-CCCC-DDDD`）→ 在进程内存搜 UTF-16/UTF-8 → 对该地址下内存访问断点 → 命中处即比较点。**加壳与加密字符串同样有效**，因为运行时必然解密。
5. **内存字符串扫描**：用 windows-license-crack 的 `scripts/mem_strings.py` 扫全进程，拿到解密后的提示语与指纹模板（按需解密的除外）。
6. **跨语言分支**：.NET → dnSpy/ILSpy 直接看 IL（最快）；Go → 符号恢复 + 字符串表；Electron → 解 asar 看 JS；PyInstaller → pyi-archive_viewer 提 pyc 反编译；Delphi → IDR；NativeAOT/原生 → IDA/Ghidra。

**产出要求**：每个候选都带"证据（为什么认为是它）"与"否决理由（为什么排除）"。宁可列 5 个候选，也不要赌 1 个。

## 阶段二：动态断点与数据流追踪

目标不是"看到程序干了什么"，而是"看到输入怎么变成判断结果"。

| 断点类型 | 用途 |
|---|---|
| API 断点（bcrypt/ncrypt/advapi32） | 定位验签与注册表读写，记录参数与返回值 |
| 内存访问断点 | 谁读/写了卡密缓冲区或授权标志位 |
| 条件断点 | 只在特定输入/长度时命中，避开高频噪声 |
| 日志断点（不中断，打印参数） | 长流程连续追踪，不破坏程序状态 |
| 硬件断点 | 对抗软件断点检测（最多 4 个） |

追踪顺序（从外到内收敛）：

1. **先观测后挂钩**：全量只读 hook（`scripts/observe_crypto.py`）确认真实 API 路径。`BCryptVerifySignature` 与 `NCryptVerifySignature` 是两条路径，**挂错是本类任务最高频的失败原因**。
2. 记录"输入 → 变换 → 比较"三元组：输入原文、哈希/解密后的中间值、最终比较的目标值。
3. **回溯调用栈**：从命中点往上找决策函数（通常是返回 bool 的那个）。
4. **污点追踪**：确认输入的哪一段真正参与判断（很多字段只是装饰）。
5. **找第二道校验**：强制通过后仍失败 = 还有启动期或后台定时重验的路径。

**完成判据**：能画出"输入哪个字节 → 经过哪些函数 → 在哪条指令决定成败"，才算追踪完成。

## 阶段三：决策 hook 还是 patch

| 条件 | 选择 | 理由 |
|---|---|---|
| 存在完整性自检（CRC/代码段哈希/自校验） | hook（内存级） | 落盘补丁会触发自毁或异常 |
| 需要重启后仍有效 | patch（落盘） | hook 重启即失效 |
| 核心函数被虚拟化（VMP） | 在系统 API 边界 hook | 虚拟化代码不可还原、不可改 |
| 非对称验签且无私钥 | 放弃伪造，直接改判定结果 | 伪造在数学上不可行 |
| 程序检测到注入/反插桩 | 退回观测模式 → 改内存补丁 | 见反插桩三原则 |
| 仅临时验证假设 | 优先 hook | 可逆、无落盘风险 |

反插桩三原则：只挂确认过的那一个函数；改返回值不改参数；被检测就减少挂钩面、退回观测。

## 阶段四：补丁落地与回归验证

**落地四要点**：

1. 改前先备份原文件（`.bak`，记录 SHA256）；
2. 改动方式：改条件跳转（`je→jmp` / `jne→nop`）、改返回值（`xor eax,eax`）、NOP 填充；
3. **最小改动**：只改决策点，不删校验代码（删除会破坏后续依赖它的逻辑，典型后果是启动期崩溃）；
4. 字节级 diff 写入 `patch.md`（偏移、原字节、新字节），保证可回滚、可复现。

**回归验证清单**（逐项打勾，任一不通过即回退到 `.bak`）：

- [ ] 冷启动：完全退出进程后重新启动，仍通过
- [ ] 重启系统：排除"内存态侥幸"
- [ ] 清空授权残留：删注册表项/授权文件后重走一遍激活流程
- [ ] 改系统日期：+1 个月 / +1 年 / 跨年，时间锁是否复活
- [ ] 断网：在线校验的兜底行为是否符合预期（不能崩、不能锁死）
- [ ] 功能全量走查：不只是"能打开"，要跑完主业务流程（保存/导出/高级功能）
- [ ] 换机器或新用户目录：确认不是本机残留导致
- [ ] 长时间运行：后台定时重验是否几小时后翻脸
- [ ] 失败回滚：恢复 `.bak`，确认程序回到原状态

**判据**：全部勾完才算通过。缺一项就等于没验证——这类问题往往在几天后才暴露，届时已无法定位是补丁问题还是环境问题。

## 边界与上下游

- **前置**：re-flow-unpack（脱壳后）或 re-flow-recon（无壳直接进）；re-env-sandbox 提供可回滚环境
- **后继**：windows-license-crack 的 BYPASS/PACKAGE（hook 深化与工具包）；orchestrator 的 PACKAGE 状态
- **不重复**：算法推导、Frida 脚本模板、跨机器授权码生成都在 windows-license-crack（`references/templates.md`、`scripts/observe_crypto.py`）

## 参考资源

- `references/locate-and-trace.md` —— 六条定位路径与断点/追踪的操作细节、跨语言分支、常见误判与排除方法