简介：面向开发者、逆向工程学习者及需要查看Windows可执行程序内部资源的用户，这份EXE解压工具提供了从EXE文件中提取嵌入资源的可行途径，可用于分析程序结构、提取图片文本音频等素材，或辅助调试与教学演示。压缩包共167个文件，以91个txt说明、42个exe程序、11个unp插件及7个dll动态库为主，并含少量ini配置、doc文档与htm帮助页，整体约5.14MB；多种引擎与插件并存，便于按不同封装格式尝试解包。已有3511人学习下载，说明其在相关场景中具备一定参考价值。读者可获得可直接运行的工具主体、配套说明与许可变更记录，以及多类解包组件的组合思路，适合作为EXE资源提取与软件分析的入门实践材料，使用时需注意版权与软件许可限制。

1. 一个 300MB 的 setup.exe，装完只剩 40MB：差的那部分去哪了

接手一个离线部署项目时，对方给的是三个 setup.exe，要求在一台没有外网的机器上还原出一模一样的运行目录。双击装完再看 Program Files，体积只有安装包的零头——剩下的几百兆并没有凭空消失，它们躺在安装包的载荷区里，只是安装脚本没把它们铺到目标盘。EXE 解压工具解决的就是这件事：不跑安装流程，直接把封装体内部的目录树、脚本、资源文件原样取出来。它适合三类人：要做离线部署和绿色化的运维、要审计第三方安装包往系统里写了什么的合规同学、以及手上只剩一个安装包却要改配置的开发者。前提先划清楚——软件归你或已获授权。

2. 先判型再动手：五种 EXE 封装与三步识别法

.exe这一个后缀底下至少藏着五种完全不同的封装：NSIS、Inno Setup、InstallShield、MSI 引导包、自解压归档，外加 PyInstaller 和 .NET 单文件这两类“其实不是安装包”的可执行体。新手最常见的动作是右键用 7-Zip 提取，运气好出一堆文件，运气好一点出一堆看不懂的编号文件，然后下结论“这包加密了”。判型这一步花不了五分钟，却决定了后面所有命令能不能用对。

2.1 从 PE 结构定位载荷：节区、overlay 与“多出来的那一段”

Windows可执行文件是 PE 格式：开头两个字节MZ，偏移0x3C处的四字节指向PE\0\0签名，签名之后是 COFF 头和可选头，再往后是节区表。安装包制作者把真正的文件树压缩后，通常塞在两个位置之一：新增一个节区（节区名常见.data、.itext、.ndata），或者直接追加在所有节区之后——后者叫 overlay，是自解压包最经典的位置。

搞清这个结构，就能解释一个常见疑惑：为什么 7-Zip 能打开某些安装包、打不开另一些。7-Zip 是从文件头扫到文件尾找已知归档魔数的，overlay 里如果躺着一段 7z、RAR 或 CAB，它自然能识别；而 Inno Setup 的载荷不是任何标准归档格式，是自家的一套压缩块加文件表，7-Zip 扫不到魔数就只能摊手。这不是权限问题，也不是加密问题，是格式支持问题。

另一个实用推论：overlay 的长度本身就是一个信号。几百字节到几 KB 的 overlay 通常是数字签名和图标残留，几十 MB 起步的基本就是载荷本体；overlay 长度和文件大小接近时，说明这个 exe 几乎就是个壳，真正的数据全在后面。

2.2 三步分型：先看壳，再看串，最后看偏移

分型不需要上来就写脚本，三条命令能解决八成情况。第一步确认这个文件有没有被加壳，第二步扫特征字符串，第三步让 7-Zip 自报家门。

# 1) 看文件本身：是 PE32/PE64，还是被 UPX 之类的壳压过 file setup.exe # 2) 扫特征字符串，成本最低的一步 # -n 8 过滤掉过短的噪声串，grep -i 大小写不敏感 strings -n 8 setup.exe \ | grep -Ei 'nullsoft|inno setup|installshield|wixbundle|pyinstaller|dotnet' \ | sort -u # 3) 让 7-Zip 报一下它能识别出什么，重点看 "Type =" 那一行 # l 是 list，只读不写，不会动原文件 7z l setup.exe | head -20

