一条命令解密 PyInstaller 打包 exe：PyInstaller 逆向分析入门与 PyInstxtractor 使用教程

一条命令解密 PyInstaller 打包 exe：PyInstaller 逆向分析入门与 PyInstxtractor 使用教程

【免费下载链接】pyinstxtractorPyInstaller Extractor项目地址: https://gitcode.com/gh_mirrors/py/pyinstxtractor

朋友公司的安全审计卡在了一个棘手的环节：外包交付的十几款 Windows 小工具全是 PyInstaller 打包的 exe，验收方需要确认程序里到底执行了什么逻辑，可源码一份都没留下。我接过其中一个文件，只用一个几百行的单文件脚本PyInstxtractor（PyInstaller Extractor），就把藏在 exe 里的全部 Python 字节码完整捞了出来。所谓PyInstaller 逆向分析，很多时候缺的只是一个靠谱的"开箱工具"，而这件事比多数人想象中简单得多。

先想明白一件事：exe 里到底藏了什么

很多人对"逆向"两个字本能地发怵，觉得那是高手拿着十六进制编辑器逐字节较劲的活。其实 PyInstaller 打包出来的程序，结构远比想象中规整。

你可以把打包过程想象成寄一个密封行李箱：你的源码先被编译成 Python 字节码（pyc 文件），和所有第三方依赖一起被压进一个叫CArchive的档案箱；箱子最外面套了一层启动壳（bootloader），负责在运行时把里面的东西还原出来；而箱子底部贴着一张"快递单"——一串固定的魔数（MEI cookie），上面清清楚楚写着包体大小、目录表偏移等关键信息。

PyInstxtractor 做的事情，本质上就是顺着这张快递单干活：先在文件末尾附近找到魔数，读出目录表，再按目录把每一件"货"拆出来、解压、归类，最后给每个 pyc 补上它丢失的"相框"（文件头）。拿到手的东西已经是可以直接交给反编译器处理的成品。

这里要先澄清一个最常见的混淆：PyInstxtractor 不是反编译器，它只负责"开箱"。它把 pyc 文件完好地交到你手上，至于把字节码还原成可读的 Python 源码，那是 uncompyle6、pycdc 这类下游工具的工作。拆包和反编译是逆向链路里前后衔接的两道工序，别指望一个命令全包。

一条命令提取全部 pyc 文件：完整实操流程

理论讲完，直接上手。下面用一个假设的工具scheduler.exe（一个用 PyInstaller 打包的任务调度程序）走完全流程。

下载与准备：只要一个脚本文件

项目仓库里只有寥寥几个文件，核心就是pyinstxtractor.py这一个脚本。克隆下来即可：

git clone https://gitcode.com/gh_mirrors/py/pyinstxtractor

注意一个好消息：你不需要安装 PyInstaller，也不需要pip install任何依赖。脚本只用到了 Python 标准库，这意味着哪怕你的机器上根本没装过 PyInstaller，也能正常拆它的包。整个项目轻到什么程度？把pyinstxtractor.py单独复制到任意目录都能跑。

运行提取命令，看懂每一行输出

把脚本和目标 exe 放到同一目录，执行：

python pyinstxtractor.py scheduler.exe

几秒之内，屏幕上会滚出一串信息，每一行都值得留意：

• [+] Pyinstaller version: 6.19.0——识别出打包用的 PyInstaller 版本；
• [+] Python version: 3.11——打包时用的 Python 版本，这一行后面会派上大用场；
• [+] Found 59 files in CArchive——主档案里拆出了 59 个条目；
• [+] Possible entry point: scheduler.pyc——工具帮你标出了最可能是程序入口的 pyc；
• [+] Found 133 files in PYZ archive——依赖模块的压缩包（PYZ）里还有 133 个文件。

结束后，工作目录里会多出一个scheduler_extracted文件夹，所有提取物都在里面。整个过程自动化程度极高，你基本只需要"看着它跑完"。

找到入口文件，配合反编译器还原源码

进入提取目录，你会看到两类东西：一层是主程序相关的 pyc，包括刚才标记为入口的scheduler.pyc；另一层是PYZ-00.pyz_extracted子目录，里面是按模块名整理好的依赖库字节码。

还原源码时，先处理入口文件，因为业务主逻辑几乎都在那里：

