1. 为什么 EXE 复原总在重复造轮子手里拿到一个打包好的 EXE想还原成可读的 Python 源码这件事本身不复杂复杂的是每次都要重新走一遍相同的判断这是 PyInstaller 还是别的打包器、提取出来的 pyc 用哪个版本反编译、反编译结果里哪些是函数错位哪些是字符串丢失、重建之后怎么验证不炸掉原目录。做过三五次之后你会发现真正花时间的不是反编译那一条命令而是围绕它的证据盘点、结果比对和安全验证。Codex 在这里的价值不是替你反编译而是把「收集证据 → 识别打包方式 → 对比反编译结果 → 重建结构 → 验证行为」这条链路固化成可重复调用的 Skill。你只需要说一句「用 DecodePyExe 继续复原当前目录」它就知道该看哪些文件、不该碰哪些目录、先恢复什么后恢复什么、验证到什么程度算通过。这篇就把这个 Skill 的目录骨架、config.toml 配置片段和一次完整复原验证动作拆开讲清楚让你能直接照着搭一套。适合谁看手头有历史打包程序需要还原结构的后端或工具开发者、经常处理 pyc 和反编译产物的安全分析人员、以及想把零散命令沉淀成 Codex Skill 的工程效率爱好者。前置要求只有两个本机装好 Python 和 Codex能跑通一次模型对话确认链路正常。2. 用 TaoToken 打通 Codex 的模型调用链路Codex 执行 Skill 时需要稳定的模型入口否则你刚把流程跑顺一次请求超时就前功尽弃。我这边习惯用 TaoToken 作为统一入口它把模型对话、Coding Plan、API Keys 管理放在同一个控制台里配置一次就能在 Codex 里长期复用不用每次换环境重新折腾。具体来说Codex 的 config.toml 里需要填一个 base_url 和 api_key。base_url 指向 TaoToken 的 API 地址api_key 在控制台的 API Keys 页面生成。这样 Codex 发起的所有模型请求都会走这个入口Skill 里定义的复原步骤才能被稳定执行。如果你只是偶尔验证一下模型输出可以直接用模型对话页面手动测如果是要长期跑编码和 Agent 任务建议开 Coding Plan配额和并发更稳。接入文档里有完整的参数说明第一次配的时候对着看一遍能省不少排查时间。注意API 地址用 https://taotoken.net/api不要在后面拼多余的路径config.toml 里的 base_url 填到这一层就够了。3. Skill 目录骨架与 config.toml 配置片段先把目录结构定下来。Codex Skill 的约定是放在项目根目录的.codex/skills/下每个 Skill 一个文件夹里面至少有一个SKILL.md描述触发条件和执行步骤。我建议再加一个references/放流程细节一个scripts/放可复用的辅助脚本。.codex/ skills/ DecodePyExe/ SKILL.md references/ recovery-flow.md safety-checklist.md scripts/ inventory.py verify_recovered.pySKILL.md的头部用 YAML front matter 写触发描述正文写步骤。描述要写清楚「什么时候用」和「禁止什么」这样 Codex 在匹配任务时不会误触发。--- name: DecodePyExe description: 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. --- # DecodePyExe ## 使用时机 - 当前目录存在 .exe、.pyc、PYZ 提取目录或反编译产物 - 用户要求复原、重建、整理源码 - 用户说「继续复原」并指向当前目录 ## 证据边界 只参考当前目录内的文件。禁止读取其他本地项目的源码。 ## 执行步骤 1. 盘点目录列出所有候选证据文件 2. 识别打包方式查找 pyiboot / pyimod / PYZ / pyi_rth 线索 3. 区分业务模块与第三方依赖 4. 对比多个反编译结果提取函数名、类名、调用顺序、字符串常量 5. 重建为 xxx_recovered.py不覆盖原始反编译文件 6. 先 py_compile 再 import 验证不贸然运行主入口 ## 输出格式 - 重建文件列表 - 每步验证命令与结果 - 不确定处的注释标记config.toml 里除了模型入口还可以给这个 Skill 单独指定温度复原任务需要稳定输出温度调低一点更合适。# ~/.codex/config.toml model claude-sonnet-4-20250514 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [skills.DecodePyExe] enabled true temperature 0.2api_key 不要硬编码在 config.toml 里用环境变量注入。Windows 下在 PowerShell 里设一次$env:TAOTOKEN_API_KEY sk-你的keyLinux 或 macOS 写进 shell 配置export TAOTOKEN_API_KEYsk-你的key配好之后跑一次模型对话确认链路通再进下一步。如果返回 401八成是 key 没读到或者 base_url 多写了路径。4. 一次完整的 EXE 复原验证动作假设当前目录里有一个legacy_tool.exe还有提取出来的PYZ-00.pyz_extracted/和一份反编译结果decompiled/。下面按 Skill 定义的步骤走一遍。第一步盘点目录。Skill 里的inventory.py负责把候选证据列出来避免手动翻。# scripts/inventory.py import os from pathlib import Path EVIDENCE_SUFFIXES {.exe, .pyc, .pyz, .pyi, .log, .json, .ini, .cfg} EVIDENCE_DIRS {PYZ-00.pyz_extracted, decompiled, resources} def inventory(root: str .): root_path Path(root) found {files: [], dirs: []} for p in root_path.rglob(*): if p.is_file() and p.suffix.lower() in EVIDENCE_SUFFIXES: found[files].append(str(p.relative_to(root_path))) if p.is_dir() and p.name in EVIDENCE_DIRS: found[dirs].append(str(p.relative_to(root_path))) return found if __name__ __main__: result inventory() print(候选文件:) for f in result[files]: print( , f) print(候选目录:) for d in result[dirs]: print( , d)跑一下python scripts/inventory.py输出会列出legacy_tool.exe、PYZ-00.pyz_extracted/下的 pyc、decompiled/下的 py 文件。这一步的目标是搞清楚手里有哪些证据不是马上开始反编译。第二步识别打包方式。在提取目录里搜打包器特征文件rg --files PYZ-00.pyz_extracted | rg pyiboot|pyimod|pyi_rth如果命中pyiboot01_bootstrap或pyimod02_importers基本可以确认是 PyInstaller 打包。这一步决定了后续入口文件大概长什么样。第三步区分业务模块和依赖。提取目录里通常混着requests、urllib3这类第三方库不要陷进去。优先找文件名带业务语义的模块比如config_loader.pyc、report_builder.pyc。第三方依赖只需要知道被引用了不需要复原。第四步对比反编译结果。如果decompiled/下有两份不同工具产出的结果分别看它们的优势一份可能字符串保留更全另一份函数边界更清楚。重建时综合两边证据而不是复制其中一份。第五步重建源码。新建legacy_tool_recovered.py不要覆盖decompiled/里的原始文件。重建顺序按 Skill 定义走imports → 配置读取 → 工具函数 → 小模块 → 核心类 → 主流程 → 异常处理。不确定的分支加注释# Reconstructed from bytecode order; exact original branch may differ. if mode batch: run_batch() else: run_single()第六步安全验证。先编译检查python -m py_compile legacy_tool_recovered.py没有输出就是通过。再做导入检查# scripts/verify_recovered.py import importlib.util import sys def verify(module_path: str, module_name: str recovered): spec importlib.util.spec_from_file_location(module_name, module_path) module importlib.util.module_from_spec(spec) sys.modules[module_name] module try: spec.loader.exec_module(module) print(import ok) return True except Exception as e: print(fimport failed: {e}) return False if __name__ __main__: verify(legacy_tool_recovered.py)跑python scripts/verify_recovered.py输出import ok说明模块级代码没有副作用、语法和导入都正常。到这一步为止不要运行主入口因为打包程序的主流程可能写文件、移动目录或启动外部程序。只有确认副作用可控后才考虑单独测试纯函数或配置解析函数。5. 复原过程中最容易踩的坑反编译结果当答案直接跑。反编译产物里函数错位、try/except 丢失、return 位置错误都很常见。直接运行轻则报错重则触发主流程的副作用。正确做法是把它当证据提取结构后重建。一上来就恢复细节。有人喜欢从第一行开始逐行还原结果卡在某个字符串乱码上半天。先恢复 imports 和配置读取拿到一个能 import 的骨架再往里填细节节奏会顺很多。误读其他项目的源码。如果用户明确说「只参考当前目录」就不要去翻本地其他项目。Skill 里把这条写成硬约束Codex 执行时不会越界。config.toml 里 base_url 写错。常见的是在https://taotoken.net/api后面又拼了/v1或/chat/completions导致 404。base_url 填到/api这一层剩下的路径由 Codex 自己拼。api_key 没注入环境变量。config.toml 里写的是env_key TAOTOKEN_API_KEY如果环境变量没设请求会直接 401。设完之后新开一个终端再跑避免旧会话读不到。验证时直接跑主入口。python legacy_tool_recovered.py这种命令在没确认副作用前不要执行。先用py_compile和import两道检查确认安全后再考虑局部测试。Codex 重启后上下文丢失。这是最常见也最影响效率的问题。解决办法是在项目根目录维护一个PROJECT_STATE.md记录当前目标、已完成、关键文件、注意事项和下一步。重启后第一句说「先读 PROJECT_STATE.md然后继续」Codex 就能接上。# 当前目标 复原 legacy_tool.exe 为可读 Python 源码 # 已完成 - 盘点目录确认 PyInstaller 打包 - 重建 legacy_tool_recovered.py 的 imports 和配置读取 - py_compile 通过 # 关键文件 - legacy_tool_recovered.py - decompiled/ 下的两份反编译结果 # 注意事项 - 只参考当前目录 - 不要运行主入口 # 下一步 - 恢复核心类结构 - 对比两份反编译结果的字符串常量6. 把流程固化下来之后Skill 搭好、config.toml 配好、PROJECT_STATE.md 维护起来之后下次遇到类似的 EXE 复原任务你只需要一句「使用 DecodePyExe继续复原当前目录里的程序」Codex 就会按既定步骤走盘点证据、识别打包方式、对比反编译结果、重建源码、安全验证。不用每次重新解释边界和顺序也不用担心重启后从零开始。如果你还没配好模型入口先去控制台生成一个 API Key然后对着接入文档把 config.toml 填完。长期跑编码和 Agent 任务的话Coding Plan 的配额更稳适合把这类复原流程当成日常工具用。配好之后跑一次模型对话确认链路再回来把 Skill 目录建起来整个流程就能跑通了。 Codex 实战：用 Python 把 EXE 反编译复原流程封装成可复用 Skill
1. 为什么 EXE 复原总在重复造轮子手里拿到一个打包好的 EXE想还原成可读的 Python 源码这件事本身不复杂复杂的是每次都要重新走一遍相同的判断这是 PyInstaller 还是别的打包器、提取出来的 pyc 用哪个版本反编译、反编译结果里哪些是函数错位哪些是字符串丢失、重建之后怎么验证不炸掉原目录。做过三五次之后你会发现真正花时间的不是反编译那一条命令而是围绕它的证据盘点、结果比对和安全验证。Codex 在这里的价值不是替你反编译而是把「收集证据 → 识别打包方式 → 对比反编译结果 → 重建结构 → 验证行为」这条链路固化成可重复调用的 Skill。你只需要说一句「用 DecodePyExe 继续复原当前目录」它就知道该看哪些文件、不该碰哪些目录、先恢复什么后恢复什么、验证到什么程度算通过。这篇就把这个 Skill 的目录骨架、config.toml 配置片段和一次完整复原验证动作拆开讲清楚让你能直接照着搭一套。适合谁看手头有历史打包程序需要还原结构的后端或工具开发者、经常处理 pyc 和反编译产物的安全分析人员、以及想把零散命令沉淀成 Codex Skill 的工程效率爱好者。前置要求只有两个本机装好 Python 和 Codex能跑通一次模型对话确认链路正常。2. 用 TaoToken 打通 Codex 的模型调用链路Codex 执行 Skill 时需要稳定的模型入口否则你刚把流程跑顺一次请求超时就前功尽弃。我这边习惯用 TaoToken 作为统一入口它把模型对话、Coding Plan、API Keys 管理放在同一个控制台里配置一次就能在 Codex 里长期复用不用每次换环境重新折腾。具体来说Codex 的 config.toml 里需要填一个 base_url 和 api_key。base_url 指向 TaoToken 的 API 地址api_key 在控制台的 API Keys 页面生成。这样 Codex 发起的所有模型请求都会走这个入口Skill 里定义的复原步骤才能被稳定执行。如果你只是偶尔验证一下模型输出可以直接用模型对话页面手动测如果是要长期跑编码和 Agent 任务建议开 Coding Plan配额和并发更稳。接入文档里有完整的参数说明第一次配的时候对着看一遍能省不少排查时间。注意API 地址用 https://taotoken.net/api不要在后面拼多余的路径config.toml 里的 base_url 填到这一层就够了。3. Skill 目录骨架与 config.toml 配置片段先把目录结构定下来。Codex Skill 的约定是放在项目根目录的.codex/skills/下每个 Skill 一个文件夹里面至少有一个SKILL.md描述触发条件和执行步骤。我建议再加一个references/放流程细节一个scripts/放可复用的辅助脚本。.codex/ skills/ DecodePyExe/ SKILL.md references/ recovery-flow.md safety-checklist.md scripts/ inventory.py verify_recovered.pySKILL.md的头部用 YAML front matter 写触发描述正文写步骤。描述要写清楚「什么时候用」和「禁止什么」这样 Codex 在匹配任务时不会误触发。--- name: DecodePyExe description: 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. --- # DecodePyExe ## 使用时机 - 当前目录存在 .exe、.pyc、PYZ 提取目录或反编译产物 - 用户要求复原、重建、整理源码 - 用户说「继续复原」并指向当前目录 ## 证据边界 只参考当前目录内的文件。禁止读取其他本地项目的源码。 ## 执行步骤 1. 盘点目录列出所有候选证据文件 2. 识别打包方式查找 pyiboot / pyimod / PYZ / pyi_rth 线索 3. 区分业务模块与第三方依赖 4. 对比多个反编译结果提取函数名、类名、调用顺序、字符串常量 5. 重建为 xxx_recovered.py不覆盖原始反编译文件 6. 先 py_compile 再 import 验证不贸然运行主入口 ## 输出格式 - 重建文件列表 - 每步验证命令与结果 - 不确定处的注释标记config.toml 里除了模型入口还可以给这个 Skill 单独指定温度复原任务需要稳定输出温度调低一点更合适。# ~/.codex/config.toml model claude-sonnet-4-20250514 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [skills.DecodePyExe] enabled true temperature 0.2api_key 不要硬编码在 config.toml 里用环境变量注入。Windows 下在 PowerShell 里设一次$env:TAOTOKEN_API_KEY sk-你的keyLinux 或 macOS 写进 shell 配置export TAOTOKEN_API_KEYsk-你的key配好之后跑一次模型对话确认链路通再进下一步。如果返回 401八成是 key 没读到或者 base_url 多写了路径。4. 一次完整的 EXE 复原验证动作假设当前目录里有一个legacy_tool.exe还有提取出来的PYZ-00.pyz_extracted/和一份反编译结果decompiled/。下面按 Skill 定义的步骤走一遍。第一步盘点目录。Skill 里的inventory.py负责把候选证据列出来避免手动翻。# scripts/inventory.py import os from pathlib import Path EVIDENCE_SUFFIXES {.exe, .pyc, .pyz, .pyi, .log, .json, .ini, .cfg} EVIDENCE_DIRS {PYZ-00.pyz_extracted, decompiled, resources} def inventory(root: str .): root_path Path(root) found {files: [], dirs: []} for p in root_path.rglob(*): if p.is_file() and p.suffix.lower() in EVIDENCE_SUFFIXES: found[files].append(str(p.relative_to(root_path))) if p.is_dir() and p.name in EVIDENCE_DIRS: found[dirs].append(str(p.relative_to(root_path))) return found if __name__ __main__: result inventory() print(候选文件:) for f in result[files]: print( , f) print(候选目录:) for d in result[dirs]: print( , d)跑一下python scripts/inventory.py输出会列出legacy_tool.exe、PYZ-00.pyz_extracted/下的 pyc、decompiled/下的 py 文件。这一步的目标是搞清楚手里有哪些证据不是马上开始反编译。第二步识别打包方式。在提取目录里搜打包器特征文件rg --files PYZ-00.pyz_extracted | rg pyiboot|pyimod|pyi_rth如果命中pyiboot01_bootstrap或pyimod02_importers基本可以确认是 PyInstaller 打包。这一步决定了后续入口文件大概长什么样。第三步区分业务模块和依赖。提取目录里通常混着requests、urllib3这类第三方库不要陷进去。优先找文件名带业务语义的模块比如config_loader.pyc、report_builder.pyc。第三方依赖只需要知道被引用了不需要复原。第四步对比反编译结果。如果decompiled/下有两份不同工具产出的结果分别看它们的优势一份可能字符串保留更全另一份函数边界更清楚。重建时综合两边证据而不是复制其中一份。第五步重建源码。新建legacy_tool_recovered.py不要覆盖decompiled/里的原始文件。重建顺序按 Skill 定义走imports → 配置读取 → 工具函数 → 小模块 → 核心类 → 主流程 → 异常处理。不确定的分支加注释# Reconstructed from bytecode order; exact original branch may differ. if mode batch: run_batch() else: run_single()第六步安全验证。先编译检查python -m py_compile legacy_tool_recovered.py没有输出就是通过。再做导入检查# scripts/verify_recovered.py import importlib.util import sys def verify(module_path: str, module_name: str recovered): spec importlib.util.spec_from_file_location(module_name, module_path) module importlib.util.module_from_spec(spec) sys.modules[module_name] module try: spec.loader.exec_module(module) print(import ok) return True except Exception as e: print(fimport failed: {e}) return False if __name__ __main__: verify(legacy_tool_recovered.py)跑python scripts/verify_recovered.py输出import ok说明模块级代码没有副作用、语法和导入都正常。到这一步为止不要运行主入口因为打包程序的主流程可能写文件、移动目录或启动外部程序。只有确认副作用可控后才考虑单独测试纯函数或配置解析函数。5. 复原过程中最容易踩的坑反编译结果当答案直接跑。反编译产物里函数错位、try/except 丢失、return 位置错误都很常见。直接运行轻则报错重则触发主流程的副作用。正确做法是把它当证据提取结构后重建。一上来就恢复细节。有人喜欢从第一行开始逐行还原结果卡在某个字符串乱码上半天。先恢复 imports 和配置读取拿到一个能 import 的骨架再往里填细节节奏会顺很多。误读其他项目的源码。如果用户明确说「只参考当前目录」就不要去翻本地其他项目。Skill 里把这条写成硬约束Codex 执行时不会越界。config.toml 里 base_url 写错。常见的是在https://taotoken.net/api后面又拼了/v1或/chat/completions导致 404。base_url 填到/api这一层剩下的路径由 Codex 自己拼。api_key 没注入环境变量。config.toml 里写的是env_key TAOTOKEN_API_KEY如果环境变量没设请求会直接 401。设完之后新开一个终端再跑避免旧会话读不到。验证时直接跑主入口。python legacy_tool_recovered.py这种命令在没确认副作用前不要执行。先用py_compile和import两道检查确认安全后再考虑局部测试。Codex 重启后上下文丢失。这是最常见也最影响效率的问题。解决办法是在项目根目录维护一个PROJECT_STATE.md记录当前目标、已完成、关键文件、注意事项和下一步。重启后第一句说「先读 PROJECT_STATE.md然后继续」Codex 就能接上。# 当前目标 复原 legacy_tool.exe 为可读 Python 源码 # 已完成 - 盘点目录确认 PyInstaller 打包 - 重建 legacy_tool_recovered.py 的 imports 和配置读取 - py_compile 通过 # 关键文件 - legacy_tool_recovered.py - decompiled/ 下的两份反编译结果 # 注意事项 - 只参考当前目录 - 不要运行主入口 # 下一步 - 恢复核心类结构 - 对比两份反编译结果的字符串常量6. 把流程固化下来之后Skill 搭好、config.toml 配好、PROJECT_STATE.md 维护起来之后下次遇到类似的 EXE 复原任务你只需要一句「使用 DecodePyExe继续复原当前目录里的程序」Codex 就会按既定步骤走盘点证据、识别打包方式、对比反编译结果、重建源码、安全验证。不用每次重新解释边界和顺序也不用担心重启后从零开始。如果你还没配好模型入口先去控制台生成一个 API Key然后对着接入文档把 config.toml 填完。长期跑编码和 Agent 任务的话Coding Plan 的配额更稳适合把这类复原流程当成日常工具用。配好之后跑一次模型对话确认链路再回来把 Skill 目录建起来整个流程就能跑通了。