strings那一步的命中结果直接对应封装类型：出现Nullsoft或NullsoftInst基本是 NSIS；出现Inno Setup Setup Data是 Inno；出现InstallShield是 IS；出现WixBundle说明这是个 Burn 引导包，里面还套着 MSI。7z l的输出里如果Type = Nsis，说明 7-Zip 原生支持，可以直接进第 3 章；如果报Can not open file as archive，不代表包坏了，只代表 7-Zip 不认这个格式。

要把这一步做扎实，用下面这段脚本把 overlay 起点和各段魔数的位置一次性打出来。它比肉眼翻十六进制靠谱得多，尤其是在判断“载荷在节区里还是在文件尾”的时候。

# probe_exe.py：定位 overlay 起点，并扫描常见载荷魔数 import sys, struct SIGS = [ (b"7z\xbc\xaf\x27\x1c", "7z 自解压"), (b"Rar!\x1a\x07", "RAR 自解压"), (b"MSCF", "CAB / MSI"), (b"MEI\x0c\x0b\x0a\x0b\x0e", "PyInstaller"), (b"Nullsoft", "NSIS"), (b"Inno Setup", "Inno Setup"), (b"InstallShield", "InstallShield"), (b"WixBundle", "WiX Burn 引导包"), ] def pe_sections(buf): """返回 [(节区名, 文件偏移, 原始大小), ...]""" e_lfanew = struct.unpack_from("<I", buf, 0x3C)[0] # PE 头偏移 assert buf[e_lfanew:e_lfanew + 4] == b"PE\0\0", "不是 PE 文件" nsec = struct.unpack_from("<H", buf, e_lfanew + 6)[0] # 节区数量 opt_size = struct.unpack_from("<H", buf, e_lfanew + 20)[0] # 可选头长度 sec_base = e_lfanew + 24 + opt_size # 节区表起点 secs = [] for i in range(nsec): b = sec_base + i * 40 name = buf[b:b + 8].rstrip(b"\0").decode("latin1", "ignore") raw_size, raw_ptr = struct.unpack_from("<II", buf, b + 16) secs.append((name, raw_ptr, raw_size)) return secs def main(path): buf = open(path, "rb").read() secs = pe_sections(buf) end = max(p + s for _, p, s in secs) # 最后一个节区的结束位置 print(f"文件大小 {len(buf):,} 字节，节区结束于 {end:,}，overlay {len(buf) - end:,} 字节") for name, ptr, size in secs: print(f" 节区 {name:<10} 偏移 {ptr:>12,} 大小 {size:>12,}") for sig, label in SIGS: pos = buf.find(sig) # 只找首次出现，通常够用 if pos != -1: where = "overlay" if pos >= end else "节区内" print(f"命中 {label:<18} 首次出现于 {pos:,}（{where}）") if __name__ == "__main__": main(sys.argv[1])

e_lfanew是 DOS 头里指向 PE 头的指针，NumberOfSections在 PE 头 +6 处，SizeOfOptionalHeader在 +20 处，节区表从e_lfanew + 24 + opt_size开始，每个节区头 40 字节，其中 +16 是SizeOfRawData、+20 是PointerToRawData，这两个字段相乘相加就能算出最后一个节的结束位置，overlay 就是剩下的部分。

find只返回第一个命中位置，对判型足够；真要提取，还得按格式规范去解析头部字段，那是下一章的事。

提示：拿到一个来源不明的 exe，先跑脚本看清楚再说。直接双击验证“能不能装”，等于把判断权交给安装脚本。

2.3 封装类型与工具映射：别拿一把锤子敲所有钉子

判完型之后，工具选择基本没有自由度，每一类封装只有一两条靠谱路径。下面这张表是这些年反复验证下来最省事的组合，左列是识别特征，右列是对应动作。

表里最后一列的“常见失败点”比工具本身更值钱。同一个 NSIS 包，有人拆出来一切正常，有人拆出来主程序缺失，差别往往只在于有没有读[NSIS].nsi里的SetOutPath指令——安装时文件被铺到哪个目录，脚本里写得明明白白，照着还原就行，不需要猜。

还有一类容易被漏判的：双层封装。外层是 InstallShield 引导程序，里面套一个 MSI，MSI 里再套 CAB。这种包第一次拆完看到一堆.msi和.cab就以为结束了，实际上第二层才是文件本体。判断方法是看解出来的目录里有没有.msi，有就再走一遍管理员安装。

3. 四类主流安装包的解包实操：命令、产物与参数

