简介这是一款面向逆向工程初学者与安全分析人员的自动查壳脱壳工具可检测程序的编译器信息、是否加壳、入口点地址、输出表与输入表等PE结构信息并支持提取PE文件中的图片、EXE、压缩包、MSI、SWF等资源同时能识别bmp、jpg、mp4、7z、rar、tar、vhd等大量文件格式还提供脱壳方法引导帮助使用者快速判断加密程序所采用的保护方式并加以学习利用。资源包共180个文件以75个dll动态库、27个eis、19个jpg、14个lng语言文件、8个txt说明及5个exe主程序为主另含bpl、ini、cfg、dpr、bat、asm、c、h等源码与配置类文件压缩包约13.1MB目录结构完整便于直接运行与二次研究。目前已有120人学习下载适合需要掌握查壳、脱壳与PE资源提取流程的开发者参考使用。1. 自动查壳脱壳工具到底在查什么从一个 PE 文件说起拿到一个来路不明的可执行文件很多人第一反应是双击运行而我的习惯是先把它拖进查壳工具里看一眼。自动查壳脱壳工具要解决的核心问题很朴素这个 PE 文件是谁编译的、有没有被加壳、入口点地址指向哪里、导入表和导出表长什么样。把这几个问题搞清楚后面无论是做兼容性排查、恶意样本分析还是研究程序保护机制心里都有底。标题里提到的编译器信息、加壳、入口点地址、PE 信息其实是一条链上的四个环节——编译器决定节区布局加壳会改写入口点和节区导入导出表则暴露程序依赖了哪些系统能力。这篇笔记就按这条链把查壳脱壳工具从原理到落地讲透适合做逆向分析、安全研究或者单纯想搞懂 PE 结构的开发人员跟做。2. PE 结构速览查壳工具到底在读哪些字段2.1 DOS 头、NT 头与节表三个必须定位的锚点PE 文件本质是一个有固定偏移约定的二进制结构。查壳工具第一步永远是定位 DOS 头偏移 0x3C 处有一个 e_lfanew 字段它指向真正的 NT 头。NT 头里的 FileHeader 给出节区数量和可选头大小OptionalHeader 则包含 AddressOfEntryPoint、ImageBase、SectionAlignment 这些关键值。入口点地址就是 AddressOfEntryPoint 加上 ImageBase 得到的虚拟地址加壳程序最典型的动作就是把这个值改到自己的解压代码上。节表紧跟在可选头之后每个节区 40 字节记录名称、虚拟大小、虚拟地址、原始大小、原始偏移和节区属性。正常编译器生成的节区名是 .text、.data、.rdata、.rsrc 这类而加壳工具往往生成 UPX0、UPX1、.aspack、.themida 这种带明显特征的名称。查壳工具判断加壳很大一部分工作就是比对节区名和节区属性。import struct def parse_pe_basics(path): with open(path, rb) as f: data f.read() # DOS 头偏移 0x3C 处是 e_lfanew e_lfanew struct.unpack_from(I, data, 0x3C)[0] assert data[e_lfanew:e_lfanew4] bPE\x00\x00, 不是有效 PE 文件 coff_off e_lfanew 4 machine, num_sections struct.unpack_from(HH, data, coff_off) opt_size struct.unpack_from(H, data, coff_off 16)[0] opt_off coff_off 20 magic struct.unpack_from(H, data, opt_off)[0] # PE32 入口点偏移 16PE32 入口点偏移 16 同样适用 entry struct.unpack_from(I, data, opt_off 16)[0] image_base struct.unpack_from(I, data, opt_off 28)[0] print(f节区数{num_sections} 入口点RVA0x{entry:x} ImageBase0x{image_base:x}) return data, opt_off, opt_size, num_sections parse_pe_basics(sample.exe)这段代码做了三件事校验 PE 签名、读出节区数量和可选头大小、计算入口点 RVA 与 ImageBase。参数上要注意 magic 字段0x10b 是 PE320x20b 是 PE32两者 OptionalHeader 里 ImageBase 的偏移不同PE32 是 8 字节。很多新手写的解析脚本在 64 位程序上读出错误的 ImageBase就是因为没区分这两种格式。2.2 导入表与导出表判断程序能力的两张清单导入表记录程序运行时需要从哪些 DLL 加载哪些函数。查壳工具读导入表一是看依赖了哪些系统库二是看导入函数的数量。加壳程序通常只保留 LoadLibrary 和 GetProcAddress 两个导入其余函数在运行时动态解析这是判断加壳的重要信号。导出表则出现在 DLL 里记录这个模块对外提供哪些函数分析系统组件时导出表是入口。导入表的结构是 IMAGE_IMPORT_DESCRIPTOR 数组每个描述符 20 字节指向一个 IMAGE_IMPORT_BY_NAME 数组。解析时要顺着 OriginalFirstThunk 和 FirstThunk 两个字段走前者指向名称表后者指向地址表。加壳程序经常把 OriginalFirstThunk 清零只留 FirstThunk这时候按常规方法读导入表会得到空结果需要结合节区属性判断。def parse_imports(data, opt_off, num_sections): # 数据目录表在可选头偏移 96PE32或 112PE32 magic struct.unpack_from(H, data, opt_off)[0] dd_off opt_off (96 if magic 0x10b else 112) import_rva, import_size struct.unpack_from(II, data, dd_off 8) if import_rva 0: print(导入表为空高度怀疑加壳) return # 这里需要先把 RVA 转成文件偏移实际项目里要遍历节表 print(f导入表 RVA0x{import_rva:x} 大小{import_size}) parse_imports(*parse_pe_basics(sample.exe)[1:])RVA 到文件偏移的转换是查壳工具里最容易翻车的地方。正确做法是遍历节表找到 VirtualAddress RVA VirtualAddress VirtualSize 的那个节区然后用 RVA - VirtualAddress PointerToRawData 得到文件偏移。如果 RVA 落在节区之外说明文件被篡改或者节区头被破坏这时候工具应该报错而不是硬算。2.3 编译器信息从 Rich Header 和链接器版本反推编译器信息不是 PE 规范里的正式字段而是从几个线索反推出来的。第一个线索是 Rich Header它位于 DOS 头之后、NT 头之前是微软链接器写入的一段加密数据解密后能看到工具集版本和构建次数。第二个线索是 OptionalHeader 里的 MajorLinkerVersion 和 MinorLinkerVersion比如 14.0 对应 VS201514.2 对应 VS2019。第三个线索是节区名和节区对齐方式MinGW 生成的节区名和 MSVC 有明显差异。查壳工具报出编译器信息对分析很有价值。比如一个样本声称是某正规软件但编译器信息显示是 MinGW 且链接器版本很老这就值得警惕。Rich Header 的解析需要先找到 DanS 标记然后用异或密钥解密后续数据密钥就是 DanS 后面那个 DWORD 与 0x536e6144 的异或结果。3. 加壳识别从节区特征到熵值分析的落地方法3.1 节区名与节区属性第一层快速筛选加壳识别最直接的方法是看节区名。UPX 加壳后节区名是 UPX0、UPX1ASPack 是 .aspack 和 .adataThemida 是 .themidaVMProtect 是 .vmp0 和 .vmp1。这些特征字符串直接写在节表里用十六进制编辑器就能看到。但现代加壳工具支持自定义节区名所以节区名只能作为第一层筛选不能作为唯一依据。节区属性是第二层线索。正常 .text 节区的属性是 0x60000020即可执行、可读、包含代码。加壳后的节区经常出现可写且可执行的属性比如 0xE0000020因为解压代码需要在运行时修改自身。如果一个 PE 文件里存在同时可写和可执行的节区加壳的概率非常高。def check_section_anomalies(data, opt_off, num_sections): magic struct.unpack_from(H, data, opt_off)[0] sec_off opt_off (224 if magic 0x10b else 240) suspicious [] for i in range(num_sections): base sec_off i * 40 name data[base:base8].rstrip(b\x00).decode(errorsignore) vsize, vaddr, rsize, roff struct.unpack_from(IIII, data, base 8) chars struct.unpack_from(I, data, base 36)[0] writable bool(chars 0x80000000) executable bool(chars 0x20000000) if writable and executable: suspicious.append((name, hex(chars))) print(f{name:10s} VA0x{vaddr:x} VSize0x{vsize:x} RawSize0x{rsize:x} Chars0x{chars:x}) return suspicious print(check_section_anomalies(*parse_pe_basics(sample.exe)[1:]))这段代码遍历节表打印每个节区的虚拟地址、虚拟大小、原始大小和属性并标记同时可写可执行的节区。参数上要注意节表起始偏移PE32 是可选头偏移加 224PE32 是加 240这个差异来自 OptionalHeader 本身的大小不同。如果打印出的节区虚拟大小远大于原始大小比如 VSize 是 0x10000 而 RawSize 只有 0x200说明这个节区在运行时会被解压填充是加壳的强信号。3.2 熵值计算量化判断代码是否被压缩熵值分析是加壳识别的量化手段。未压缩的代码和数据熵值通常在 5.0 到 6.5 之间压缩或加密后的数据熵值接近 7.9。计算方法是把节区原始数据按字节统计频率然后套用香农熵公式。查壳工具通常会对每个节区单独算熵如果某个节区的熵值超过 7.0 且属性可执行基本可以判定被加壳。import math from collections import Counter def section_entropy(data, offset, size): chunk data[offset:offsetsize] if not chunk: return 0.0 counter Counter(chunk) length len(chunk) entropy -sum((c/length) * math.log2(c/length) for c in counter.values()) return entropy def scan_entropy(data, opt_off, num_sections): magic struct.unpack_from(H, data, opt_off)[0] sec_off opt_off (224 if magic 0x10b else 240) for i in range(num_sections): base sec_off i * 40 name data[base:base8].rstrip(b\x00).decode(errorsignore) rsize, roff struct.unpack_from(II, data, base 16) ent section_entropy(data, roff, rsize) flag -- 疑似压缩/加密 if ent 7.0 else print(f{name:10s} 熵值{ent:.3f}{flag}) scan_entropy(*parse_pe_basics(sample.exe)[1:])熵值计算要注意两个边界一是原始大小为零的节区直接跳过否则除零二是数据量太小的节区熵值波动大一般少于 512 字节的节区不参与判断。实际工具里还会结合节区之间的熵值分布如果只有一两个节区高熵而其他正常可能是资源压缩而非整体加壳。3.3 入口点特征判断壳的类型和版本入口点地址指向的代码是壳的解压 stub。不同壳的 stub 有不同特征比如 UPX 的入口点通常在一个高熵节区的开头前几条指令是 pushad 和 mov esi 之类的固定模式。查壳工具会把入口点处的字节序列和已知壳的特征库比对从而报出壳名和版本。入口点分析还有一个实用技巧看入口点落在哪个节区。正常程序的入口点在 .text 节区加壳程序的入口点往往在最后一个节区或者一个名字异常的节区。如果入口点 RVA 超出了所有节区的虚拟地址范围说明节表被破坏文件可能被手工修改过。4. 脱壳路径从自动识别到手工 dump 的完整流程4.1 自动脱壳的适用边界与失败信号自动脱壳工具的原理是模拟运行目标程序等壳的解压 stub 执行完毕、原始代码写入内存后把内存镜像 dump 下来并修复导入表。这条路对 UPX、ASPack 这类老壳非常有效一条命令就能脱干净。但对 VMProtect、Themida 这类带虚拟化保护的壳自动脱壳基本无效因为原始代码从未以完整形式出现在内存里。判断自动脱壳是否成功看三个信号dump 出来的文件入口点是否落在正常节区、导入表是否完整、文件能否在隔离环境里正常加载。如果 dump 后入口点还在高熵节区说明壳没跑完就 dump 了如果导入表只有 LoadLibrary 和 GetProcAddress说明导入表没修复。# 以 UPX 为例先查壳再脱壳 upx -l sample.exe # 列出壳信息确认是 UPX upx -d sample.exe -o unpacked.exe # 脱壳输出到新文件 python parse_pe_basics.py unpacked.exe # 复查入口点和节区UPX 的命令行参数里-d 是解压-o 指定输出文件-l 是列出信息。脱壳后一定要复查入口点正常 UPX 脱壳后入口点会回到 .text 节区节区名恢复成编译器默认值。如果脱壳后文件反而变大说明原始文件里可能有覆盖数据需要检查 overlay。4.2 手工 dump 的关键步骤找 OEP 与修复导入表手工脱壳的核心是找到 OEP即原始入口点。常用方法是利用调试器的内存断点在壳的入口点下断运行后对代码段下内存访问断点当执行流跳到原始代码段时断下当前位置就是 OEP。找到 OEP 后用 dump 插件把进程内存导出成文件再用导入表修复工具重建导入表。找 OEP 有几个经验点一是壳的 stub 通常以 pushad 开头、popad 结尾popad 之后不远处往往就是跳向 OEP 的 jmp二是可以在栈上对 ESP 下硬件断点pushad 会把寄存器压栈popad 恢复时断下顺着单步就能到 OEP三是注意异常处理有些壳故意触发异常来混淆执行流调试器要配置成忽略这些异常。# 用 pefile 检查 dump 后文件的导入表是否完整 import pefile pe pefile.PE(dumped.exe) if hasattr(pe, DIRECTORY_ENTRY_IMPORT): for entry in pe.DIRECTORY_ENTRY_IMPORT: dll entry.dll.decode() funcs [imp.name.decode() if imp.name else ford({imp.ordinal}) for imp in entry.imports] print(f{dll}: {len(funcs)} 个函数) else: print(导入表为空需要手工修复)pefile 是解析 PE 的常用库DIRECTORY_ENTRY_IMPORT 属性存在说明导入表可读。如果导入表为空需要用 Scylla 这类工具手工指定 IAT 的起始地址和大小重建导入描述符。修复导入表时要注意区分绑定导入和延迟导入前者在文件里就有地址后者需要运行时解析。4.3 脱壳后的验证三重检查避免拿到半成品脱壳不是 dump 完就结束必须做三重验证。第一重是结构验证用查壳工具重新扫一遍确认没有残留的壳特征、入口点正常、节区属性合理。第二重是功能验证在隔离环境里运行脱壳后的程序看主要功能是否正常。第三重是静态验证用反汇编器加载脱壳文件看代码段是否能正常反汇编出有意义的指令序列。三重验证里最容易忽略的是第三重。有些壳脱完后文件能运行但代码段里混有壳的残留数据反汇编出来一堆无意义指令。这时候需要检查节区的原始大小和虚拟大小是否匹配如果虚拟大小远大于原始大小说明还有未解压的区域。5. 避坑与排查查壳脱壳里最容易翻车的五个点5.1 现象工具报「不是有效 PE 文件」但文件确实能运行原因通常有三种文件被加了非标准壳导致 PE 头被搬移、文件是 DOS 扩展格式、或者文件被截断。有些壳会把原始 PE 头加密后放到文件末尾运行时再解密还原静态解析自然失败。解决方法是先用十六进制编辑器确认 MZ 和 PE 签名是否存在如果 MZ 存在但 PE 签名找不到尝试在文件里搜索 PE\0\0 字节序列找到后手动修正 e_lfanew。5.2 现象导入表解析出来全是乱码函数名原因是 RVA 到文件偏移的转换算错了或者导入表的 OriginalFirstThunk 被壳清零。先检查节表遍历逻辑确认 RVA 落在正确的节区里。如果 OriginalFirstThunk 为零改用 FirstThunk 解析但要注意 FirstThunk 在文件里存的是 RVA 还是已解析的地址加壳文件里通常是 RVA未加壳文件里可能是地址。解决方法是两个字段都试一遍取能解析出可读字符串的那个。5.3 现象熵值计算出来所有节区都接近 8.0原因是把整个文件当成一个节区算了或者节区的原始偏移和大小读错了。熵值必须按节区单独算且要用原始数据而不是虚拟数据。检查节表解析时 PointerToRawData 和 SizeOfRawData 是否读对了偏移PE32 里这两个字段在节区基址加 20 和加 16 的位置。如果整个文件熵值都高可能是文件本身是压缩包或者加密容器不是 PE 加壳。5.4 现象自动脱壳后程序运行崩溃原因是导入表没修复完整或者 dump 时机太早、壳还没解压完。先确认 dump 时壳的 stub 是否执行完毕可以在 OEP 处下断确认。导入表修复时注意区分大小写Windows 加载器对 DLL 名大小写不敏感但有些修复工具会写错。另外检查重定位表如果脱壳后文件加载基址和原始基址不同重定位表缺失会导致绝对地址引用失效。5.5 现象查壳工具报的编译器信息和实际不符原因是 Rich Header 被壳修改或清除工具回退到链接器版本字段而链接器版本可以被伪造。Rich Header 的校验方法是解密后看工具集 ID 是否在合理范围内如果解出来是乱码说明被改过。这时候不要迷信工具报的编译器信息结合节区名、导入表特征和代码风格综合判断。我一般会同时用两三个工具交叉验证单一工具的结论只作参考。6. 把查壳能力接进自己的分析流水线6.1 批量扫描与结果结构化单个文件查壳用现成工具就够了但做样本分析往往要处理成百上千个文件这时候需要把查壳逻辑做成可批量调用的脚本。核心思路是把前面几节的解析函数串起来对每个文件输出一行结构化结果文件路径、是否 PE、编译器猜测、是否加壳、壳名、入口点 RVA、节区数量、最高熵值。输出成 CSV 或 JSON方便后续筛选和统计。import csv, os def batch_scan(folder, out_csv): rows [] for name in os.listdir(folder): path os.path.join(folder, name) if not os.path.isfile(path): continue try: data, opt_off, opt_size, num_sec parse_pe_basics(path) magic struct.unpack_from(H, data, opt_off)[0] entry struct.unpack_from(I, data, opt_off 16)[0] rows.append({file: name, sections: num_sec, entry: hex(entry), magic: hex(magic)}) except Exception as e: rows.append({file: name, error: str(e)}) with open(out_csv, w, newline) as f: writer csv.DictWriter(f, fieldnames[file, sections, entry, magic, error]) writer.writeheader() writer.writerows(rows) batch_scan(./samples, scan_result.csv)批量扫描要注意异常处理单个文件解析失败不能中断整个批次。参数上建议把每个文件的解析结果独立成行方便用表格工具排序筛选。如果样本量大可以加多进程但要注意文件 IO 的并发限制。6.2 特征库的维护与更新查壳工具的准确率取决于特征库。节区名特征、入口点字节特征、Rich Header 工具集 ID 映射表这三类数据需要持续维护。我的习惯是每遇到一个新壳就手动分析一遍把节区名规律和入口点前 32 字节的特征记下来追加到特征库文件里。特征匹配时按优先级排序先匹配入口点字节特征再匹配节区名最后看熵值和属性组合。特征类型匹配字段误报风险维护频率入口点字节序列入口点前 32 字节低遇到新壳时节区名节表名称字段中每月复查节区属性组合Characteristics中高每季度复查熵值阈值节区熵值高按样本调参Rich Header解密后工具集 ID低跟随 VS 版本特征库维护的难点是平衡召回率和误报率。入口点字节特征最可靠但覆盖窄熵值特征覆盖宽但容易把资源压缩误判成加壳。实际使用中我会把多个特征做成加权评分总分超过阈值才报加壳这样比单一特征判断稳得多。6.3 一个我常犯的错误早期做批量扫描时我图省事直接把整个文件读进内存算熵结果遇到一个 2GB 的样本直接把内存吃满脚本崩了。后来改成按节区流式读取每次只读一个节区的原始数据内存占用立刻降下来。另一个教训是 RVA 转换函数没做边界检查遇到节区头被破坏的样本时算出的文件偏移越界读出一堆垃圾数据还以为是壳的特征。现在我的习惯是每个解析函数入口先做长度校验任何越界访问直接抛异常并记录文件名宁可漏报也不误报。查壳这件事工具报什么不重要重要的是你知道它为什么这么报以及什么时候不该信它。希望帮到你。本文还有配套的精品资源点击获取