uncompyle6 scheduler_extracted/scheduler.pyc

如果入口文件里调用了自定义模块，再去PYZ-00.pyz_extracted里找到对应的 pyc 逐个反编译即可。依赖库（比如标准库、第三方包）通常不用管，它们只是被"打包"进来的公共零件。

顺带一提，PyInstxtractor 同样能直接处理 Linux 下的 ELF 可执行文件，不需要额外转换工具，跨平台场景下省事不少。

PyInstxtractor 与同类方案怎么选：一张对比清单

真正接触这个领域后你会发现，市面上并不缺"拆 PyInstaller 包"的手段，但它们各自的定位差别很大。用一张清单对比更直观：

几点观察供你参考：

• 如果你只是想在纯 Python 环境下快速拆包、做一次性的分析，原版 PyInstxtractor 是性价比最高的起点；
• 如果目标文件加了密，或者你希望脱离 Python 环境、做成独立工具链，可以去看 pyinstxtractor-ng 这类持续维护的 fork；
• 反编译器和拆包器不是竞争关系，而是上下游配合。很多人问"uncompyle6 能不能直接拆 exe"，答案是它压根不干这活，你得先有 pyc 才有得反编译。

新手最容易踩的五个坑及排查思路

拆包本身成功率很高，但后续环节的坑往往一个接一个。以下是出现频率最高的五类问题，以及各自的排查思路。

1. Python 版本不匹配，PYZ 解组失败工具在提取 PYZ 存档时要用marshal反序列化模块表，这依赖与打包时相同的 Python 版本。如果版本不一致，输出里会出现Unmarshalling FAILED或"please run in Python X.Y"的警告，PYZ 部分会跳过。排查思路很简单：用输出中提示的 Python 版本重跑一次，例如用python3.11 pyinstxtractor.py scheduler.exe。

2. 加密的 PYZ 提取后是一堆乱码针对加密包，工具不会硬解，而是把内容原样转储为.encrypted后缀的文件。这是有意为之——先保留下原始数据，再用解密工具或支持加密的 fork 版本处理。别对着乱码文件怀疑人生，那不是你的问题。

3. 反编译出来的代码和预期不符，或直接报错先确认你反编译的 pyc 文件头四字节（魔数）是否与目标 Python 版本匹配。PyInstaller 5.3 之后不再在包里保存完整 pyc 头，PyInstxtractor 会自动补齐，但如果你拿这个文件去别的环境手动处理，头部信息很容易丢。文件头不对，反编译器会立刻拒绝工作。

4. 入口文件找错，翻遍了也看不到业务逻辑程序真正的入口会被标记为Possible entry point，同时那里往往还伴随pyiboot01_bootstrap.pyc这类启动引导文件。业务逻辑通常在非引导类的那个入口 pyc里，别被引导文件带偏。

5. 路径与工作目录问题脚本会在当前工作目录下生成xxx_extracted文件夹，如果你从别的目录调用脚本，要么先切到 exe 所在目录，要么在命令里传完整路径。反编译时同理，路径写错会得到一堆莫名其妙的"file not found"。

把它放进更大的图景里

PyInstxtractor 在 Python 逆向生态里的位置，很像供应链上的第一道分拣线：它不生产成品，但所有下游环节都依赖它先把货物完好无损地卸下来。安全审计要确认恶意代码，代码恢复要抢救业务逻辑，学习 Python 打包机制要观察真实样本——这些场景的第一步，几乎都是拆包。

如果你想往深处走，有三条路值得探索：一是研究 PyInstaller 自己的格式规范，理解 cookie、CArchive、PYZ 三者如何协作；二是学习 pyc 文件的结构，尤其是 Python 3.7 之后引入的确定性哈希头；三是了解字节码反编译的原理，明白为什么有的 pyc 能完美还原、有的只能恢复个大概。

PyInstaller 在持续迭代，加密手段在升级，提取工具也在不断跟进——打包与拆包这对"攻防"已经拉锯了十几年。最后一个问题留给你思考：当打包器每出一个新版本就多一道防护时，这种"拆箱"技术到底是安全研究的刚需，还是永远追不上版本的追赶游戏？答案可能取决于你用它来做什么。

【免费下载链接】pyinstxtractorPyInstaller Extractor项目地址: https://gitcode.com/gh_mirrors/py/pyinstxtractor