分型只是把范围缩小，真正落地的动作在这一章。四类封装的处理方式差别很大，命令不能互相套用：Inno 必须用专用工具，NSIS 用 7-Zip 就够，MSI 走系统自带的管理员安装最稳，自解压包看模块配置。每条命令后面我都会说清楚产物长什么样，因为“解出来一堆文件但不知道哪个是主程序”是比解不开更常见的困境。

3.1 Inno Setup：innoextract 是唯一稳的路子

Inno 的载荷是自定义格式，通用归档工具一律无效。innoextract是专门为它写的，能读文件表、还原目录结构、还原原始文件名，还能只解不写盘先看一眼。

# 只列目录，不落盘。先看清楚里面有什么再决定解不解 innoextract -l setup.exe # 正式解包：-e 只解应用数据（跳过安装引擎的 DLL 和语言文件） # -d 指定输出目录，目录不存在会自动建 innoextract -e -d ./out setup.exe # 老包文件名乱码时，强制指定代码页。936 对应简体中文 innoextract -e -d ./out --codepage=936 setup.exe # 只要其中一部分：-I 是包含过滤，大小写敏感，支持通配 innoextract -e -d ./out -I "app/*.dll" setup.exe

-l的输出会分行列出每个条目和它的原始路径，注意看有没有app/前缀——Inno 把“要装到目标机的文件”统一放在app/下，其余tmp/、embedded/是安装过程用的临时资源和引擎文件，一般不需要。-e这个开关就是干这件事的：跳过非应用数据，产物干净得多。

--codepage是踩坑率最高的参数。Inno 老版本用 ANSI 存文件名，包是在什么语言的系统上编的，文件名就用什么代码页，在另一个语言环境里解出来就是问号或方块。简体中文的包给936，日文的给932，不确定的时候先-l看一眼：如果列表里文件名已经是乱码，加--codepage重来一次即可，不用删目录，覆盖解一遍就行。

产物结构大致是这样：out/app/下是完整的程序目录，可能还有out/app/bin/、out/app/locale/；同级的其他目录是安装引擎残留。判断主程序很简单——app/里体积最大的那个 exe，或者和目录同名的那个 exe，八成就是它。

3.2 NSIS：7-Zip 能开，但解出来的目录不是最终目录

NSIS 是 7-Zip 原生支持的格式，一条命令就出东西，代价是产物结构看起来有点乱，第一次见容易被吓到。

# -o 后面紧跟目录名，不能有空格；-y 全部覆盖，不交互 7z x -y -oout setup.exe # 想先看目录结构，把 x 换成 l，只列不写 7z l setup.exe # 大包解到一半想看进度，加 -bsp1 把进度打到 stdout 7z x -y -bsp1 -oout setup.exe

解出来的东西通常分三块。第一块是$PLUGINSDIR/，里面是安装过程中临时解压的插件 DLL 和界面资源，删掉不影响使用。第二块是[NSIS].nsi，这是安装脚本的反编译结果，也是最值钱的东西——它能告诉你安装时到底写了哪些注册表项、创建了哪些服务、文件被复制到哪里。第三块才是真正的文件树，但它的目录名往往不是最终目录名，因为 NSIS 的脚本里用变量表示目标路径。

读脚本时盯住两个指令：SetOutPath决定“接下来的文件放到哪”，File决定“放哪些文件”。一段典型的脚本长这样：

SetOutPath "$INSTDIR\bin" ; 之后写出的文件都进 <安装目录>\bin File "payload\core.dll" File "payload\worker.exe" SetOutPath "$INSTDIR" File "payload\launcher.exe"

照着这段把out/里的散装文件重新摆进bin/和根目录，就能还原出安装后的真实结构。这一步没有捷径，但脚本通常不长，几十行翻一遍就清楚了。老包如果是非 Unicode 版 NSIS 编的，文件名同样可能乱码，处理方式和 Inno 一致——换个中文环境或者按脚本里的原始名手工改名。

注意：$PLUGINSDIR里的 DLL 别急着删。有些安装包把真正的功能组件藏在插件 DLL 里，运行期才释放，先用strings扫一眼确认是界面库还是业务代码再决定。

3.3 InstallShield 与 MSI：走管理员安装，别手工拆 CAB

