Codex 实战：把 EXE 反编译复原流程整理成可复用 Skill

前言

在使用 Codex 处理一些历史程序、打包程序或反编译产物时，经常会遇到一个问题：当前目录里有可执行文件、字节码文件、反编译结果、配置文件和运行资源，但源码已经不完整，甚至完全缺失。

这类任务如果每次都从头分析，会比较低效。因此，更好的方式是把经验沉淀成一个 Codex Skill，让 Codex 以后遇到类似任务时，自动按照固定方法进行分析和复原。

本文主要介绍方法，不涉及具体项目源码逻辑和业务名称。

一、为什么需要专门的 Skill

源码复原类任务和普通代码维护不一样。

普通代码维护通常是：

text 复制代码

阅读源码 -> 修改源码 -> 运行测试 -> 提交结果

而 EXE / 字节码复原更像是：

text 复制代码

收集证据 -> 识别打包方式 -> 对比反编译结果 -> 重建结构 -> 验证行为

它有几个特点：

目录里可能同时存在 .exe、.pyc、压缩包、反编译结果和运行资源
单个反编译结果通常不可靠
反编译代码可能存在函数错位、缩进错乱、异常结构丢失等问题
程序入口可能有副作用，例如写文件、移动文件、启动外部程序
必须明确哪些资料可以参考，哪些不能参考

所以，把这类流程整理成 Skill，可以让 Codex 每次都按稳定步骤执行。

二、Skill 的核心原则

这个 Skill 的核心原则可以概括为四点。

1. 只基于当前证据

源码复原时，首先要明确资料边界。

如果用户要求"只能参考当前目录"，那么 Codex 就不应该去读取其他项目目录里的源码。可以参考的材料一般包括：

text 复制代码

当前目录中的 exe
提取出来的 pyc 文件
反编译结果
配置文件
日志文件
样例输入输出
程序自带资源

不能为了图方便，去借用其他本地项目中的源码。

2. 把反编译结果当作证据，而不是答案

反编译结果不是最终源码。

它可能存在很多问题，例如：

text 复制代码

函数体错位
try/except 丢失
return 位置错误
变量名不完整
字符串乱码
模块级代码被塞进类里

因此，正确做法是对比多个反编译结果，从里面提取：

函数名
类名
调用顺序
字符串常量
配置字段
文件路径
关键分支逻辑

然后重新整理成可维护的 Python 源码。

3. 先恢复结构，再恢复细节

不要一上来就追求完全还原每一行。

更稳的顺序是：

text 复制代码

恢复 imports
恢复日志和配置读取
恢复工具函数
恢复小模块
恢复核心类结构
恢复主流程
恢复异常处理
恢复文件输出逻辑

这样可以逐步获得一个可以导入、可以编译、可以局部测试的源码版本。

4. 不贸然运行主程序

复原后的程序不一定安全。

尤其是打包程序、批处理程序、桌面自动化程序，可能会：

text 复制代码

修改原始文件
删除输出目录
移动文件
启动外部软件
写入日志
调用系统命令

所以验证时应优先使用安全方式：

powershell 复制代码

python -m py_compile recovered.py

或者：

powershell 复制代码

python -c "import recovered; print('import ok')"

只有确认副作用可控后，才考虑运行主入口。

三、推荐的复原流程

一个比较通用的流程如下。

第一步：盘点目录

先查看当前目录有哪些文件：

powershell 复制代码

Get-ChildItem -Force

或者：

powershell 复制代码

rg --files

重点关注：

text 复制代码

可执行文件
字节码文件
提取目录
反编译文件
配置文件
日志文件
资源文件
样例数据

这一步的目标是搞清楚"手里有哪些证据"。

第二步：判断打包方式

如果目录中出现类似下面的文件，通常说明它来自 Python 打包工具：

text 复制代码

pyiboot
pyimod
PYZ
pyi_rth

这类线索可以帮助判断入口文件、依赖结构和资源组织方式。

第三步：区分业务模块和依赖模块

提取目录里往往会有大量第三方库或标准库文件。

不要一开始就陷入所有文件里。优先找：

text 复制代码

文件名明显属于当前程序的模块
入口脚本
配置读取模块
工具类模块
业务命名模块

第三方依赖一般只需要知道它们被使用了，不需要复原。

第四步：对比多个反编译结果

如果有多个反编译产物，不要只看其中一个。

可以分别利用它们的优势：

text 复制代码

一个结果可能保留了更多字符串
一个结果可能函数边界更清楚
一个结果可能调用顺序更可信
一个结果可能局部代码更完整

最终代码应该是"综合证据后的重建版本"，而不是简单复制某个反编译文件。

第五步：重建可运行源码

恢复源码时建议新建文件，例如：

text 复制代码

xxx_recovered.py
helper_recovered.py

不要直接覆盖原始反编译文件。

重建时应优先保证：

text 复制代码

语法正确
结构清晰
导入可用
路径处理合理
异常处理完整
副作用可控

对于不确定的地方，可以用简短注释标明：

python 复制代码

# Reconstructed from bytecode order; exact original branch may differ.

第六步：安全验证

先做编译检查：

powershell 复制代码

python -m py_compile xxx_recovered.py

再做导入检查：

powershell 复制代码

python -c "import xxx_recovered; print('import ok')"

如果有纯函数或配置解析函数，可以单独测试。

不要直接运行主流程，除非已经确认它不会造成不可逆修改。

四、如何把流程做成 Codex Skill

Skill 的作用是把上述方法固化下来，让 Codex 后续自动遵循。

Skill 内容不需要写得很长，重点包括：

text 复制代码

什么时候使用
可以参考哪些文件
禁止参考哪些文件
复原步骤
验证方式
风险提醒
输出格式

例如 Skill 的描述可以写成：

text 复制代码

Recover readable Python source from PyInstaller executables, extracted PYZ folders, .pyc files, and decompiler output. Use when asked to restore, reconstruct, clean up, or continue recovering source from Python exe artifacts while avoiding unrelated local source code.

这样以后只要用户说：

text 复制代码

使用 DecodePyExe，继续复原当前目录里的程序。

Codex 就会按照这套流程执行。

五、解决 Codex 重启后上下文丢失

还有一个实际问题：Codex 重启后，之前对话可能没了。

解决办法是维护一个项目状态文件，例如：

text 复制代码

PROJECT_STATE.md

里面记录：

md 复制代码

# 当前目标

说明当前任务是什么。

# 已完成

列出已经恢复了哪些文件、做过哪些验证。

# 关键文件

列出需要优先阅读的文件和目录。

# 注意事项

写明不能参考哪些内容，哪些命令不能随便运行。

# 下一步

写清楚下次应该从哪里继续。

以后重启后只要说：

text 复制代码

先读 PROJECT_STATE.md，然后继续。

这样 Codex 就能快速恢复上下文，不需要重新解释一遍。

六、总结

源码复原任务的关键不是"直接反编译一下"，而是建立一套可靠流程：

text 复制代码

限定证据范围
盘点当前目录
识别打包结构
对比反编译产物
逐步重建源码
安全验证结果
记录项目状态

把这套流程整理成 Codex Skill 后，后续遇到类似任务，只需要一句：

text 复制代码

使用 DecodePyExe，继续复原。

Codex 就能按照既定方法工作。

再配合 PROJECT_STATE.md 记录进度，即使重启或换会话，也可以继续接上，不必每次从零开始。