Codex/LLM 逆向工程复用工作流 - 五阶段完整指南

整理时间： 2026-02-03 23:01
来源： 群聊消息
整理人： AI助手

概述

本文档介绍了一套基于 Codex/LLM 的逆向工程复用工作流，专门用于解包和还原 Electron 应用的混淆代码。该工作流通过系统化的五阶段方法，将复杂的逆向工程任务分解为可管理的步骤，并利用 LLM 的能力自动化大部分还原过程。

核心思想

为什么需要这个工作流？

长上下文任务管理 - 逆向工程涉及大量代码，超出单次会话的上下文限制
状态持久化 - 防止会话重置后丢失进度
自动化处理 - 减少人工干预，提高效率
质量保证 - 通过测试验证还原的准确性

工作流程概览

┌─────────────────────────────────────────────────────────────────┐
│                    五阶段逆向工程工作流                            │
├─────────────┬─────────────┬─────────────┬─────────────┬─────────┤
│  第一阶段    │  第二阶段    │  第三阶段    │  第四阶段    │ 第五阶段 │
│ 准备与分析   │ 外部记忆系统  │  模块还原    │  组装修复    │ 测试验证 │
│ Preparation │   Memory    │ Restoration │   Assembly  │Verification
│  & Analysis │    Setup    │    Loop     │    & Fix    │         │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────┘

第一阶段：准备与分析 (Preparation & Analysis)

1.1 提取资源

操作步骤：
1. 解包 Electron 应用的 app.asar 文件
2. 提取混淆后的 JS 和 CSS 资源
3. 建立原始资源库

工具命令：

# 安装 asar 工具
npm install -g asar

# 解包 app.asar
asar extract app.asar ./extracted_source

# 查看提取的文件结构
tree ./extracted_source -L 2

1.2 生成库存 (Inventory)

目标： 让 LLM 分析代码结构，生成模块清单

操作流程：

步骤	操作	说明
1	读取主 JS 文件	通常是被混淆的主入口文件
2	输入 LLM	使用结构化提示词
3	获得模块清单	作为后续还原的大纲

Prompt 模板：

分析此混淆代码的结构，识别主要逻辑块，并生成一个模块/功能列表。

代码文件：[粘贴混淆代码]

请输出：
1. 模块清单（按功能分类）
2. 每个模块的简要描述
3. 模块间的依赖关系
4. 建议的还原优先级

预期输出：

## 模块清单

### 核心模块
- [ ] main.js - 应用入口
- [ ] renderer.js - 渲染进程
- [ ] preload.js - 预加载脚本

### 功能模块
- [ ] auth.js - 用户认证
- [ ] api.js - API 请求
- [ ] ui.js - UI 组件
...

第二阶段：构建外部记忆系统 (External Memory Setup)

这是长上下文任务的核心。需要创建两个本地文件来存储状态和规则。

2.1 PLAN.md (进度控制)

文件作用： 作为 LLM 的状态存储，防止会话重置后丢失进度

文件内容结构：

# 逆向工程进度计划

## 项目信息
- 项目名称：[应用名称]
- 开始时间：[日期]
- 目标：还原混淆代码为可读 TypeScript

## 模块清单（Checklist）

### 核心模块
- [ ] main.js - 应用入口 (待办)
- [x] renderer.js - 渲染进程 (已完成)
- [ ] preload.js - 预加载脚本 (进行中)

### 功能模块
- [ ] auth.js - 用户认证 (待办)
- [ ] api.js - API 请求 (待办)
...

## 当前处理状态
- **当前模块：** preload.js
- **处理进度：** 50%
- **上次会话：** 2026-02-03 22:30
- **备注：** 正在还原事件监听逻辑

## 已完成模块摘要
1. renderer.js - 完成时间、主要功能、关键发现

2.2 AGENT.md (系统指令)

文件作用： 定义项目背景、任务目标和核心规则

文件内容结构：

# Agent 系统指令

## 项目背景
- 目标应用：[应用名称]
- 原始技术栈：Electron + [其他框架]
- 目标技术栈：Electron + TypeScript
- 代码状态：混淆压缩后的 JS

## 任务目标
将混淆的 Electron 应用代码还原为可读的 TypeScript 项目。

## 核心规则