MSI 及其外层引导包的处理方式和其他几类完全不同：不要解压，要“安装到一个目录”。Windows Installer 自带这个能力，命令是msiexec /a，业内叫管理员安装（administrative install）。它按 MSI 数据库里记录的文件表和目录表，把每个文件展开到正确的相对路径下，产物直接就是一个可以拷走用的安装源目录。

# 对一个 msi 做管理员安装：/a 表示管理安装，/qb 显示基本进度条不弹交互 # TARGETDIR 必须是绝对路径，不要用相对路径，也不要在末尾加反斜杠 msiexec /a "D:\pkg\setup.msi" /qb TARGETDIR="D:\out" # 如果外层是引导包 exe，先让它把内层 msi 释放到临时目录， # 再对那个 msi 走上面的命令；多数引导包支持 /a 直接透传 msiexec /a "D:\pkg\setup.exe" /qb TARGETDIR="D:\out" # 拆 WiX 做的 Burn 引导包，用 WiX 工具链里的 dark： # -x 指定输出目录，-o 指定反编译出的 wxs 描述文件 dark.exe -x "D:\out" -o "D:\out\bundle.wxs" "D:\pkg\setup.exe"

/a和/i的区别值得说清楚：/i是正常安装，会写注册表、注册组件、建快捷方式；/a只是把文件按结构展开，不动系统状态。做离线部署包、做绿色化、做差异比对，要的都是后者。

TARGETDIR必须绝对路径，这一点没有例外，写相对路径的结果是文件散落到当前工作目录或者直接失败。另一个细节：/qb会弹一个进度条窗口，跑批处理时用/qn全静默更合适，但出问题时看不到任何提示，调试阶段建议先用/qb。

InstallShield 要分两代看。基于 MSI 的新版 IS 直接用上面这套流程；IS6 及更早的 InstallDev 老包不是 MSI，跑起来会把自己的内容解压到临时目录再安装，处理办法是启动安装程序，然后在%TEMP%下找_is开头的目录，趁安装向导停在第一步时把目录整个拷走。这个做法略脏，但对付二十年前的老包确实有效。

3.4 自解压包：7z SFX 与 RAR SFX 的命令行开关

自解压包（SFX）本质是“一个解压引擎 + 一段标准归档”，引擎在前，归档在后，正好对应 2.1 讲的 overlay。因为归档部分是标准格式，7-Zip 直接就能开，不需要跑那个 exe。

# 最稳的做法：绕开 SFX 引擎，直接当归档解 7z x -y -oout setup.exe # 也可以用 SFX 自己的开关，适合引擎支持命令行的情况 # -y 全部覆盖确认，-o 指定输出目录（这个开关由 SFX 模块决定是否存在） setup.exe -y -o"D:\out" # 判断 SFX 引擎类型：看 overlay 起始处的魔数 # 7z 是 37 7A BC AF 27 1C，RAR 是 52 61 72 21 1A 07 xxd -s <overlay偏移> -l 16 setup.exe

优先选第一条。SFX 模块在编译时可以关掉命令行解析、可以加密码、可以设成解压后自动运行某个脚本，直接用 7-Zip 拆归档能绕开所有这些不确定性。只有当 7-Zip 报“无法作为归档打开”时，才回头去试 SFX 自带的开关。

还有一种混合情况：外层是 NSIS，安装过程中在临时目录里释放一个 7z 自解压包再执行。这种包第一层解出来只有几个 DLL 和一个 exe，看不到业务文件，别急着判断失败，去找那个 exe，它才是第二层的入口。

4. 单文件程序与资源段：PyInstaller、.NET、Electron 怎么拆

有一类 exe 根本不是安装包，它自己就是程序，只是把运行时、依赖库、资源全塞进了一个文件。这类东西用安装包工具去解一定失败，因为它们没有安装脚本，只有一段自解压引导代码加一个打包清单。识别它们靠 2.2 那步的字符串扫描，处理它们靠本章这几种针对性打法。

4.1 PyInstaller 打包的 exe：还原 pyc 与版本边界

PyInstaller 会在 exe 尾部写入一个MEI标记和一份目录表（TOC），记录每个成员的名字、偏移、长度、是否压缩。专用脚本读这份表就能把PYZ-00.pyz、依赖 DLL、资源文件全提出来。

# pyinstxtractor 是单文件脚本，参数就是目标 exe python pyinstxtractor.py app.exe # 产物目录名固定为 <原名>_extracted ls app.exe_extracted/ # 典型内容：PYZ-00.pyz base_library.zip 若干 .pyc 若干 .pyd/.dll

