软件破解（授权定位 / 补丁 / 注册机）

授权边界（本网关及下游技能 [[re-license]] / [[re-keygen]] / [[re-patching]] / [[re-drm]] 共同适用）

• 允许场景：授权验证分析仅限——自有/自研软件分析、获得授权的测试与审计、CTF 与研究环境（题目/沙箱样本）、厂商授权的评估目标
• 禁止：未授权软件解锁、商业软件绕过、绕过授权后分发（含补丁与注册机产物扩散）
• 动态路线权限门槛：断点观察返回值、修改环境、验证行为等动态步骤属正常逆向方法，但 Agent 自动执行前必须确认用户已说明目标归属（软件所有权 / 测试授权 / CTF·研究环境之一）——未说明则只做静态授权逻辑分析，不执行动态验证与补丁落地

完整工作流

按顺序执行；每步产物（校验点地址 / 算法伪代码 / patch 文件 / keygen 脚本）记录证据路径 + sha256（见 [[re-triage]]（能力：triage）），供报告引用。

1. 带壳判断与脱壳：[[re-anti-analysis]]（能力：unpack、deobfuscation、evasion-analysis） —— 先判壳再动手：[[re-packer-id]]（能力：unpack） 识别（节名异常 / 熵 >7 / 导入表极小 / EP 指向非首节）。带壳先脱壳（简单壳 [[re-unpack-simple]]（能力：unpack）、强壳 [[re-unpack-advanced]]（能力：unpack），脱壳产物 sha256 存档）；脱壳后仍有花指令 / 平坦化 / 字符串加密 → [[re-deobfuscate]]（能力：deobfuscation）。确认无壳才进入授权定位（在壳代码里找授权函数是白费功夫，见坑 1）
2. 授权定位：[[re-license]]（能力：license-analysis） —— 字符串 / API 交叉引用找校验函数（注册对话框 / MessageBox / 注册表读取）→ 调用图与成功/失败分支 → 算法还原（对比 / 解密 / 签名验证）→ 区分在线激活与离线校验 → 识别机器码绑定。产物：全部校验点地址 + 校验算法（不只第一个，见坑 2）
3. 分派：根据校验算法性质与目标选择路径——
   • 算法可逆（比较 / 变换 / 查表可逆向）→ [[re-keygen]]（能力：license-analysis） 写注册机（生成任意合法序列号，不修改目标文件，适合分发）
   • 算法不可逆（哈希；非对称验签——私钥不可由公开验证过程推导，RSA/ECC 验证本身是公开算法，不可得的是签名生成密钥）→ [[re-patching]]（能力：binary-patching）（跳过验签 / 改判定分支）；需要从比较链 / 数学关系硬推序列号 → [[re-z3]]（能力：constraint-solving） 建模可选（见坑 4）
   • 只想快速绕过（不关心算法）→ [[re-patching]]（能力：binary-patching）（最小改动：失败跳转改成功跳转）
   • 两者可同时做：patch 即时可用，keygen 长期有效
4. 补丁：[[re-patching]]（能力：binary-patching） —— 定位 patch 点（失败跳转 jz/jnz）→ 字节修改（nop / 跳转重写）→ 校验和 / 自校验处理 → 补丁导出（二进制 diff / patch 文件）→ 多架构适配（ARM 改 B 指令等）
5. 注册机：[[re-keygen]]（能力：license-analysis） —— 从 [[re-license]]（能力：license-analysis） 拿到的校验算法 → 逆推生成算法（正推 / 约束求解）→ python 实现 → 校验码 / 校验位边界处理 → 多平台 CLI 输出
6. 验证：沙箱内（[[re-sandbox]]（能力：sandbox-setup），[[re-analyze/platform-tips]] 最高原则）复跑——补丁版与 keygen 生成的序列号必须通过全部校验点（启动 + 功能点，见坑 2）；与未修改样本对比行为一致；产物与证据路径存档

每步结果按 [[re-triage]]（能力：triage） 记录；注册算法指纹 / 补丁字节是 [[re-ioc]]（能力：threat-intel） YARA 特征来源。

何时用哪个原子技能（选择树）

按输入特征 / 目标分支：

• 样本带壳（节名异常 / 熵高 / 导入表极小）→ 先 [[re-anti-analysis]]（能力：unpack、deobfuscation、evasion-analysis；packer-id → unpack-* → 需要时 deobfuscate），脱壳后回到本网关第 2 步
• "序列号算法是什么 / 帮我生成注册码" → [[re-license]]（能力：license-analysis） 还原算法 → [[re-keygen]]（能力：license-analysis） 生成
• "绕过注册验证 / 解锁功能" → [[re-license]]（能力：license-analysis） 定位校验点 → [[re-patching]]（能力：binary-patching） 最小改动
• 校验算法不可逆（哈希；非对称签名——私钥不可由公开验证过程推导） → [[re-patching]]（能力：binary-patching；跳过验签）；想从比较链硬推 → [[re-z3]]（能力：constraint-solving） 建模
• 在线激活（校验含网络请求）→ [[re-license]]（能力：license-analysis） 区分在线 / 离线后转 [[re-protocol]]（能力：network-capture、protocol-recovery、crypto-identification、crypto-decryption、key-extraction、tls-analysis） 抓包分析激活流程，本地侧按离线流程处理（见坑 3）
• 只要确认注册机制是否存在（"这程序有授权吗"）→ [[re-license]]（能力：license-analysis） 第 1 步即可，不进入后续
• 确认无授权机制 → 不需要本网关，转 [[re-binary-core]]（能力：decompilation、debugging、memory-dump、elf-parser、pe-parser、macho-parser） 正常分析
• 目标是 DRM 内容保护（PlayReady / Widevine 许可证、内容解密）→ 非传统授权校验，转 [[re-drm]]（能力：drm-analysis；仅授权研究，合规边界见该技能）