### 规则 1：会话开始时
**强制指令：** 每次会话开始时，必须先读取 PLAN.md 文件，了解当前进度状态。

### 规则 2：会话结束时
**强制指令：** 每次回答结束前，必须输出更新后的 PLAN.md 内容，保存当前进度。

### 规则 3（第三阶段）：还原阶段
**强制指令：** "将混淆的 JS 逐个模块转换为可读的 TypeScript。"
**关键约束：** "不要尝试编译代码。只关注逻辑还原，忽略任何类型错误或构建缺失。"
> 说明：防止模型因试图修复编译错误而删减逻辑

### 规则 4（第四阶段）：修复阶段
**强制指令：** "现在的目标是修复编译错误（Fix Compilation Errors）并确保 npm start 可运行。"

## 还原标准
1. 保留原始逻辑，不做功能删减
2. 变量命名清晰可读
3. 添加必要的类型注解
4. 保持代码结构清晰

第三阶段：模块还原 (Restoration Loop)

这是核心的代码还原阶段，需要循环处理每个模块。

3.1 设定还原规则

在 AGENT.md 中确认第三阶段规则：

## 当前阶段：模块还原 (Phase 3)

**指令：** 将混淆的 JS 逐个模块转换为可读的 TypeScript
**约束：** 
- 不要尝试编译代码
- 只关注逻辑还原
- 忽略任何类型错误或构建缺失

3.2 执行循环 (Automation)

输入流程：

混淆代码片段 → LLM 处理 → 可读 TypeScript → 保存文件 → 更新 PLAN.md

上下文管理脚本：

# context_monitor.py - 监控上下文使用情况
import subprocess
import time

SESSION_THRESHOLD = 0.8  # 80% 上下文使用阈值

def check_context_usage():
    """检查当前会话的上下文使用情况"""
    # 实际实现需要集成 LLM API
    pass

def save_current_progress():
    """保存当前进度"""
    # 1. 保存当前输出到文件
    # 2. 更新 PLAN.md
    pass

def start_new_session():
    """开启新会话并恢复进度"""
    subprocess.run([
        "claude",  # 或其他 LLM CLI
        "--prompt", "Continue based on PLAN.md"
    ])

def main():
    while True:
        usage = check_context_usage()
        if usage > SESSION_THRESHOLD:
            save_current_progress()
            start_new_session()
        time.sleep(60)  # 每分钟检查一次

if __name__ == "__main__":
    main()

工作流程图：

┌──────────────────────────────────────────────────────────────┐
│                      模块还原循环                             │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐            │
│   │ 读取 PLAN │ → │ 选择模块  │ → │ 输入混淆  │            │
│   │   .md    │    │          │    │   代码    │            │
│   └──────────┘    └──────────┘    └────┬─────┘            │
│                                         ↓                   │
│                                   ┌──────────┐             │
│                                   │ LLM 还原  │             │
│                                   │ 为 TS    │             │
│                                   └────┬─────┘             │
│                                         ↓                   │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐            │
│   │ 检查上下文│ ← │ 保存输出  │ ← │  输出 TS │            │
│   │ 使用情况 │    │ 更新 PLAN │    │   代码   │            │
│   └────┬─────┘    └──────────┘    └──────────┘            │
│        │                                                    │
│        ↓ 超过阈值                                            │
│   ┌──────────┐                                               │
│   │ 开启新会话│ ───────→ 读取 PLAN.md 继续                   │
│   │ 自动继续  │                                               │
│   └──────────┘                                               │
│                                                              │
└──────────────────────────────────────────────────────────────┘

第四阶段：组装与修复 (Assembly & Fix)

4.1 脚手架搭建

步骤：

# 使用 Electron Forge 初始化项目
npm init electron-app@latest my-app -- --template=typescript-webpack

cd my-app

# 安装依赖
npm install

4.2 注入代码

将第三阶段还原的 TS 文件放入项目目录：

my-app/
├── src/
│   ├── main.ts          # 替换为还原的 main.ts
│   ├── preload.ts       # 替换为还原的 preload.ts
│   └── renderer/
│       └── index.ts     # 替换为还原的 renderer.ts
└── ...

4.3 调整规则

修改 AGENT.md：

## 当前阶段：组装修复 (Phase 4)