拿到_extracted目录后，业务代码在里面的.pyc文件里，需要再反编译一步。这里有个硬边界必须先说：.pyc的字节码格式随 Python 版本变化，反编译工具通常只覆盖到某个版本为止，跑在 3.11 以上环境里打包的程序，用现成工具反编译大概率报Unsupported bytecode。解决办法不是硬试，而是看_extracted里附带的 Python DLL 版本号（比如python311.dll就是 3.11），装一个同大版本的 Python，再用支持该版本的工具处理。

.pyd是编译好的扩展模块，反编译不了，也不需要反编译，直接当二进制依赖用。资源文件（图标、模板、配置文件）通常在_extracted根目录或同名子目录下，这部分才是日常排障最常要的——比如某个工具把默认配置硬编进了包里，改不了，只能拆出来改完再放回去。

4.2 .NET 单文件：尾部清单与 runtimeconfig 缺失

.NET 的单文件发布（single-file publish）机制和 PyInstaller 类似但更规范：文件尾部有一段固定的 bundle 标记，标记前面是 manifest，manifest 里列出每个嵌入程序集的偏移、大小、压缩方式。抽取的方式有两种，一是用现成的 single-file 抽取脚本按 manifest 读，二是等程序首次运行时看它在%TEMP%\.net\下展开的目录——后者最省事，跑一次就有了。

# 方式一：临时目录法。程序启动时会把自身解包到用户临时目录 # 先运行一次目标程序，再去找展开目录 dir "%TEMP%\.net" /s /b | findstr /i "app" # 方式二：反编译。ilspycmd 是命令行版反编译器，输出 C# 工程 dotnet tool install -g ilspycmd ilspycmd -p -o ./src app.dll # 只看类型和成员签名，不生成工程，速度快很多 ilspycmd -l c app.dll

-p是把整个程序集还原成一个可编译的工程，-o指定输出目录，-l c只列类型（c 表示 class）。反编译出来的代码不能指望一次编译通过，混淆过的程序集变量名全是A、B、AA，但结构是完整的，用来理解逻辑、定位配置项足够。

真正容易翻车的地方在“拆出来跑不起来”。单文件发布时，app.deps.json和app.runtimeconfig.json这两个文件有时被嵌进包里、有时作为外部文件分发。只把 DLL 拷出来而缺runtimeconfig.json，运行时会直接报“找不到框架版本”。遇到这个报错，回头确认抽取工具有没有把这两个 json 一并导出，没有就手动补一个，内容照框架版本写。

4.3 Electron 应用：asar 包才是本体

Electron 打包的桌面程序，目录结构极其规整：主程序 exe 加一堆 Chromium 运行时 DLL，加一个resources/目录，业务代码全在resources/app.asar里。asar 是个简单的归档格式，头部是 JSON 索引，后面是拼接的文件内容，不改名、不加密。

# 列出 asar 里的文件树，先确认结构 npx @electron/asar list resources/app.asar # 解包到指定目录 npx @electron/asar extract resources/app.asar ./app_src # 反向打包：改完代码重新封回去 npx @electron/asar pack ./app_src resources/app.asar

解出来的app_src里通常有main.js（主进程）、package.json、renderer/或dist/（前端产物）。前端部分是压缩混淆过的 JS，可读性一般；主进程代码通常没混淆，能直接看出这个程序读了哪些配置、连了哪些地址、把用户数据存在哪。做离线部署时最常改的就是package.json里的启动参数和主进程里的配置路径，改完pack回去，覆盖原文件即可。

有些程序开了 asar 完整性校验，改了 asar 会导致启动失败。这种情况要么关掉校验（在校验配置里改），要么不解包、改用外挂配置文件的方式覆盖默认值。先试后者，代价小。

4.4 资源段：图标、清单、版本信息用脚本批量取

不管哪类 exe，PE 资源段里都固定存着图标、版本信息、应用清单（manifest）、字符串表。这些东西用图形工具一个个点很慢，写脚本批量取更快，也便于比对两个版本的差异。

