简介自动查壳脱壳工具exeinfope是一款面向开发人员与逆向分析者的PE分析实用工具可快速查看编译器信息、入口点、输入表/输出表等结构判断是否加壳并给出脱壳引导还能提取图片、EXE、压缩包、MSI、SWF等资源并对bmp、jpg、mov、mp4、7z、rar、CRX、vhd、tar等多种格式进行识别。压缩包共180个文件以DLL动态库、EIS数据、JPG图片、LNG语言文件、TXT说明文档、EXE主程序、BPL运行组件、INI/CFG配置文件为主DLL和BPL支撑软件运行LNG提供多语言界面TXT为使用说明ZIP内多为示例或附加工具。另有asm、bas、c、h、dpr等源代码和compile.bat批处理脚本整体约13.1MB目录结构清晰。目前已有120人学习下载适合入门或中级用户作为查壳、脱壳、资源提取和格式识别的辅助工具。附带的PEiD插件相关源码如masm_plugin.asm、PEiD_Plugin.bas和vcl70.bpl、rtl70.bpl运行库可帮助理解插件机制、定制脱壳功能而TXT文档和示例ZIP也提供了参考案例。1. 自动查壳脱壳不是一键破解而是先把 PE 文件“验明正身”开发人员拿到一个来路不明的 exe 时第一反应一般是它加壳了吗用什么编译器生成的入口点地址在哪里这类问题催生了“自动查壳脱壳工具”它通过解析 PE 文件的结构把编译器信息、是否加壳、入口点地址EP、输出表、输入表一次性列出来。对我来说工具不是用来“一键破解”的而是给后续分析一个可靠的起点——决定我是直接看反汇编还是先脱壳再还原逻辑。不管是做恶意代码分析、老项目维护还是验证自己写的程序在加壳后的强度第一步都是把 PE 文件的身份搞清楚。自动查壳工具做得好的能在几毫秒内给出壳名做得不够好的也能把原始 PE 头数据摊开让你自己判断。这篇笔记按“原理 → 实操 → 避坑 → 接入流程”的顺序把整套做法讲透。适合刚接触逆向的开发者也适合已经用 DIE 但遇到误报和脱壳失败的分析人员。2. 查壳工具的工作原理入口点、导入表与编译器指纹2.1 入口点地址EP加壳后为什么总是跳到一段陌生的解压代码每个 PE 文件的可选头OPTIONAL_HEADER里都有一个 AddressOfEntryPoint 字段表示程序入口在内存映射中的 RVA。正常程序入口通常是编译器生成的启动代码VC 的入口在 .text 区段最典型的字节序列是一条 call 或 jmp 到 CRT 初始化函数前面还有各编译器固定的前缀比如先做 GS 安全检查。壳为了让自己的代码先跑会把 EP 改成指向自己新增的区段例如 UPX 的 UPX1、ASProtect 的 .aspack这些区段往往同时具备“可读可写可执行”权限。查壳工具判断“有没有壳”的第一条规则就是看 EP 落在哪个区段。如果 EP 落在 .text 上且区段权限与链接器默认值一致那就倾向于无壳如果 EP 落在 UPX0 或 .vmp0 这类名字异常的区段或者区段的 VirtualSize 明显大于 SizeOfRawData压缩壳常见真实数据在文件中很小运行时展开得很大就会直接给出加壳提示。这也就是为什么工具输出的“EntryPoint”和“EP Section”两个字段要连着看单独一个 EP 地址没有意义结合区段特征才能下结论。有些壳还会做“Fake EP”文件头里写的 AddressOfEntryPoint 指向一个和解压代码很像的伪装块真正入口靠壳代码运行时跳过去。这时只看 EP 会被骗所以工具还要看导入表和代码熵。2.2 输出表和输入表壳把“正常导入”藏到哪去了输出表和输入表是 PE 里最容易“露馅”的两个数据目录。一个正常用 C/C 写的窗口程序输入表会列出 user32.dll、kernel32.dll、gdi32.dll 以及大量具名函数输出表则只在 DLL 或插件程序里出现。加壳后情况完全翻转原始输入表被压缩或加密壳代码在运行时只依赖两个 API——LoadLibraryA 和 GetProcAddress——来动态解析所有后续函数。因此工具解析完导入表后如果发现“导入的 DLL 数量1API 数量2”这种极端样式基本可以断定被壳处理过。输出表也一样。假如一个 DLL 含有导出函数 AddUser、DeleteUser加壳后这些导出地址会被加密查壳工具读输出表时要么只看到壳自己的导出要么看到一堆指向壳区段的无效地址。所以很多查壳工具会单独显示“Exports 数量”作为参考指标。我自己看结果时有个习惯先看导入表 DLL 列表是不是只剩 kernel32再看导出表指向的 RVA 是否落在壳区段两者都异常就进入脱壳流程只要有一个正常就得继续查。2.3 编译器信息从哪来Rich 头与链接器版本“编译器信息”这一栏很多人以为是工具猜的其实它是实打实读出来的只是有些信息藏在正史里有些藏在角落里。第一证据是 Rich Header它位于 DOS stub 之后、PE Header 之前是 MSVC 系列编译器留下的结构里面用一系列 32 位值记录编译器工具链的 ID、版本和使用次数。DIE 这类新工具会直接解析 Rich Header告诉你“Visual C 2019 x64”而不是含糊的“MSVC”。第二证据是可选头里的 MajorLinkerVersion 和 MinorLinkerVersion这一对字节记录了链接器版本比如 14.29 对应当前 VS2019 的链接器。但是注意壳完全可以修改链接器版本字段比如老壳为了兼容性会把版本改成 6.0所以链接器版本只能作为辅助。第三证据是入口代码的字节模式每个编译器的启动代码都有自己的习惯比如做堆栈校验、设置 SEH、调用 main。工具会把这些模式做一个“无壳”特征库匹配到了就报编译器名匹配不到再结合 Rich 头判断。这里有个常见的坑特征库比较旧的时候工具可能会把一个带签名的 .NET 程序报成“可疑壳”因为 .NET 的入口代码看起来不像 VC 也不像 MinGW。这时候你就得自己去看 Rich 头和 DLL 列表而不是迷信工具。2.4 区段名与熵值两个辅助但不仲裁的指标查壳工具还会给出区段名和熵值这两个字段容易看错要单独说。区段名诸如 UPX0、UPX1、.vmp0 只是字符串可以被壳作者随意改名。我见过把壳的区段改成 .text/.data 来伪装的文件所以区段名只能用来“提示”不能用来“定罪”。真正有判断力的是区段的尺寸比例UPX 这类压缩壳在磁盘上 SizeOfRawData 很小但运行时 VirtualSize 非常大因为解压后的数据要展开到内存。普通编译器生成的区段这两个数值基本接近。熵值Shannon entropy是另一个参考指标。一个加密或压缩过的区段字节分布接近随机熵值可以到 7.8 以上正常代码段因为有固定的指令模式熵值一般在 6 到 7 之间。但高熵不一定有壳因为很多安装包和资源段也会压缩低熵也不一定无壳因为有的壳为了性能不加密代码段。所以看到 DIE 提示“suspicious entropy”先别急着认定加壳把它当成“需要进一步检查”的信号就好。2.5 用一条 diec 命令把 UPX 壳“验”出来原理讲再多不如直接对一个已知样本动手。我这里用一个带 UPX 壳的小工具做示例。UPX 是开源的压缩壳特征非常标准适合第一个上手。diec samples/putty.exe -j -eep参数 -j 表示输出 JSON-eep 表示输出里带上 EntryPoint 和 EP Section 字段。运行后你会看到类似下面的关键字段{ packer: UPX(3.96)[NRV2B], entrypoint: 0040xxxx, ep_section: UPX1, imports_dll: [KERNEL32.dll] }看到 packer 字段直接给出 UPX且 ep_section 是 UPX1就可以确认这个文件被 UPX 加壳。这条命令的逻辑就是把 2.1 讲的“EP 落在壳区段”和 2.2 讲的“导入异常”组合成一条自动规则。如果你没有 DIE也可以用 Exeinfo PE 或 PEiD 的 GUI 打开检查“Packer”栏是否显示 UPX。这条命令的代价很小但它验证了一个重要流程自动查壳工具并不是一个黑匣子它只是把 PE 结构解析和特征匹配的结果展示给你。当特征库误报时你可以跳回 2.12.3 的三层证据自己仲裁。这也是我把它放在第 2 章最后的原因——先理解规则再相信结果。3. 用自动查壳工具做一次完整 PE 体检命令、输出与批量报告3.1 diec 命令行查壳-p/-j/-eep 的参数怎么选DIEDetect It Easy是当前从业者用得最多的自动查壳工具之一带 GUI 和命令行 diec。单文件要快速看结果直接用diec target.exe纯文本输出会依次显示 Compiler、Packer、Linker 等字段信息够用但太简洁。想要在脚本里解析用 JSON 模式更稳diec target.exe -j -eep -r这一条是“完整体检”常用的组合-j 输出 JSON-eep 强制加入 EntryPoint 和 EP Section-r 表示递归扫描嵌套的 PE 段。JSON 输出的好处是字段结构固定后续用 Python 或 jq 处理都不容易翻车。如果同时要留给审计存档还可以加 -p 把纯文本也落一份。参数选择只有一个原则人工看用 -p程序读用 -j。EEP 字段必须在查壳时打开否则输出里没有入口点地址很多后续判断无从谈起。GUI 模式和命令行读取的是同一套特征库所以不要担心命令行结果与界面不一致。3.2 批量扫描目录把查壳结果变成 CSV 报告日常分析很少只有一个样本更多时候面对的是一个目录下的几十个 exe/dll。这时用 Python 调 diec 批量跑把结果整理成 CSV 是最省事的方式。import subprocess, csv, pathlib root pathlib.Path(samples) rows [] for f in root.rglob(*): if f.suffix.lower() not in (.exe, .dll): continue try: out subprocess.check_output( [diec, str(f), -p, -eep], stderrsubprocess.DEVNULL, timeout10 ).decode(utf-8, errorsignore) except Exception as exc: rows.append({file: str(f), error: str(exc)}) continue info {file: str(f)} for line in out.splitlines(): for key in (Compiler, Packer, EntryPoint, EP Section): if line.startswith(key :): info[key] line.split(:, 1)[1].strip() break rows.append(info) with open(scan_report.csv, w, newline, encodingutf-8) as fp: writer csv.DictWriter(fp, fieldnames[file, Compiler, Packer, EntryPoint, EP Section, error]) writer.writeheader() writer.writerows(rows)这个脚本用 pathlib 递归收集样本把每个文件的 diec 纯文本输出按冒号拆成结构化字段。需要注意三点一是 subprocess 要加 timeout防止个别大文件卡住二是 DIE 对资源损坏的文件可能直接返回非 0所以异常要捕获并写入 error 列三是 diec 的字段名可能与版本不同运行时先用单文件打印一次输出再微调 key。生成 CSV 之后用 Excel 或者 grep 过滤 Packer 列就能快速定位哪几个文件需要脱壳。这一步省掉了一个一个开 GUI 的时间也是“自动查壳”在团队协作里最被认可的价值之一。3.3 用 dumpbin 核对输入输出表和入口点查壳工具给结论dumpbin 给证据。Windows SDK 自带的 dumpbin 是核对 PE 头最权威的参照之一尤其看输入表和入口点。dumpbin /headers samples/target.exe dumpbin /imports samples/target.exe dumpbin /exports samples/target.exe/headers 输出里的 Optional Header 字段会直接给出 AddressOfEntryPoint 和 ImageBase这个入口点数值是可以和 DIE 的输出对照的。如果两者对不上原因通常是 DIE 显示的是加载后的入口地址而 dumpbin 显示的是文件里的 RVA数值差一个 ImageBase。/imports 的输出值得逐行看正常程序会有很多 DLL 和函数名而加壳程序的导入区通常只有 KERNEL32.dll 的 LoadLibraryA 和 GetProcAddress。/exports 同理导出函数列表如果比文档少一大截说明导出表可能被壳压缩。我一般把 dumpbin 的输出存成一个文本文件和 DIE 的 JSON 放同目录。这样后面无论是写报告还是做二次分析都有原始证据。这也解决了“工具说有壳但我不信”的争论——拿 /imports 给同事看一眼比扯半天特征库靠谱得多。4. 脱壳实操UPX 一键脱掉之后手动修复 IAT 才是分水岭4.1 UPX一条命令脱干净但有前置条件UPX 是少数支持“自动脱壳”的压缩壳因为它的解压缩算法是公开且标准化的。查壳确认是 UPX 后直接cp samples/target.exe work/target.exe upx -d work/target.exe -o work/unpacked.exe先复制一份再操作是习惯因为 upx -d 默认会在原文件上改写而带壳原样本要留作对比。参数 -d 表示 decompress-o 指定输出文件。整个过程很快UPX 会读取文件尾部的保护信息恢复原始 PE 头、区段表和入口点。如果命令报 “NotPackedException”说明文件虽然自称 UPX但结构不完整或者作者修改过 UPX 的默认参数。可以先试upx -d --force因为 UPX 对部分修改过的文件也能解再不行就放弃自动脱走 4.3 的手动流程。验证脱壳结果用两条命令upx -t work/unpacked.exe diec work/unpacked.exe -pupx -t 用于完整性测试DIE 如果不再显示 Packer 字段说明壳的特征已经消失。这里有个容易忽略的细节upx -d 成功的前提是文件必须是标准 UPX 壳如果作者用 UPX 加壳后又把文件尾部的 UPX 标志改了自动脱壳就失效。所以看到 UPX 识别结果后不要急着高兴先跑 upx -t 确认。4.2 自动脱壳的边界压缩壳可以虚拟化壳只能识别不能还原“自动查壳脱壳工具”里的“自动脱壳”四个字能覆盖的壳比很多人想象中窄得多。常见能自动处理的壳是压缩壳UPX、ASPack、FSG、NSPack 这些原理是运行时解压原始代码壳代码不改变原始机器码。处理方式是找到解压入口dump 内存再修复一下头就能拿回接近原始的程序。加密壳和虚拟化壳完全是另一回事。ASProtect、Enigma 这类加密壳会对原始代码分段解密VMProtect、Themida 更是把原始指令转换成自定义字节码交给壳内置的虚拟机解释执行。文件里根本没有完整的原始机器码副本所以无论你 dump 多少次内存得到的都是虚拟化后的中间代码。查壳工具能瞬间识别出 VMProtect但它做不到一键还原成你想要的汇编。自动脱壳工具面对这种壳唯一能做的就是告诉你“这是谁”剩下的工作要交给动态分析和人工逆向。提示选型时要先查工具官方维护的“已支持壳列表”如果列表里没有你目标壳别把时间花在调参数上。UPX 是入门VMProtect 是另一个技能树。4.3 手动脱壳最小路径x64dbg Scylla 修复 IAT当自动脱壳失败或者要处理压缩壳的变种常见做法是“内存 dump 重建 IAT”。我用 x64dbg 加 Scylla 走这条流程步骤如下。第一步x64dbg 加载带壳文件停在系统断点后按 F9 运行到入口。入口通常是壳自己的一段代码UPX 类壳开头一般是pushad用来保存寄存器现场。第二步在pushad后面一行对 ESP 下硬件访问断点。这个技巧叫 ESP 定律原理是pushad之后 ESP 指向保存寄存器数据的区域壳在解压结束准备跳回原 OEP 前会从这片区域恢复寄存器访问 ESP 指向的地址。断在popad附近后单步跟到后面的jmp指令执行过去就是原程序的入口。第三步记下原入口在文件中的 RVA。x64dbg 显示的地址是 ImageBase 加 RVA要手算减一下基址或者直接用 Scylla 自动计算。第四步Scylla 附加目标进程在 OEP 栏填 RVA点 “IAT Autosearch” 让它扫描输入表再点 “Get Imports” 拉出函数列表。正常情况能看到几十个 DLL 和几百个 API如果只看到 kernel32 的两个函数说明扫描范围不对。第五步点 Dump 保存内存镜像再点 Fix Dump 选择刚才的文件Scylla 会重建输入表并生成修复后的 exe。这个流程看起来简单实际每次翻车点都在 IAT 搜索范围。Scylla 自动搜索常会漏掉延迟导入或者把无关地址识别成 API。经验是手动把 IAT 的起始地址和大小扩到壳区段附近再重扫几遍。4.4 脱壳后验证重新查壳、运行和导入表三合一脱壳不算完验证脱壳结果才是真验收。我会用三条检查串起来。diec work/unpacked.exe -j -eep dumpbin /imports work/unpacked.exe work/unpacked.exe第一步看 DIE 是否还报 Packer第二步看导入表是不是从“只剩 LoadLibraryA”变成完整列表第三步直接运行。对 UPX 这类壳能正常弹出窗口且 DIE 无壳基本就过关了。如果文件是恶意样本第三步要在隔离虚拟机里做不要在工作机上直接点。验证时最容易出现的情况是脱壳后一运行就报错这往往不是脱壳步骤错了而是 IAT 没有修复完整或者重定位表被截断。遇到这种情况先回到 Scylla把 IAT 范围调大重新修复。宁可让修复后的文件变“胖”也不要让导入表带伤上阵。5. 查壳脱壳避坑指南误报、随机入口、IAT 崩坏与杀软拦截5.1 特征库太旧把编译器误报成壳现象DIE 把一个小巧的 VC 程序报成“ASProtect 2.x”或者把 .NET 自带的程序报成“SmartAssembly”。原因新版本编译器生成的入口代码与老特征库里某些壳的特征存在字节级别的重叠旧特征库又没有关闭这类误报。解决先升级到最新特征库再交叉验证。交叉验证的次序是DIE 的 Packer 字段 dumpbin /imports 区段名。如果 dumpbin 显示导入表完整且入口点在 .text那大概率是误报继续分析而不是急着脱壳。这个坑之所以常见是因为很多人把查壳工具的“Packer”字段当结论。记住查壳工具提供的只是“可能性”不是判决书。真正确认有壳至少要两个工具同时给出相近结论或者原始 PE 头部数据能自圆其说。5.2 入口点地址每次查都不一样ASLR 和 Fake EP现象同一个 exe 在两次查壳中显示的入口点地址不一样dumpbin 显示的 EntryPoint 是 00012345DIE 显示的却是 004012345。原因ASLR 让 ImageBase 随机化工具显示运行时加载地址时数值会随进程基址变化另外某些壳在文件头写 Fake EP导致工具读到的是伪装地址。解决以 dumpbin /headers 里的 AddressOfEntryPoint 为准它是文件内的 RVA不随系统加载地址变化。DIE 的 -eep 输出里应该同时有 EntryPoint 和 EP Section如果 EP Section 是 UPX1 或 .vmp0那就说明壳在文件层面生效。遇到 Fake EP 还得到具体反汇编里看跳转逻辑查壳工具只能给你一个起点。5.3 IAT 没修完整脱壳后能打开一点就崩现象脱壳后的 exe 能启动但一触发某个业务功能就报“无法定位程序输入点 X 于动态链接库 Y”或者直接内存访问冲突。原因dump 时壳还没有完成全部导入函数的中转或者 Scylla 扫描 IAT 的范围不够导致部分函数地址没有写入修复表。解决重新加载原壳样本在 OEP 处多等一会儿让壳把所有 DLL 都加载完再 dumpScylla 里把 IAT 范围扩大到整个可读区段去掉“仅扫描已执行代码”之类的限制。调试时在 GetProcAddress 返回处下断点记录每个解析函数能帮你确认哪些导入漏掉了。这是手动脱壳最容易翻车的地方也是“自动脱壳工具”在压缩壳上仍被需要的原因。能用 upx -d 解决的就别轻易尝试手修 IAT。5.4 安全软件把查壳脱壳工具当病毒处置现象UPX、DIE、Scylla 下载后刚落地就被删除脱壳生成的 unpacked.exe 一写出来就进了隔离区。原因这些工具要读取其他进程内存、修改 PE 文件、触发内存页的可执行权限行为特征与恶意软件高度重合安全软件的启发式引擎会优先拦截。解决在专用的脱壳虚拟机里做全部操作给工具目录和输出目录加白名单工具包从官方仓库获取并核对哈希值不要用下载站里的“破解版整合包”。脱壳产物也不要拷贝到生产机直接运行先在隔离环境里跑一轮行为观察。这条重要到会卡住整个项目进度。很多团队第一次引入自动查壳脱壳工具不是死在技术上而是死在 IT 安全策略上。提前申请好白名单能给后续省下大量扯皮时间。5.5 查壳结果与 dumpbin 对不上文件头可能被定向修改现象DIE 识别为无壳但程序有异常的反调试行为或者 dumpbin 显示的入口点指向一个长度异常的代码段。原因一部分定制壳会在文件头写标准编译器信息来欺骗查壳工具但运行时代码会自校验并跳转。解决不要只看文件级字段要看运行时实际入口。用 x64dbg 跑一下观察第一条执行的指令是否在文件头声明的代码段里。如果实际入口和文件头的 AddressOfEntryPoint 不一致说明壳做了“运行时改头”文件级查壳结果可信度要下调。6. 把自动查壳接进日常流程一个 PE 指标采集脚本与验证方法前面几章说的都是单次操作但工程上更需要一个能反复跑的基线。我习惯在查壳前先用脚本把 PE 原始指标记下来这样无论 DIE 怎么升级、特征库怎么变化原始头部数据不会说谎。import argparse, csv import pefile def scan_pe(path): pe pefile.PE(path) opt pe.OPTIONAL_HEADER ep opt.AddressOfEntryPoint linker f{opt.MajorLinkerVersion}.{opt.MinorLinkerVersion} ep_section if pe.sections: for s in pe.sections: rva s.VirtualAddress size max(s.Misc_VirtualSize, s.SizeOfRawData) if rva ep rva size: ep_section s.Name.decode(utf-8, errorsignore).rstrip(\x00) break imports [] if hasattr(pe, DIRECTORY_ENTRY_IMPORT): for entry in pe.DIRECTORY_ENTRY_IMPORT: imports.append(entry.dll.decode(ascii, errorsignore)) exports [] if hasattr(pe, DIRECTORY_ENTRY_EXPORT): for sym in pe.DIRECTORY_ENTRY_EXPORT.symbols: if sym.name: exports.append(sym.name.decode(ascii, errorsignore)) return ep, ep_section, linker, imports, exports for p in argparse.ArgumentParser().parse_args().files: ep, sec, linker, imports, exports scan_pe(p) print(f{p}\tEP{ep:#x}\tSection{sec}\tLinker{linker}\tImports{len(imports)}\tExports{len(exports)})这个脚本用 pefile 重新实现了 DIE 的核心读取逻辑。EP 是入口点 RVAep_section 用它落在哪个区段来判断壳的特征linker 取的是链接器版本对应 2.3 的第二个证据imports 和 exports 是真实数量。对一个 UPX 样本运行脚本输出一般会是SectionUPX1 Imports2 Exports0与 DIE 的提示完全吻合。如果脚本没有被特征库干扰但你仍然怀疑有壳那么差异就出在特征匹配之外需要去看字节层的细节。验证方法也很简单拿同一个样本先跑脚本再跑 diec然后 dumpbin。三者一致直接进入分析不一致就以脚本输出的原始字段为基准慢慢排查是哪一层信息被壳修改过。我自己的教训是很多误报不是工具不靠谱而是特征库更新后引入了新的判定逻辑。脚本里的 PE 头数据是最稳定的锚点只要它没被定向伪造结论就有大概率正确。我现在拿到任何未知样本都会让脚本先把 EP 区段和导入 DLL 列表打出来再拿 DIE 的壳名去对号。查壳工具负责方向原始 PE 数据负责兜底。希望帮到你。本文还有配套的精品资源点击获取