**指令：** 修复编译错误并确保 npm start 可运行

**删除的规则：**
~~"忽略编译错误"~~

**新增规则：**
1. 运行编译 → 获取错误日志
2. 将错误日志喂给 LLM
3. LLM 对比原始混淆逻辑
4. 生成修复代码
5. 重复直到编译通过

4.4 修复循环 (Fix Loop)

自动化脚本：

# fix_loop.py - 编译错误修复循环
import subprocess
import json

def run_compiler():
    """运行 TypeScript 编译器"""
    result = subprocess.run(
        ["npx", "tsc", "--noEmit"],
        capture_output=True,
        text=True
    )
    return result.returncode == 0, result.stdout + result.stderr

def fix_with_llm(error_log, original_logic):
    """使用 LLM 修复错误"""
    prompt = f"""
    编译错误日志：
    {error_log}

    原始混淆逻辑参考：
    {original_logic}

    请：
    1. 分析错误原因
    2. 对比原始逻辑
    3. 生成修复后的代码
    4. 说明修改原因
    """
    # 调用 LLM API
    pass

def main():
    max_attempts = 10
    for attempt in range(max_attempts):
        success, errors = run_compiler()
        if success:
            print("✅ 编译通过！")
            break

        print(f"尝试 {attempt + 1}: 发现 {errors.count('error')} 个错误")
        fix_with_llm(errors, get_original_logic())
    else:
        print("❌ 达到最大尝试次数，需要人工介入")

if __name__ == "__main__":
    main()

第五阶段：测试验证 (Verification)

5.1 生成测试

Prompt 模板：

请为核心用户流程编写集成测试 (Integration Tests)：

应用功能：
1. [功能1] - [描述]
2. [功能2] - [描述]
...

要求：
1. 使用 Jest + Playwright 或类似的测试框架
2. 覆盖主要用户流程
3. 包含边界情况
4. 生成可运行的测试代码

5.2 盲写矫正循环

流程：

运行测试 → 发现失败 → 喂入测试报告 → LLM 修正 → 重新运行 → 通过

测试驱动修复脚本：

# test_driven_fix.py
import subprocess

def run_tests():
    """运行测试套件"""
    result = subprocess.run(
        ["npm", "test"],
        capture_output=True,
        text=True
    )
    return result.returncode == 0, result.stdout

def fix_based_on_test(test_report):
    """基于测试报告修复"""
    prompt = f"""
    测试失败报告：
    {test_report}

    请分析失败原因并修复代码。
    修复后必须确保测试通过。
    """
    # 调用 LLM
    pass

def main():
    while True:
        success, report = run_tests()
        if success:
            print("✅ 所有测试通过！")
            break

        print("发现测试失败，正在分析...")
        fix_based_on_test(report)

if __name__ == "__main__":
    main()

总结：核心操作清单

阶段	关键操作	输入	输出
1. 提取	解包 asar	app.asar	混淆 JS/CSS
2. 记忆	建立 PLAN.md + AGENT.md	LLM 分析结果	状态文件
3. 还原	JS → TS	混淆代码	可读 TS
4. 组装	放入新脚手架	TS 文件	Electron 项目
5. 修复	编译器报错修复	错误日志	可编译代码
6. 验证	集成测试	测试报告	可运行应用

关键成功因素

1. 状态管理

✅ 使用 PLAN.md 跟踪进度
✅ 每次会话读取和更新状态
✅ 自动化上下文切换

2. 质量保证

✅ 还原阶段不编译，保留完整逻辑
✅ 修复阶段专注编译通过
✅ 验证阶段确保功能正确

3. 自动化

✅ 监控上下文使用
✅ 自动保存和恢复
✅ 编译错误自动修复

常见问题与解决方案

Q1: 混淆代码太复杂，LLM 无法理解

A: 先让 LLM 识别代码结构，生成高级概述，再逐个模块深入。

Q2: 还原的代码有功能缺失

A: 检查第三阶段是否遵守”不编译”规则，确保没有因修复错误而删减逻辑。

Q3: 测试无法通过

A: 对比原始混淆代码和还原代码的行为，确保逻辑等价性。

Q4: 上下文频繁耗尽

A: 调整监控脚本的阈值，或拆分为更小的模块进行处理。