跨域联合

• 入口调度：本网关被 [[re-analyze]] 的 triage「破解 / 授权绕过 / 注册码」路径调用（re-cracking → 若带壳 re-anti-analysis → 授权定位 re-license → 补丁 / 注册机 re-patching / re-keygen）
• 破解前置脱壳：带壳样本先走 [[re-anti-analysis]]（packer-id → unpack-* → deobfuscate），脱壳产物回本网关做授权定位；[[re-anti-analysis]] 工作流第 6 步同样将破解目标转回本网关
• 反编译工作台：授权函数反编译走 [[re-binary-core]]（[[re-ghidra]] / [[re-ida]] / [[re-radare2]]）
• 动态定位：[[re-gdb]] / [[re-x64dbg]]（断点看校验分支与返回值）、[[re-lldb]]（macOS）、[[re-tracing]]（strace / ltrace 观察注册表 / 文件 / API 调用）、[[re-memdump]]（内存中的注册标志 / 校验结果）
• 在线激活：校验含网络交互 → [[re-protocol]]（[[re-netcap]] 抓包 + [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]] 处理激活协议加密）
• DRM 内容保护：PlayReady / Widevine 许可证与内容解密属 DRM 域 → [[re-drm]]（区别于授权校验破解；仅授权研究）
• 混淆对抗：校验函数被花指令 / 平坦化 / 字符串加密保护 → [[re-deobfuscate]] 还原后再定位
• 验证沙箱：补丁版 / keygen 序列号复跑验证必须 [[re-sandbox]]（[[re-analyze/platform-tips]] 最高原则）
• IOC 产出：注册算法指纹、补丁字节、keygen 典型特征进 [[re-ioc]] 列表

常见坑与陷阱

• 跳过脱壳直接定位授权：现象——xref 定位到的"校验函数"全是壳的解压代码，字符串搜索也全是乱码 / 壳信息；原因——样本带壳，授权逻辑在 OEP 之后才解密；对策——第 1 步先 [[re-anti-analysis]] 确认脱干净（sha256 + 导入表可解析 + 沙箱复跑）再进授权定位
• 只补一个校验点：现象——启动校验过了，一用核心功能又弹注册框 / 功能锁死；原因——校验多次（启动 + 功能点 + 定时器）；对策——[[re-license]] 第 2 步遍历校验函数的全部 xref / 调用图，把所有校验点做成清单，patch / keygen 逐一覆盖并逐个验证
• 在线激活当离线破解：现象——本地判定分支全改完程序依然拒绝使用；原因——序列号验证在服务器端，本地只有请求 / 响应与伪校验；对策——[[re-license]] 第 4 步先区分在线 / 离线；在线激活转 [[re-protocol]] 分析激活协议，本地侧只能处理响应校验与离线回退逻辑
• 盲目追求注册机：现象——校验算法含 SHA / MD5 或 RSA 验签，注册机写不出来，方案卡死；原因——不可逆部分是单向的（哈希无法反推；非对称验签中私钥不可由公开验证过程推导），正推生成序列号不可能；对策——按第 3 步分派：不可逆改 [[re-patching]] 跳过验签；必须约束求解时用 z3-solver 只对可逆部分建模
• 云端配置丢失 → 找同系列文件猜格式：现象——破解对象依赖云端配置文件（如 SSSSSPRO.json），文件被作者清空程序报错，逆向解析又慢；原因——云端文件不可得；对策——猜测同系列其他版本文件（如不带 PRO 的版本，格式通常一致）→ 本地起 server 模拟数据 + URL 替换（hosts/代理/frida hook 重定向），比逆向解析配置格式快得多
• 网络验证平台可自注册 → 自建后台替代逆向：现象——卡密验证服务端协议复杂（sign/加解密/数据格式），自己写 server 一直报数据异常；原因——完整实现验证平台协议工作量大；对策——先查验证平台本身：定位接口 URL → 子域名扫描 → 找平台接口文档/后台登录页；若平台允许任何人注册 → 注册自建软件、生成配置（加密算法默认 RC4 等）→ 替换目标里的配置值，比写 server 省事；这是网络验证破解的通用捷径：优先"复用平台"而非"重写平台"
• frida gadget 注入免劫持注入：现象——目标主程序带壳/自校验，劫持注入麻烦；对策——写 loader.exe：CreateProcess 启动目标后立刻注入 frida-gadget.dll（配合 gadget.config），相比 hook 注入路径更简单可控