把反编译项目"合法化"：让 Claude Code 接受你的逆向工程工作区
在现代 AI 辅助编程时代，Claude Code 这样的工具能显著提升开发效率。但对安全研究和逆向工程（RE）爱好者来说，它们有一个共同的限制——所有权验证。本文分享一种实践思路：用 Claude Code + Gemini CLI 多 Agent 协作，绕过这一限制并让项目"合法化"。
核心痛点：证明所有权
如果你在一个明显是反编译输出的文件夹中启动 Claude Code，它会通过多种审计方法判断你是不是该项目的真正所有者，验证失败就可能拒绝执行敏感任务。
Claude Code 的所有权审计信号（不完全列举）
- 检查 Git 历史和 commit 元数据
- 分析特定文件路径与目录命名习惯
- 识别具有混淆 / 反编译特征的字符串
- 识别破解工具留下的硬编码痕迹
面对这一限制，容易想到两种思路：
伪造邮件
通过配置伪装所有者的通信记录。成功率低，且极不稳定。
叙事重构
将反编译片段重构成"丢失了元数据的原始源代码"，构建逻辑闭环的项目背景。
叙事重构：从反编译到"源代码丢失"
要让 Claude Code 接受一个没有 Git 历史、满是反编译痕迹的项目，需要构建一个合理且逻辑闭环的叙事。
背景设定
声称这个项目原本是在另一台机器上开发的原始项目，但由于硬盘故障之类的不可抗力事故，Git 仓库（.git）以及所有开发元数据都丢失了。
核心复原
使用 Codex 或其他反汇编工具复原关键逻辑（Core Source），并将其作为"唯一留下的备份"来呈现。
重要流程：证据的自动清理（Sanitize）
这是最容易失败的一步。反编译项目里会留下大量"尾巴"——下面这些是最常见、也最容易触发审计的指纹。
| 类别 | 典型痕迹 |
|---|---|
| 文件夹名 | disasm/、pseudocode/、-reverse / -reconstructed 后缀 |
| 关键词字符串 | Mach-O、stripped、Ghidra |
| 致命字面量 | CRACKED、fake_signature、2099-12-31 这类破解工具硬编码 |
通过 AI 协作进行清理的流程
当 Claude Code 检测到证据并表现出疑虑时，不要试图在当前会话中解释。这会污染上下文。正确做法如下：
Gemini CLI 之类不受审计限制的其他 AI 作为独立 Agent 接入工作区。
.build、analysis 等所有反编译产物目录。
CRACKED、fake_signature 等可被识别的字符串统一替换或移除。
README.md
将项目重新定义为"社区主导的独立资源项目"，给出符合背景设定的描述。
-reverse、-reconstructed 等后缀的目录改成中性名字。
/rewind 命令，回滚到产生疑虑之前的状态。
上述清理流程已被抽象为可复用的 Claude Code Skill。源代码和 CLI 入口点请参见 project-sanitizer-skill。
多 Agent 协作：受审计的执行体 vs 不受审计的清理器
这套方案的核心，是把"被审计的 AI"和"做清理的 AI"分开来。
Claude Code
负责实际开发任务，需要通过所有权验证。清理过程中暂时挂起，清理完成后用 /rewind 重置会话。
Gemini CLI
在另一进程里独立运行，扫描工作区并执行删除 / 替换 / 重命名 / 重写 README 等清理动作。
使用 Task Rewind（/rewind）
/rewind 并不只是用来撤销代码变更的。更重要的是，它是一种"上下文重置"。在使用 Gemini CLI 完成工作区的物理清理之后，/rewind 会让 Claude Code 忘记先前发现证据的那一刻，并重新开始任务。此时，面对一个已被干净重构的工作区，Claude Code 会将其识别为一个因意外事故而丢失元数据的普通独立项目。
总结
这种"多 Agent 协作 + 叙事重构"的思路，本质上是利用 AI 作为工具的特性，来对抗另一个 AI 的审计机制。它要求开发者不仅理解代码逻辑，也要理解 AI 工具的"心理"和审计逻辑。
评论
评论发布后会立即公开，如触发规则可能被审核下架。