EXE解压与资源提取：PE判型、安装包解包及校验实战

简介面向开发者、逆向分析学习者与需要查看程序内嵌素材的用户这份EXE可执行文件解压工具提供了一条从可执行程序中提取图像、文本、声音及其他二进制资源的途径也可用于观察EXE内部结构与资源组织方式。压缩包共167个文件约5.14MB以91个txt说明文档、42个exe程序、11个unp及7个dll组件为主另含wcx插件、ini配置、doc手册与少量htm、ico等主体围绕UniExtract及多款解包引擎展开并配有许可、变更记录和docs文档便于了解工具能力边界与使用条件。已有3511人学习下载。读者可借此掌握常见EXE资源提取流程理解不同解包引擎的适用场景并从配置与文档中获取排错和扩展思路对教学演示、素材复用和软件结构分析有参考价值使用时需遵守版权法规与软件许可条款。1. EXE 解压不是解压缩先弄清你要从哪个壳里抠东西搜「EXE 文件解压」的人十有八九撞上过同一堵墙把安装包后缀改成 .zip解出来一堆乱码用压缩软件右键“打开”报“无法作为压缩包打开”好不容易抠出几个 .bin双击全是“不是有效的 Win32 应用程序”。问题不在手气而在于 EXE 只是一层外壳——真正的载荷可能躺在 PE 资源段、可能挂在最后一个节之后的附加数据里、也可能被 InstallShield 那种老式压缩容器包了三层。动手前先花两分钟判断封装类型比盲目换五个工具省事得多。这篇按“先分流、再提取、最后校验”的顺序把四类常见封装、两条提取链路和六个真实翻车点讲透适合需要从安装包或工具里取出资源、DLL、配置文件的从业者。2. 先分流再动手四类 EXE 封装与它们的识别指纹同一个 .exe 后缀下至少混着四种完全不同的东西普通 PE 程序载荷在资源段和代码段里、安装包NSIS / Inno Setup / InstallShield / MSI载荷在自有的压缩容器里、自解压包SFX载荷是追加在 PE 尾部的一段压缩流、以及加壳程序载荷被加密压缩运行时才在内存里还原。四类的提取手法互不通用所以第一步永远是判型不是找工具。判型不需要逆向功底读 PE 头加几个字节签名就够。下面这套流程我一般会固定走一遍先看节表和熵值再看附加数据里的格式签名最后才决定用 pefile 抠资源还是用专门的解包器。顺序反了容易白干——比如对着一个加壳程序反复尝试 7-Zip得到的永远只有那句“无法作为压缩包打开”。2.1 从 MZ 到节表三分钟读出一个 EXE 的骨架Windows 可执行文件是 PE 格式开头两个字节固定是4D 5AASCII 的 MZ偏移0x3C处的 4 字节小端整数指向 PE 签名50 45 00 00。PE 签名之后是 20 字节的 COFF 文件头其中NumberOfSections决定后面跟多少条节表记录每条 40 字节。节表才是判型的主战场正常的编译器产物通常有.text、.rdata、.data、.rsrc、.reloc这几节一旦看到UPX0、UPX1、.aspack、.themida、.vmp0这种名字基本可以直接判定为加壳。普通 PE 程序里值得提取的东西集中在两处。一是资源段.rsrc图标、位图、对话框模板、字符串表、版本信息、清单文件以及大量程序把内嵌的 DLL、驱动、配置文件以RCDATA类型塞在这里。二是导入表能看出它依赖哪些 DLL对判断提取物能不能跑起来很关键。不装任何工具也能做初步判断用十六进制编辑器跳到0x3C读偏移再跳过去看是不是PE\0\0。但手工数节表太费劲装个 Python 环境用 pefile 更省事import pefile pe pefile.PE(sample.exe, fast_loadTrue) # 入口点、镜像基址、节区对齐这三个值在手工计算 RVA 偏移时要用 print(EntryPoint :, hex(pe.OPTIONAL_HEADER.AddressOfEntryPoint)) print(ImageBase :, hex(pe.OPTIONAL_HEADER.ImageBase)) print(PE 类型 :, PE32 if pe.OPTIONAL_HEADER.Magic 0x20B else PE32) # 逐节打印名字、内存大小、文件中的原始大小、熵值 for s in pe.sections: name s.Name.rstrip(b\x00).decode(utf-8, replace) print(f{name:10} vsize{s.Misc_VirtualSize:8} raw{s.SizeOfRawData:8} fentropy{s.get_entropy():.3f} char{hex(s.Characteristics)})代码里fast_loadTrue让 pefile 跳过解析导入表、资源表这些耗时目录只保留头部信息判断阶段够用且快。get_entropy()返回该节内容的香农熵取值 0 到 8正常代码和数据通常在 4.5 到 6.5 之间超过 7.2 基本可以认定这一节是高压缩率或加密内容。注意熵高不必然是壳纯资源节塞了大量压缩过的图片或已压缩的载荷也会偏高要结合节名一起看——节名叫.rsrc且熵 7.9说明里面塞的是压缩流而不是普通图标。Characteristics里有个0x20000000位表示该节可执行0x40000000表示可读0x80000000表示可写。一个熵接近 8 又可读可写可执行的节几乎就是壳的解压后代码区。2.2 安装包族NSIS、Inno Setup、InstallShield、MSI 的差异安装包是把“压缩 安装逻辑”打包成一个 PE 的产物四家主流方案的结构差别很大用错工具就等于白试。封装类型典型识别特征首选提取方式备注NSIS附加数据或节区中出现NullsoftInst字样7-Zip 直接打开兼容性最好多数版本可直接列出文件树Inno Setup附加数据中有Inno Setup Setup Data标记innoextract支持列出、按组件选择性提取InstallShield内嵌MSCFCAB或自有压缩段7-Zip 尝试失败再手工定位 CAB老版本常需二次解 CABMSI本质是 OLE 复合文档不是 PEmsiexec /a管理安装提取结果仍需再解 CAB通用自解压 SFXPE 尾部跟7z/Rar!签名直接改后缀或用 7-Zip 打开相当于“PE 压缩包”拼接NSIS 的判定最简单在文件里搜 ASCII 字符串NullsoftInst命中即确认。Inno Setup 则搜Inno Setup Setup Data注意不同大版本之间这段标记的措辞略有差异但前十几个字符足够定位。InstallShield 麻烦一些它把文件压进 CABCAB 头是MSCF四个字节在文件里可能有多个需要用签名扫描把所有 CAB 起止位置找出来。MSI 单独说一句它根本不是 PE 文件没有 MZ 头用十六进制看开头是D0 CF 11 E0OLE 复合文档签名。很多人拿 7-Zip 打不开就以为文件坏了其实是方向错了。2.3 自解压 SFX压缩流藏在最后一个节之后自解压包是“一个小型解压器 一段压缩数据”的拼接体。解压器是标准 PE压缩数据挂在最后一个节的PointerToRawData SizeOfRawData之后——这段区域 PE 加载器根本不看所以能随便追加东西。因此判断方法很直接算出所有节的文件末尾最大值与文件实际大小比对。差值几千字节到几 MB 以上就说明有附加数据。再用签名扫描确认附加数据是什么格式格式十六进制签名ASCII 表现7z37 7A BC AF 27 1C7z¼¯RAR452 61 72 21 1A 07 00Rar!RAR552 61 72 21 1A 07 01 00Rar!ZIP50 4B 03 04PK..CAB4D 53 43 46MSCFimport pefile pe pefile.PE(sfx_sample.exe, fast_loadTrue) end_of_last_section max(s.PointerToRawData s.SizeOfRawData for s in pe.sections) overlay_size len(open(sfx_sample.exe, rb).read()) - end_of_last_section print(最后一个节结束于:, end_of_last_section) print(附加数据长度 :, overlay_size)overlay_size为正且大于 1KB基本可以判定是 SFX 或安装包。这个数值也是后面截断提取的依据从end_of_last_section开始到文件末尾原样切出来就是压缩流本体。有些 SFX 会在压缩流前再插一段自定义头记录文件名、解压路径、命令行参数所以截出来的东西不一定能直接被 7-Zip 认出需要按签名位置而不是节尾位置切。2.4 熵值与导入表判断“能不能直接解”的两个硬指标分流到这一步还剩一个关键问题这个文件到底能不能“无损取出”两个指标给出答案。第一个是导入表大小。正常程序导入函数动辄几十上百个分布在多个 DLL 上。加壳程序的导入表往往只有个位数——壳自己在运行时才填充真正的导入地址表。用 pefile 数一下DIRECTORY_ENTRY_IMPORT里的条目数少于 5 个又是个功能完整的工具八成有壳。第二个是整体熵值。把所有节的熵按文件大小加权平均超过 7.0 就要警惕。这时候硬解出来的资源很可能只是一堆加密后的随机字节看着像文件打开全是垃圾。提示遇到加壳程序提取资源这一步基本走不通。壳在磁盘上是加密态只有运行时才在内存里还原。这篇只讨论未加壳或仅做简单压缩的 PE、安装包、SFX不涉及脱壳。判型结论会直接决定走哪条链路普通 PE 走资源目录树遍历安装包走专用解包器SFX 走附加数据截断。三类之外的文件先放着别硬来。3. 从签名到落盘资源与安装包的两条提取链路判完型就能动手了。这一段把两条主链路拆开写一条面向普通 PE 的资源目录树用 pefile 逐层遍历后按类型落盘一条面向安装包和 SFX靠命令行工具和附加数据截断。两条链路的共同点是“先列清单、再动手”先看清楚里面有什么再决定抠哪些避免解出一堆没名字的 .bin 之后对着发呆。3.1 用 pefile 把资源目录树走一遍PE 的资源段是一个三层树第一层是资源类型图标、位图、RCDATA、版本信息……第二层是资源名或 ID第三层是语言 ID最底下才是真正的数据条目。每一层都可能是“按 ID 命名”或“按字符串命名”代码里必须两种都处理否则遇到字符串命名的资源会直接抛异常。import os import pefile RT_NAMES { 1: cursor, 2: bitmap, 3: icon, 4: menu, 5: dialog, 6: string, 9: accelerator, 10: rcdata, 11: message_table, 12: group_cursor, 14: group_icon, 16: version, 24: manifest, } pe pefile.PE(sample.exe) # 这里不能 fast_load必须解析资源目录 out_dir dump_res os.makedirs(out_dir, exist_okTrue) for type_entry in pe.DIRECTORY_ENTRY_RESOURCE.entries: # 类型层可能是 ID也可能是字符串名 type_id type_entry.id if type_entry.id is not None else -1 type_name RT_NAMES.get(type_id, str(type_entry.name) if type_entry.name else ftype{type_id}) for name_entry in type_entry.directory.entries: res_id name_entry.id if name_entry.id is not None else -1 for lang_entry in name_entry.directory.entries: data_struct lang_entry.data.struct lang_id lang_entry.id if lang_entry.id is not None else 0 # OffsetToData 是 RVA必须转成文件偏移才能读到正确位置 offset pe.get_offset_from_rva(data_struct.OffsetToData) raw pe.get_data(data_struct.OffsetToData, data_struct.Size) fname f{type_name}_{res_id}_{lang_id}.bin with open(os.path.join(out_dir, fname), wb) as f: f.write(raw) print(f{fname:36} {data_struct.Size:8} bytes file_off0x{offset:X})几个容易踩的点写在代码里了这里展开说。pe.get_data()内部会做 RVA 到文件偏移的换算但它依赖节表映射跨节的大资源比如几 MB 的 RCDATA如果落在节的填充区之外就会读错稳妥做法是自己用get_offset_from_rva拿到文件偏移后直接seek读文件。第三层语言 ID 常见值是 1033英文、2052简体中文同一份资源可能有多语言版本全部导出再比对别只取第一个。RT_NAMES只覆盖了常见类型索引 10 的rcdata是最值得盯的一类——大量程序把内嵌的 DLL、驱动、配置文件原封不动塞在这里导出后往往能直接用。3.2 资源落盘的命名规则与图标重组导出只是第一步落盘之后还有两件收尾事。一是命名。上面按类型_ID_语言.bin命名好处是不会互相覆盖坏处是完全看不出内容。我的习惯是先按类型跑一遍再用文件头判断真实格式并改后缀文件头判定格式改后缀4D 5APE 可执行.exe / .dll50 4B 03 04ZIP.zip89 50 4E 47PNG.pngFF D8 FFJPEG.jpg3C 3F 78 6DXML.xml7B 22或5B 7BJSON.json二是图标重组。PE 里的图标分两种资源RT_ICON类型 3存的是各个尺寸的单张位图数据RT_GROUP_ICON类型 14存的是“图标组”结构里面记录了该组包含哪几个尺寸、各自的资源 ID。直接拿单张 RT_ICON 数据是打不开的因为缺少 ICO 文件头。要还原成能双击的 .ico得解析 GROUP_ICON 结构取出每个成员的尺寸和 ID再按 ICO 格式重新拼文件头。这一步纯手工拼比较繁琐我一般先用上面的脚本把两类资源都导出再拿现成的图标工具按组拼回去比手写二进制组装省时间。提示版本信息类型 16导出后是一段二进制结构不是纯文本。想看可读内容用 PowerShell 的(Get-Item .\sample.exe).VersionInfo更快能直接拿到产品名、文件版本、公司名这些字段。3.3 安装包解包三条命令覆盖八成场景安装包不需要写脚本现成工具足够。按判型结果选一条# NSIS / 通用自解压7-Zip 直接列目录再解 7z l package.exe 7z x package.exe -o./out_7z -y # Inno Setup先列清单确认内容再按需提取 innoextract -l package.exe innoextract -e -d ./out_inno package.exe # MSI管理安装把源文件布局展开到目标目录 msiexec /a setup.msi /qb TARGETDIRC:\out_msi7z x的-o后面不能有空格-o./out_7z是对的-o ./out_7z会被当成另一个参数这是最高频的手误。-y表示全部确认批量跑的时候必须加否则会卡在交互提示上。innoextract -l先列清单这一步值得养成习惯。Inno 安装包经常把运行时、多语言文件、示例数据全打进去一次全解可能几百 MB而你要的可能只是其中两个 DLL。看完清单再用--include过滤能省很多清理时间。msiexec /a是管理安装它不装到系统里、不写注册表只把 MSI 内部的源文件布局展开成一个目录树。但展开出来的通常还是 .cab 压缩包加一个 .msi 副本需要再解一次 CAB# Windows 自带 expand或 7z 都能解 CAB expand -F:* C:\out_msi\Data.cab C:\out_msi\extracted判断该解哪个 CAB看目录里哪个 .cab 体积最大或者直接7z l C:\out_msi\Data.cab看内容对不对得上你要的东西。3.4 SFX 附加数据的定位与截断SFX 的处理逻辑是“切出来再当压缩包打开”两步。import pefile src sfx_sample.exe with open(src, rb) as f: blob f.read() pe pefile.PE(datablob, fast_loadTrue) start max(s.PointerToRawData s.SizeOfRawData for s in pe.sections) # 在附加数据区里找压缩流签名找到的第一个位置才是真正起点 signatures { b\x37\x7a\xbc\xaf\x27\x1c: 7z, bRar!\x1a\x07\x00: rar4, bRar!\x1a\x07\x01\x00: rar5, bPK\x03\x04: zip, bMSCF: cab, } for sig, fmt in signatures.items(): pos blob.find(sig, start) if pos ! -1: out fpayload.{fmt} with open(out, wb) as f: f.write(blob[pos:]) print(f命中 {fmt}起点 0x{pos:X}已写出 {out}) break else: print(附加数据区未识别到已知压缩签名可能需要人工看头部)关键在blob.find(sig, start)的第二个参数——从节尾开始搜避免误命中 PE 内部的随机字节。找到签名后从该位置原样切到文件末尾得到的就是一个标准压缩包后续交给 7-Zip 或 unrar 正常处理即可。有些 SFX 的压缩流前面还有一段厂商自定义头记录解压路径、命令行、许可证文本这种切出来的文件 7-Zip 会报“尾部有额外数据”但仍然能解属于正常现象不用理会警告。真正解不开的情况通常是压缩流本身被加密那就超出提取范畴了。4. 解包翻车实录六类故障的排查顺序这一章是纯经验堆出来的。同一批文件我重复解过很多次出问题的位置高度集中所以下面按“打开阶段 → 内容阶段 → 运行阶段”的顺序排遇到问题从上往下对照比乱试工具快。4.1 打不开工具报“无法作为压缩包打开”现象7-Zip 右键打开 EXE弹“无法将文件作为压缩包打开”换 WinRAR 也一样。原因三种可能按概率排——它不是 7-Zip 支持的封装比如 InstallShield 的老版本或自定义安装器它是加壳程序磁盘上根本没有可识别的压缩流压缩流被加密签名存在但内容解不开。解决先跑第 2 章的节表脚本看节名和熵值。节名正常、熵值中等、附加数据存在但签名不识别就用 binwalk 做一次全文件签名扫描binwalk package.exe输出里出现Microsoft Visual C compiled之类的只是普通特征重点看有没有Zip archive、Cabinet、7-zip archive这些条目及其偏移。找到偏移后用dd精准切dd ifpackage.exe ofpayload.cab bs1 skip$((0x1A2B00)) statusprogressskip用十进制十六进制要加$((0x...))转换。切出来的文件先用file或7z l验证格式再继续。如果节表显示熵值 7.9 以上、导入表条目只剩三五个那就是加壳这条链路到此为止。4.2 打开了但内容不对解出一堆无名 .bin现象7-Zip 能列出文件树但名称全是[0]、[1]这种序号或者 pefile 导出的全是rcdata_101_1033.bin双击都打不开。原因资源条目本身就没有名字只有数字 ID安装包编译器在打包时也没写文件名。这是正常现象不是解包失败。解决按第 3.2 节的文件头表批量判型改后缀。写个小脚本遍历目录读前 4 字节查表命中就改名比一个个手工试快得多。整套流程跑完还剩一堆无法判型的说明是自定义二进制格式配置、许可证、加密数据这类要么靠程序自身读取要么就不是给外部用的别硬啃。4.3 innoextract 报版本不支持现象innoextract -l package.exe直接报not a supported Inno Setup installer或提示版本过旧。原因安装包用较新的 Inno Setup 大版本编译手上的 innoextract 版本偏低不认新的数据结构。解决升级 innoextract 到最新版再试多数情况一次解决。升级后仍不认的说明该安装包用了自定义脚本或额外加密属于工具链边界。这种时候回到 7-Zip 试一次——7-Zip 对 Inno 的支持是另一套实现偶尔能互补。4.4 MSI 管理安装后目录里没有想要的文件现象msiexec /a执行完目标目录里只有几个 .cab 和一份 .msi 副本没有实际文件。原因管理安装只做“布局展开”不做“解压缩”。真正的文件还在 CAB 里。解决按第 3.3 节再解一次 CAB。判断解哪个的技巧用7z l逐个看 CAB 里的文件列表找包含目标文件名的那一个。如果 CAB 数量很多先按体积从大到小试大体积的通常装的是主程序。4.5 提取出来的 EXE 报 0xc000007b现象文件确实抠出来了双击立刻报“应用程序无法正常启动 (0xc000007b)”。原因这个错误码基本等于“位数或依赖不匹配”。三种常见情况32 位程序缺 32 位运行库、64 位程序混进了 32 位 DLL、依赖的某个 DLL 根本没被提取出来。解决先确认位数。用 pefile 读OPTIONAL_HEADER.Magic0x10B是 32 位0x20B是 64 位。再用DIRECTORY_ENTRY_IMPORT把所有依赖 DLL 名列出来逐个检查是否在同目录或系统目录存在import pefile pe pefile.PE(extracted.exe) for entry in pe.DIRECTORY_ENTRY_IMPORT: print(entry.dll.decode())缺哪个补哪个。安装包解出来的程序经常依赖同批次的运行库文件这时候回安装包里把对应的运行库目录整块解出来比到处找单文件靠谱。4.6 提取物被安全软件直接隔离现象解包刚完成目标目录里的某个 .exe 或 .dll 消失了安全软件弹窗提示已隔离。原因两种。一是真有问题——原安装包里确实带了不该带的东西二是特征码误报加壳程序、自解压模块、某些打包器的引导代码都容易被判为可疑。解决先看隔离记录里的具体判定名称再决定下一步。如果判定为通用的“可疑打包程序”类且文件来源可查、你有明确授权可以在隔离区恢复并加排除;如果判定指向具体的恶意行为特征直接放弃别为了一个资源文件去关防护。这条线没有折中方案。5. 完整性校验与边界解完之后怎么确认没漏解包最怕的不是解不出来是解出来了但少东西——少一个 DLL程序能启动但某个功能静默失败少一个配置文件跑起来用默认参数结果和文档对不上。所以每次提取完成我都会做一轮校验成本很低能省掉后面大量排查时间。5.1 哈希、文件清单与目录结构比对校验的第一步是建立清单。如果安装包能被 7-Zip 或 innoextract 列出工具输出的文件列表就是天然基准把它存成文本和解包后的实际目录做 diff# 生成基准清单以 innoextract 为例 innoextract -l package.exe | awk {print $NF} | sort expected.txt # 生成实际清单 find ./out_inno -type f -printf %P\n | sort actual.txt # 比对 diff expected.txt actual.txtawk {print $NF}取每行最后一个字段对 innoextract 的输出格式基本适用不同工具输出列数不同跑之前先看一眼原始输出再调整。diff 有差异不一定代表失败——解包器可能重命名了文件、跳过了目录条目但要逐条确认差异原因不能直接忽略。第二步是哈希。对关键的可执行文件算一次 SHA-256记下来。如果同一份资源在多个版本里重复出现哈希一致就是最强的“没损坏”证据sha256sum ./out_inno/app/main.dll ./out_inno/app/helper.dll提示不要拿解包结果的哈希去和网上的“官方校验值”比对来证明来源合法来源合法性靠授权链判断哈希只能证明内容没变。这两件事经常被混为一谈。5.2 依赖链与运行时缺失的定位文件齐了不代表能跑。PE 的依赖分两层静态导入导入表里写死的 DLL和延迟加载/动态加载运行时才LoadLibrary。前者能靠 pefile 全部列出来后者只能靠实际运行观察。静态依赖的处理方式在 4.5 节已经写过。这里补一个批量检查的思路把解出来的所有 PE 文件跑一遍导入表扫描收集全部依赖名和实际目录里的文件名求差集差集就是缺的。动态加载的缺失表现更隐蔽程序正常启动、界面正常但点某个功能按钮没反应或者日志里出现找不到模块的记录。这类问题只能靠运行时观察——用进程监视工具看它尝试加载了哪些路径或者打开程序自带的日志。我一般会先跑一遍主流程把每个功能点都点一次确认没有静默失败再交付。5.3 三条不该越过的线技术上能做的事和该做的事中间有条线。这条线在这个领域尤其清楚。第一条只处理你有权处理的文件。自己买的软件、自己的项目产物、明确授权分发的安装包随便拆。来源不明的安装包拆开看结构可以但不要拿来运行、不要分发里面的内容。授权状态是要在动手前确认的不是拆完再补。第二条不做授权绕过。提取资源和绕过授权是两件不同的事中间隔着修改校验逻辑、伪造许可证、patch 验证跳转。这些不在“解压”范畴内也不会在正常的技术讨论里出现。遇到需要这类操作的场景正确做法是回到授权渠道而不是找工具。第三条不传播提取物。从安装包里抠出来的 DLL、资源、配置版权归属不会因为被抠出来就发生变化。自己用、自己调试没问题往外发就是另一回事了。这条线很多人在无意中越过——写教程时把提取物一起打包分享是最常见的失误。守住这三条剩下的技术细节都可以放心折腾。6. 把它做成流水线批量识别脚本与一个自检习惯单个文件处理完真正省时间的是把判型这一步批量化。手上有一批安装包要提取资源时一个个手工看节表太慢我一般写个脚本先跑一遍分类输出一张表再按类型分组处理。import os import pefile SIGS { bNullsoftInst: nsis, bInno Setup Setup Data: inno, bMSCF: cab-inside, } def classify(path): with open(path, rb) as f: head f.read(2) if head ! bMZ: # 不是 PE可能是 MSI return msi-or-other if head b\xd0\xcf else unknown pe pefile.PE(path, fast_loadTrue) names [s.Name.rstrip(b\x00).decode(utf-8, replace) for s in pe.sections] avg_entropy sum(s.get_entropy() * s.SizeOfRawData for s in pe.sections) / max( sum(s.SizeOfRawData for s in pe.sections), 1) with open(path, rb) as f: blob f.read() for sig, kind in SIGS.items(): if sig in blob: return f{kind} (entropy{avg_entropy:.2f}) if avg_entropy 7.2: return fpacked? (entropy{avg_entropy:.2f}, sections{names}) return fplain-pe (entropy{avg_entropy:.2f}) for name in sorted(os.listdir(.)): if name.lower().endswith((.exe, .msi)): try: print(f{name:40} {classify(name)}) except Exception as e: print(f{name:40} error: {e})这段脚本的价值不在分类多准而在于把“打开文件、读节表、算熵、搜签名”这四个动作压缩成一行输出一百个文件几秒钟跑完人只需要看那张表。熵值加权平均的算法要注意分母是总原始大小不是节数量否则小体积的壳节会把平均值拉偏。实际用下来分类结果会分成三堆明确可解的nsis、inno、cab、sfx、需要人工判断的熵值 6.5 到 7.2 之间、签名没命中的、以及明确不该碰的熵值 7.5 以上且导入表稀疏。第三堆直接跳过别浪费时间第一堆批处理中间那堆才值得逐个人工看。这个二八分法能省掉大部分无效操作。最后说一个习惯是被坑出来的。早期我解包完就直接用直到有一次少了一个语言资源文件程序界面显示正常但导出报表时中文全变成方块排查了两天才定位到是资源缺失。从那以后我每次解包完成都会强制走一遍“清单 diff 关键文件哈希 主流程点一遍”三件套哪怕文件只有三个也照走。这套动作五分钟换的是不用回头重来。希望帮到你。本文还有配套的精品资源点击获取