# dump_res.py：导出 PE 资源段里的图标与版本信息 import pefile, os, sys def dump(path, outdir): os.makedirs(outdir, exist_ok=True) pe = pefile.PE(path) if not hasattr(pe, "DIRECTORY_ENTRY_RESOURCE"): print("没有资源段") return for entry in pe.DIRECTORY_ENTRY_RESOURCE.entries: # 资源类型：3=图标 14=图标组 16=版本信息 24=清单 rtype = pefile.RESOURCE_TYPE.get(entry.struct.Id, str(entry.struct.Id)) for res in entry.directory.entries: for lang in res.directory.entries: data = lang.data.struct blob = pe.get_data(data.OffsetToData, data.Size) # 图标组需要专门的拼装逻辑，这里先按类型+ID落盘 name = f"{rtype}_{res.struct.Id}_{lang.struct.Id}.bin" open(os.path.join(outdir, name), "wb").write(blob) print(f"{name:<32} {len(blob):>10,} 字节") if __name__ == "__main__": dump(sys.argv[1], sys.argv[2])

RESOURCE_TYPE是 pefile 内置的类型映射表，3 对应 RT_ICON，14 对应 RT_GROUP_ICON，16 对应 RT_VERSION，24 对应 RT_MANIFEST。导出的.bin里，版本信息是 UTF-16 编码的VS_VERSIONINFO结构，用文本编辑器打开能看到产品名、版本号、原始文件名；清单是 XML，直接就能读，能看出这个程序要求管理员权限还是普通权限、依赖哪个版本的运行库。

图标是唯一需要额外处理的部分：RT_GROUP_ICON 里存的是索引，真正的图像数据分散在多个 RT_ICON 条目里，要按组表拼装才能还原成.ico。日常用不着自己写，图形工具点两下导出的结果一样，脚本的价值在于批量——比对两个版本差了哪些资源、找出被替换掉的图标，手工做太慢。

5. 解包翻车现场：6 个常见问题与排查顺序

解包失败从来不是单一原因，但现场表现高度相似：文件少、文件乱码、文件打不开、文件能看不能跑。按下面的顺序排查，能省掉大量重复劳动——先确认封装层数，再看文件名表，再看体积对不对，最后才怀疑内容完整性。跳过前三步直接去猜“是不是加密了”，是最常见的低效路径。

5.1 现象：解出来一堆0、1、2或者问号方块

原因：安装包的文件名表用了非 Unicode 编码，工具按默认代码页解析，遇到超出范围的字节就退化成了序号或替换字符。Inno 老版本、非 Unicode 版 NSIS 都会这样，跟包有没有损坏无关。

解决：Inno 加--codepage=936（简体中文）或对应语言代码页重解一遍，覆盖原目录即可，不用清理。NSIS 先看[NSIS].nsi里的File指令，那里写的是原始文件名，照着手工改名；如果脚本本身也乱码，说明包确实是非 Unicode 编的，在中文区域设置的系统上重跑一次 7-Zip 通常就正常了。还有个小技巧：7z l列表里如果文件名显示正常，说明解压时的编码判断出错，换个版本的工具往往能绕过。

5.2 现象：解出来的总体积比安装包小一大截，某些文件明显被截断

原因：有三种可能，按概率排序是多层封装只解了第一层、载荷跨节区导致偏移算错、以及包用了固实压缩（solid）导致单独取某个成员时解不完整。

解决：先看解出来的目录里有没有.msi、.cab、.7z、.zip，有就说明还有下一层，继续解。再看probe_exe.py输出的 overlay 长度和文件总大小的关系，如果 overlay 比文件小很多，说明载荷分散在多个节区里，得换用支持完整解析的工具而不是靠魔数扫描。最后用7z t做一次完整性测试，报 CRC 错误才是真的传输损坏，没报错就别怀疑文件本身。

5.3 现象：解出来的 exe 双击就报“找不到 XXX.dll”或“应用程序无法正常启动 0xc000007b”

原因：解包不等于安装。安装脚本在复制文件之外还做了三件事——写注册表、注册 COM 组件、安装运行库。这三件事解包工具一件都不做，所以程序找不到依赖是必然的，和包本身没关系。

解决：回去读脚本。NSIS 看[NSIS].nsi里的WriteRegStr、RegDLL、ExecWait；Inno 看install_script.iss里的[Registry]、[Run]段。把注册表项按脚本手工补上，把ExecWait里调用的运行库安装包单独装一遍。0xc000007b 基本就是 32/64 位运行库装混了，装对应架构的 VC 运行库即可。这一步的工程量经常比解包本身还大，评估工作量时别漏算。

