简介面向开发者、逆向工程学习者及需要查看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 -20strings那一步的命中结果直接对应封装类型出现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 [ (b7z\xbc\xaf\x27\x1c, 7z 自解压), (bRar!\x1a\x07, RAR 自解压), (bMSCF, CAB / MSI), (bMEI\x0c\x0b\x0a\x0b\x0e, PyInstaller), (bNullsoft, NSIS), (bInno Setup, Inno Setup), (bInstallShield, InstallShield), (bWixBundle, WiX Burn 引导包), ] def pe_sections(buf): 返回 [(节区名, 文件偏移, 原始大小), ...] e_lfanew struct.unpack_from(I, buf, 0x3C)[0] # PE 头偏移 assert buf[e_lfanew:e_lfanew 4] bPE\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字符串含Nullsoft7z 显示Type Nsis7-Zip 直接x文件树 [NSIS].nsi脚本主程序藏在$INSTDIR分支里Inno Setup含Inno Setup Setup Datainnoextractapp/目录即真实文件树老版本代码页导致文件名乱码InstallShield含InstallShield旁边常见data1.cab管理员安装或data1.cab直取MSI 结构目录IS6 老包必须在运行中抓临时目录MSI / Burn 引导包含MSCF或WixBundlemsiexec /a或 WiX 的dark展开后的安装源目录用 7-Zip 直拆得到一堆无名 CAB7z / RAR 自解压overlay 里有对应魔数7-Zip 直接x原始归档内容模块被编译时禁用了命令行参数PyInstaller 打包含MEI标记pyinstxtractor_extracted目录 pycPython 版本不匹配无法反编译表里最后一列的“常见失败点”比工具本身更值钱。同一个 NSIS 包有人拆出来一切正常有人拆出来主程序缺失差别往往只在于有没有读[NSIS].nsi里的SetOutPath指令——安装时文件被铺到哪个目录脚本里写得明明白白照着还原就行不需要猜。还有一类容易被漏判的双层封装。外层是 InstallShield 引导程序里面套一个 MSIMSI 里再套 CAB。这种包第一次拆完看到一堆.msi和.cab就以为结束了实际上第二层才是文件本体。判断方法是看解出来的目录里有没有.msi有就再走一遍管理员安装。3. 四类主流安装包的解包实操命令、产物与参数分型只是把范围缩小真正落地的动作在这一章。四类封装的处理方式差别很大命令不能互相套用Inno 必须用专用工具NSIS 用 7-Zip 就够MSI 走系统自带的管理员安装最稳自解压包看模块配置。每条命令后面我都会说清楚产物长什么样因为“解出来一堆文件但不知道哪个是主程序”是比解不开更常见的困境。3.1 Inno Setupinnoextract 是唯一稳的路子Inno 的载荷是自定义格式通用归档工具一律无效。innoextract是专门为它写的能读文件表、还原目录结构、还原原始文件名还能只解不写盘先看一眼。# 只列目录不落盘。先看清楚里面有什么再决定解不解 innoextract -l setup.exe # 正式解包-e 只解应用数据跳过安装引擎的 DLL 和语言文件 # -d 指定输出目录目录不存在会自动建 innoextract -e -d ./out setup.exe # 老包文件名乱码时强制指定代码页。936 对应简体中文 innoextract -e -d ./out --codepage936 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 NSIS7-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走管理员安装别手工拆 CABMSI 及其外层引导包的处理方式和其他几类完全不同不要解压要“安装到一个目录”。Windows Installer 自带这个能力命令是msiexec /a业内叫管理员安装administrative install。它按 MSI 数据库里记录的文件表和目录表把每个文件展开到正确的相对路径下产物直接就是一个可以拷走用的安装源目录。# 对一个 msi 做管理员安装/a 表示管理安装/qb 显示基本进度条不弹交互 # TARGETDIR 必须是绝对路径不要用相对路径也不要在末尾加反斜杠 msiexec /a D:\pkg\setup.msi /qb TARGETDIRD:\out # 如果外层是引导包 exe先让它把内层 msi 释放到临时目录 # 再对那个 msi 走上面的命令多数引导包支持 /a 直接透传 msiexec /a D:\pkg\setup.exe /qb TARGETDIRD:\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 -oD:\out # 判断 SFX 引擎类型看 overlay 起始处的魔数 # 7z 是 37 7A BC AF 27 1CRAR 是 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 标记标记前面是 manifestmanifest 里列出每个嵌入程序集的偏移、大小、压缩方式。抽取的方式有两种一是用现成的 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 资源段图标、清单、版本信息用脚本批量取不管哪类 exePE 资源段里都固定存着图标、版本信息、应用清单manifest、字符串表。这些东西用图形工具一个个点很慢写脚本批量取更快也便于比对两个版本的差异。# dump_res.py导出 PE 资源段里的图标与版本信息 import pefile, os, sys def dump(path, outdir): os.makedirs(outdir, exist_okTrue) 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_ICON14 对应 RT_GROUP_ICON16 对应 RT_VERSION24 对应 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 加--codepage936简体中文或对应语言代码页重解一遍覆盖原目录即可不用清理。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、ExecWaitInno 看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 -lmanifest.sha256的排序很关键find的输出顺序依赖文件系统不排序的话两次结果 diff 出来全是噪声。sed那一步是把前缀去掉让清单里的路径变成相对路径这样在另一台机器上生成的清单可以直接比。比对结果通常有三种。完全一致说明解包路径选对了可以固化命令。文件数量一致但哈希不同多半是时间戳或版本号嵌在文件里属于正常差异看差异集中在哪几个文件就能判断。文件数量不一致就是结构性问题回头查 5.2。第二张表看着简陋实战里反而更常用。差异只在几个文件上说明是补丁版本整个目录多出一层说明封装方式变了之前的命令不能照抄。最后一个技巧也是我这些年养成的习惯每个安装包处理完把判型结果、用过的命令、产物哈希清单三样东西写进同一个文本文件跟产物放在一起。半年后再看不用重新回忆这个包是 NSIS 还是 Inno也不用重新试错一遍参数。有次回滚一个老系统靠的就是当初留下的三行命令前后不到十分钟而同一批里没留记录的那几个包花了整整一个下午重新判型、重新试代码页。从那以后我每次解包都强制走一遍判型 → 命令 → 清单这三步绝不省。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/2 3:55:25 · 阅读 1.2k EXE安装包解包实战：判型、提取与校验
简介面向开发者、逆向工程学习者及需要查看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 -20strings那一步的命中结果直接对应封装类型出现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 [ (b7z\xbc\xaf\x27\x1c, 7z 自解压), (bRar!\x1a\x07, RAR 自解压), (bMSCF, CAB / MSI), (bMEI\x0c\x0b\x0a\x0b\x0e, PyInstaller), (bNullsoft, NSIS), (bInno Setup, Inno Setup), (bInstallShield, InstallShield), (bWixBundle, WiX Burn 引导包), ] def pe_sections(buf): 返回 [(节区名, 文件偏移, 原始大小), ...] e_lfanew struct.unpack_from(I, buf, 0x3C)[0] # PE 头偏移 assert buf[e_lfanew:e_lfanew 4] bPE\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字符串含Nullsoft7z 显示Type Nsis7-Zip 直接x文件树 [NSIS].nsi脚本主程序藏在$INSTDIR分支里Inno Setup含Inno Setup Setup Datainnoextractapp/目录即真实文件树老版本代码页导致文件名乱码InstallShield含InstallShield旁边常见data1.cab管理员安装或data1.cab直取MSI 结构目录IS6 老包必须在运行中抓临时目录MSI / Burn 引导包含MSCF或WixBundlemsiexec /a或 WiX 的dark展开后的安装源目录用 7-Zip 直拆得到一堆无名 CAB7z / RAR 自解压overlay 里有对应魔数7-Zip 直接x原始归档内容模块被编译时禁用了命令行参数PyInstaller 打包含MEI标记pyinstxtractor_extracted目录 pycPython 版本不匹配无法反编译表里最后一列的“常见失败点”比工具本身更值钱。同一个 NSIS 包有人拆出来一切正常有人拆出来主程序缺失差别往往只在于有没有读[NSIS].nsi里的SetOutPath指令——安装时文件被铺到哪个目录脚本里写得明明白白照着还原就行不需要猜。还有一类容易被漏判的双层封装。外层是 InstallShield 引导程序里面套一个 MSIMSI 里再套 CAB。这种包第一次拆完看到一堆.msi和.cab就以为结束了实际上第二层才是文件本体。判断方法是看解出来的目录里有没有.msi有就再走一遍管理员安装。3. 四类主流安装包的解包实操命令、产物与参数分型只是把范围缩小真正落地的动作在这一章。四类封装的处理方式差别很大命令不能互相套用Inno 必须用专用工具NSIS 用 7-Zip 就够MSI 走系统自带的管理员安装最稳自解压包看模块配置。每条命令后面我都会说清楚产物长什么样因为“解出来一堆文件但不知道哪个是主程序”是比解不开更常见的困境。3.1 Inno Setupinnoextract 是唯一稳的路子Inno 的载荷是自定义格式通用归档工具一律无效。innoextract是专门为它写的能读文件表、还原目录结构、还原原始文件名还能只解不写盘先看一眼。# 只列目录不落盘。先看清楚里面有什么再决定解不解 innoextract -l setup.exe # 正式解包-e 只解应用数据跳过安装引擎的 DLL 和语言文件 # -d 指定输出目录目录不存在会自动建 innoextract -e -d ./out setup.exe # 老包文件名乱码时强制指定代码页。936 对应简体中文 innoextract -e -d ./out --codepage936 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 NSIS7-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走管理员安装别手工拆 CABMSI 及其外层引导包的处理方式和其他几类完全不同不要解压要“安装到一个目录”。Windows Installer 自带这个能力命令是msiexec /a业内叫管理员安装administrative install。它按 MSI 数据库里记录的文件表和目录表把每个文件展开到正确的相对路径下产物直接就是一个可以拷走用的安装源目录。# 对一个 msi 做管理员安装/a 表示管理安装/qb 显示基本进度条不弹交互 # TARGETDIR 必须是绝对路径不要用相对路径也不要在末尾加反斜杠 msiexec /a D:\pkg\setup.msi /qb TARGETDIRD:\out # 如果外层是引导包 exe先让它把内层 msi 释放到临时目录 # 再对那个 msi 走上面的命令多数引导包支持 /a 直接透传 msiexec /a D:\pkg\setup.exe /qb TARGETDIRD:\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 -oD:\out # 判断 SFX 引擎类型看 overlay 起始处的魔数 # 7z 是 37 7A BC AF 27 1CRAR 是 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 标记标记前面是 manifestmanifest 里列出每个嵌入程序集的偏移、大小、压缩方式。抽取的方式有两种一是用现成的 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 资源段图标、清单、版本信息用脚本批量取不管哪类 exePE 资源段里都固定存着图标、版本信息、应用清单manifest、字符串表。这些东西用图形工具一个个点很慢写脚本批量取更快也便于比对两个版本的差异。# dump_res.py导出 PE 资源段里的图标与版本信息 import pefile, os, sys def dump(path, outdir): os.makedirs(outdir, exist_okTrue) 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_ICON14 对应 RT_GROUP_ICON16 对应 RT_VERSION24 对应 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 加--codepage936简体中文或对应语言代码页重解一遍覆盖原目录即可不用清理。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、ExecWaitInno 看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 -lmanifest.sha256的排序很关键find的输出顺序依赖文件系统不排序的话两次结果 diff 出来全是噪声。sed那一步是把前缀去掉让清单里的路径变成相对路径这样在另一台机器上生成的清单可以直接比。比对结果通常有三种。完全一致说明解包路径选对了可以固化命令。文件数量一致但哈希不同多半是时间戳或版本号嵌在文件里属于正常差异看差异集中在哪几个文件就能判断。文件数量不一致就是结构性问题回头查 5.2。第二张表看着简陋实战里反而更常用。差异只在几个文件上说明是补丁版本整个目录多出一层说明封装方式变了之前的命令不能照抄。最后一个技巧也是我这些年养成的习惯每个安装包处理完把判型结果、用过的命令、产物哈希清单三样东西写进同一个文本文件跟产物放在一起。半年后再看不用重新回忆这个包是 NSIS 还是 Inno也不用重新试错一遍参数。有次回滚一个老系统靠的就是当初留下的三行命令前后不到十分钟而同一批里没留记录的那几个包花了整整一个下午重新判型、重新试代码页。从那以后我每次解包都强制走一遍判型 → 命令 → 清单这三步绝不省。希望帮到你。本文还有配套的精品资源点击获取