5.4 现象：反编译.pyc或.dll时报版本不支持、语法错误

原因：字节码和 IL 都有版本，工具的支持范围永远滞后于最新发布。PyInstaller 打的包如果用的是新版本 Python，反编译工具直接不认；.NET 的混淆器也会故意插入非法 IL 让反编译失败。

解决：先确定版本，再看工具支持矩阵，不要硬试。Python 包看目录里的python3XX.dll，.NET 看runtimeconfig.json里的tfm字段，版本对上了再选工具。反编译只用于理解逻辑和恢复配置，不做二次分发，这条边界得守住。

5.5 现象：病毒查杀软件报警，或者解包工具本身被拦截

原因：自解压引擎、加壳程序、以及“从 exe 里往外掏文件”这个行为模式，都命中了启发式规则。误报率不低，但也确实有一部分安装包捆绑了推广组件——这两件事在行为上很像。

解决：先确认来源，只处理自有或已授权的安装包，来源不明的包不要在自己的工作机上跑。必须处理时，在隔离的虚拟机里操作，处理完直接销毁快照。解包工具本身被拦截，换成命令行版本、加白名单目录，比关掉查杀软件安全得多。

5.6 现象：所有工具都打不开，提示“不是有效的归档文件”

原因：程序被 UPX 或商业壳压过，PE 结构被改写，原本能被识别的节区和 overlay 都变了形状；或者这个 exe 压根不是安装包，是加了壳的业务程序。

解决：先跑file看有没有UPX之类的标记。UPX 压的可以直接upx -d app.exe -o unpacked.exe脱壳，脱完再判型，成功率很高。商业壳没有通用解法，而且破解壳这件事本身超出了资源提取的范畴，遇到就停手，别在这上面耗时间。

6. 校验与复用：把解出来的目录做成可交付的部署包

解包完成不等于交付完成。真正干活的时候，你面对的往往是“同一软件的三个版本要对比”“解出来的目录要能证明和官方安装结果一致”“下个月再来一次还得复现”。这时候需要的不是再解一遍，而是一套校验和快照的做法。

我一般会做两张表。第一张是哈希清单，对解包产物逐文件算 SHA-256，按相对路径排序输出，用来和“正常安装后的目录”做逐行比对；第二张是结构快照，只记目录层级和文件数量，用来快速判断两次解包有没有结构性差异。两张表都用脚本生成，不要手工维护。

# 生成哈希清单：相对路径 + 哈希，按路径排序，便于 diff # -print0 和 -d '' 是为了兼容带空格的文件名 find ./out -type f -print0 \ | sort -z \ | xargs -0 sha256sum \ | sed 's#\./out/##' \ > manifest.sha256 # 与官方安装结果比对：只输出差异行 diff <(sort manifest.sha256) <(sort installed.sha256) # 结构快照：只要目录和文件计数，速度快，适合放进流水线 find ./out -type d | sort > dirs.txt find ./out -type f | wc -l

manifest.sha256的排序很关键，find的输出顺序依赖文件系统，不排序的话两次结果 diff 出来全是噪声。sed那一步是把前缀去掉，让清单里的路径变成相对路径，这样在另一台机器上生成的清单可以直接比。

比对结果通常有三种。完全一致，说明解包路径选对了，可以固化命令。文件数量一致但哈希不同，多半是时间戳或版本号嵌在文件里，属于正常差异，看差异集中在哪几个文件就能判断。文件数量不一致，就是结构性问题，回头查 5.2。

第二张表看着简陋，实战里反而更常用。差异只在几个文件上，说明是补丁版本；整个目录多出一层，说明封装方式变了，之前的命令不能照抄。

最后一个技巧，也是我这些年养成的习惯：每个安装包处理完，把判型结果、用过的命令、产物哈希清单三样东西写进同一个文本文件，跟产物放在一起。半年后再看，不用重新回忆这个包是 NSIS 还是 Inno，也不用重新试错一遍参数。有次回滚一个老系统，靠的就是当初留下的三行命令，前后不到十分钟；而同一批里没留记录的那几个包，花了整整一个下午重新判型、重新试代码页。从那以后我每次解包都强制走一遍"判型 → 命令 → 清单"这三步，绝不省。希望帮到你。

本文还有配套的精品资源，点击获取