简介Detect It EasyDIE是一款专业查壳工具面向逆向分析初学者、安全调试人员及CTF参赛者可快速识别未知壳、加壳器与打包器与PEID相比它采用深度扫描与多引擎匹配能一次检测到底即便其他工具无法打开的超大文件也能正常读取。这份资料共1362个文件压缩包仅13.55MB主体为sg特征库文件用于定义各种壳与编译器的签名规则另有html说明文档、qm多语言文件、dll动态库和exe主程序组成跨平台可运行的完整工具套件同时保留插件接口便于后续扩展。目前已有4149人学习下载。工具本身绿色免安装支持拖放检测、右键菜单、简体中文界面并内置16进制编辑器与多皮肤用户可以自行编写脚本、添加自定义插件针对特定加壳样本做补充匹配广泛覆盖当前常见压缩壳、加密壳和打包格式。对于需要频繁辨别程序是否加壳、加了什么壳的软件分析场景DIE完全可以替代PEID让查壳流程更高效。1. 查壳工具 DIEDetect It EasyPEID 该退役了一眼看清加壳类型查壳工具 DIEDetect It Easy是我现在处理恶意样本、分析加壳程序时最先打开的工具没有之一。它解决的问题很具体拿到一个未知的 EXE/DLL先搞清楚这文件有没有壳、是什么壳、入口点大概在哪PEID 当年能做这件事但已经很多年不更新遇到新壳、伪装壳基本靠猜。DIE 不一样它把签名匹配、熵值分析、区段扫描放在同一个界面里识别结果直接给出壳名、类别和置信度新手也能一眼看懂。适合刚接触逆向、病毒分析、脱壳学习的人也适合内网做样本初筛的蓝队。这篇文章我会从原理讲到命令行实操再列出我在真实分析里踩过的坑。2. 为什么是 DIE多引擎签名、熵值与签名库的工作方式2.1 多引擎签名匹配不只看入口点PEID 的识别逻辑比较粗糙它主要靠入口点附近的字节特征去匹配已知壳的指纹匹配规则写死了遇到变种就抓瞎。DIE 的签名引擎不是单靠某一段字节而是把 PE 文件的多个结构拆开来看包括导入表特征、区段名称、入口点指令序列、文件偏移布局甚至资源段里的字符串每个维度的命中都会加分最后汇总成一个结果。常见做法是DIE 在匹配时会多个签名库里同时查而不是只查一个“壳列表”。比如一个文件既符合 UPX 的特征又带有某些编译器特征DIE 会把两者都列出来并且标明主类型和附加信息。我在分析样本时习惯先看 DIE 主界面的左侧列表那里会直接显示“UPX(3.xx)”或者“Microsoft Visual C”这样的结论。要注意的是签名匹配本质上是概率判断不是绝对真相后面我会专门讲误报的情况。DIE 支持的格式也不止 PE。PEID 基本只认 Windows 的 PE 文件遇到 ELF 或者 Mach-O 就无能为力了而 DIE 对这三种主流可执行格式都有对应的签名库。这对我这种偶尔要从 Linux 服务器上拖样本分析的人来说非常有用。就算只谈 PEDIE 对 32 位和 64 位的兼容性也明显更好。2.2 熵值分析查壳的第二只眼睛签名匹配可以被壳作者刻意干扰比如伪造区段名、修改入口点字节但熵值很难伪装。熵值衡量的是文件数据的“混乱程度”未加壳的原生 PE 文件代码段和数据段有清晰的逻辑结构熵值通常不高加壳后的文件原来的代码被压缩或加密变成了接近随机分布的数据熵值会明显升高。DIE 在界面里直接提供了一个熵值可视化图不用自己拿脚本算。我一般这样读整个文件的平均熵值如果超过 7.0基本可以确定加壳或者加密了在 5.0 到 7.0 之间属于灰色地带可能是某种压缩壳也可能只是资源段体积很大低于 5.0 且签名匹配不到任何壳大概率是原生程序。这只是一个经验区间不是严格标准但作为初筛已经够用。除了整体熵值DIE 还能按区段显示熵值分布。比如 UPX 壳的典型特征是入口点所在区段熵值很高而其他区段可能相对低一些因为 UPX 会把原始代码压缩后放在单独区段。这个细节对后面手动脱壳时定位 OEP 很有帮助。2.3 签名库的组件方式规则不是黑匣子DIE 的签名库和 PEID 不同它不是编死在程序里的而是以文本规则文件的方式放在安装目录的 db 文件夹下。每个壳、编译器、打包器都有对应的规则文件比如 UPX 的规则、MPRESS 的规则。规则文件是文本格式可以用编辑器打开看里面定义了匹配类型、匹配模式、壳名称和版本信息。这意味着两件事。第一DIE 的识别能力可以自己扩展遇到新壳或者私有壳可以照着现有规则的格式写一条新规则加进去不用等官方更新。第二整体签名库升级很简单直接替换 db 文件夹的内容就行不像 PEID 那样要换整个程序。我在维护分析环境时会周期性更新一次签名库这是减少漏报最直接的手段。这套机制和杀毒软件的病毒库思路类似但它更透明因为你随时能打开规则文件去看某条规则的匹配逻辑是什么。DIE 不是黑匣子这就是它比很多商业查壳工具更让人放心的原因。3. 从 GUI 到命令行用 DIE 跑通单个样本与批量扫描3.1 GUI 拖文件与分析面板DIE 的图形界面使用门槛很低安装后直接把样本文件拖进主窗口就行。界面左侧是检测结果列表右侧是文件的详细结构信息包括 DOS 头、PE 头、区段表、导入表、导出表等。我最常用的操作路径是拖入文件先看左侧识别结果然后点开“区段”标签页看每个区段的名称、虚拟地址和熵值最后切到“熵”标签页看整体熵值分布曲线。三步走完基本就能判断这个文件有没有壳、壳的类型以及入口点大概在什么位置。右键点击结果条目还可以直接复制检测文本方便贴到分析报告里。GUI 还内置了 Hash 计算功能右键样本文件可以一键算出 MD5、SHA1、SHA256不用另开工具。这个细节在病毒分析里很实用因为提交报告的时候通常要附上文件哈希省一步是一步。3.2 命令行 diec 的最小用法DIE 自带命令行程序Windows 下一般是diec.exeLinux 下对应的命令叫diec。在自动化脚本或者没有图形界面的服务器上命令行版本是主力。不同版本的参数略有差异先用--help看一眼当前版本支持的参数再跑实际命令。# 查看帮助确认当前版本支持的参数 diec --help # 单文件扫描默认文本输出 diec sample.exe # 单文件扫描输出 JSON 格式方便脚本解析 diec -j sample.exe # 递归扫描整个目录下的所有可执行文件 diec -r /samples/2025/ -j这段逻辑要说明一下。第一条命令是每次换环境必做的因为 DIE 的命令行参数在不同版本里有过调整直接依赖记忆里的参数名容易翻车。第二条命令是最简单的使用方式输出结果里会包含检测到的壳名、编译器信息和熵值提示。第三条命令加-j参数后输出 JSON 结构字段包括文件名、检测类型、检测名称、熵值等这个格式对写脚本非常友好。第四条命令用-r指定递归目录加上-j后适合做批量样本初筛。我在实际分析中会把-j输出重定向到文件里保存因为文本输出看起来直观但 JSON 输出更适合后续统计。比如想知道一批样本里有多少 UPX 壳、多少 VMProtect 壳直接解析 JSON 比肉眼看得快得多。3.3 批量扫描脚本一次处理几百个样本如果只是扫描几个文件命令行手敲就够了。但做样本收集或者应急排查时经常拿到一个目录几百个文件这时候就需要写一个循环脚本。在 Windows 的 CMD 下可以这样写for /R C:\samples\2025 %i in (*.exe *.dll) do diec -j %i result.jsonl解释一下这条命令的作用for /R指定从C:\samples\2025目录开始递归搜索in (*.exe *.dll)限制只处理这两种扩展名do diec -j %i对每个命中的文件执行 DIE 扫描并输出 JSON result.jsonl把结果追加写入一个 jsonl 文件每个文件一行。这样扫完一整个目录最后得到的是一个可以被 Python、jq 直接读取的结果集。是追加重定向不是覆盖所以多个文件的结果会依次追加到同一文件里。如果用单个每扫一个文件就会把之前的覆盖掉最后只剩最后一个文件的记录这是很多人踩过的坑。扫完后再用 jq 或者 Python 按检测类型分组统计就能快速得出这批样本的加壳分布情况整体效率比 GUI 手动拖文件高出一个数量级。4. 识别结果怎么读壳、编译器、混淆器与 OEP 的判断4.1 先分清四类结果壳、编译器、打包器、混淆器很多新手拿到 DIE 结果看到“UPX”就以为文件加了壳看到“Microsoft Visual C”就以为没壳其实不够准确。DIE 的检测结果按类型分为几类壳Packer、保护器Protector、编译器Compiler、打包器Installer、混淆器Obfuscator。每一类的处理思路完全不同。壳和混淆器才是需要重点关注的编译器和打包器只是辅助信息。比如一个文件被 DIE 识别为“Microsoft Visual C 6.0”这只能说明它用什么语言写的不构成篡改或保护但如果你看到一个文件同时被识别成“VMProtect”和“Microsoft Visual C”那 VMProtect 才是主要关注对象。按熵值和区段信息去分类壳的特征是入口点代码被替换成解压/解密逻辑原始入口点被保存在壳的数据区里混淆器则不一定改变整体文件结构更多是在代码层面做等价变形。两者的脱壳策略差异很大前者要先找 OEP后者可能需要先做反混淆。4.2 常见壳的识别样式和判断要点我用一个表格整理最常见的识别结果方便对照DIE 显示名称、通常伴随的熵值特征、以及我的判断思路。DIE 识别结果典型熵值表现判断要点UPX整体熵值高入口点区段尤其高最常见改动少的话可以直接用 UPX 官方工具脱壳MPRESS中等偏高区段名通常是 MPRESS1、MPRESS2脚本/程序压缩常见手动脱壳要修区段属性VMProtect整体熵值很高虚拟机化特征明显不建议手工硬脱优先考虑动态分析Themida/WinLicense区段名混乱导入表被加密有反调试环境检测严需在隔离环境处理Enigma多个壳特征叠加熵值波动大新版带虚拟化和 VMProtect 处理思路类似ASProtect区段名带 ASPack 相关字样老旧壳脱壳工具较成熟这张表里最难判断的是 VMProtect 和 Themida。两者都不只是简单压缩而是对代码做了虚拟化或者加密保护DIE 识别出名字只是第一步不代表你能轻松脱壳。我在处理这类样本时更倾向于把 DIE 当作定位工具用它的区段和熵值结果去配置 x64dbg 的调试策略而不是指望一个按钮搞定。4.3 从识别结果到 OEPDIE 怎么帮你找入口点查壳的最终目的在很多场景下是为了脱壳后在调试器里找到原始入口点OEP。DIE 不直接给出 OEP 地址但它提供的区段信息能大大缩小找 OEP 的范围。通常做法是先看 DIE 里入口点所在的区段加壳程序的入口点一定落在壳代码区段而不是原始代码区段。然后在 x64dbg 里打开样本先停在系统断点再运行到程序入口点对比一下当前 EIP 所在的模块和 DIE 显示的入口点区段是否一致。如果一致就可以开始单步跟踪解压循环跟踪过程中留意跳转到原始代码区段的大跳转那个目标通常就是 OEP。DIE 的熵值分布在这个阶段也很有用。壳的解压循环执行完的瞬间内存里的数据熵值会显著下降如果你在用硬件断点或者内存断点监控某个区段就能感知到解压完成的时间点从而定位 OEP。这个方法对 UPX 和 MPRESS 这类传统壳非常有效。5. 避坑清单DIE 误报、漏报和假壳的排查记录5.1 DIE 报 Nothing found文件却明显有异常现象DIE 扫描结果为空没有匹配到任何壳或编译器但是文件在运行时会释放恶意载荷或者在虚拟机里触发异常行为。原因样本使用了私有壳、变种壳或者作者手动修改过壳特征导致现有签名库完全不命中。另一种情况是这个壳本身比较新官方签名库还没收录。解决不要因为 DIE 没报就判定“无壳”。先把熵值调出来看一眼如果整体熵值高于 7.0基本可以确定加壳了再用 x64dbg 加载样本停在入口点观察是否有解压循环。我在遇到这种情况时会先用 DIE 看一眼熵值再用 PE 头里的区段数量辅助判断原生程序的区段数量通常是固定的几个加壳后会多出一些异常区段。5.2 同一份样本在不同机器上扫描结果不一样现象自己的机器上 DIE 识别出 UPX同事的机器上同一份文件却报 Nothing found或者识别出不同的壳名。原因两边 DIE 版本不同或者签名库的更新日期不同。DIE 的签名库是独立于主程序的只升级主程序而不更新 db 文件夹识别能力就不会提升。解决建一个统一的样本分析环境定期同步 DIE 主程序和 db 签名库。我在团队里一般会在共享目录放一个固定版本所有人从这个目录拷贝避免各装各的。做对比分析时如果结果不一致先核对双方的 DIE 版本和签名库版本。5.3 DIE 报 UPX但用 UPX 官方工具脱壳失败现象DIE 明确显示文件是 UPX 加壳执行upx -d却提示文件格式不对或解压失败。原因这是典型的“伪 UPX”样本作者手动修改了 UPX 的区段名、入口点特征让查壳工具误认为 UPX实际用的壳可能是自研的或者是在 UPX 基础上做了二次加密。解决先对比文件区段和标准 UPX 区段比如标准 UPX 一般有 UPX0、UPX1、UPX2 三个区段如果区段名被改成别的就要怀疑是伪装的。再检查入口点指令标准 UPX 入口通常是 pushad 加一些 mov 指令如果入口点直接是奇怪的循环或者异常指令直接放弃upx -d改用内存转储的方式处理。5.4 DIE 能识别壳名但脱壳后程序还是跑不起来现象按 DIE 识别的壳类型用对应工具脱壳成功重新运行却报错崩溃。原因这个程序可能是“多重壳”外层壳脱掉之后里面还有一层壳或者有完整性校验。DIE 很多时候只显示最明显的一层特征其他层被外层签名掩盖了。解决脱壳完成后不要急着运行先用 DIE 再扫描一次脱壳后的文件如果还是识别出其他壳就继续处理第二层。如果 DIE 已经显示原生编译器就要考虑程序是否做过校验和比对入口点留一个断点去观察校验逻辑。我在分析多重壳样本时会保留每一层的脱壳副本方便出问题时回溯。5.5 杀毒软件把 DIE 当成病毒清理掉现象DIE 刚下载完就被系统自带杀毒软件或者企业的终端安全软件删除或者在解压时弹窗警告。原因DIE 具备解析 PE 文件、分析壳特征的能力行为逻辑和恶意软件分析工具重叠杀软按照启发式规则很容易误报。解决杀软设置里加白名单把 DIE 的安装目录和下载目录排除掉。我在分析环境里一般会准备一台专用的离线 Windows 虚拟机不装杀软DIE、x64dbg、PE 编辑工具都放在里面从源头避免误杀和干扰。注意 DIE 这类工具只放在自己控制的隔离环境里使用不要随意传播给非分析用途的机器。6. 进阶把 DIE 接进自动化样本初筛和自定义签名用 JSON 输出驱动 Python 脚本按壳名自动分拣样本。import subprocess import json import os def scan_file(path): result subprocess.run( [diec, -j, path], capture_outputTrue, textTrue ) data json.loads(result.stdout) return data for root, dirs, files in os.walk(samples): for name in files: full_path os.path.join(root, name) try: data scan_file(full_path) print(name, data.get(detect, unknown)) except Exception as exc: print(name, f[error] {exc})这段脚本的核心是调用diec -j并解析标准输出。subprocess.run负责执行外部命令capture_outputTrue捕获输出textTrue让输出以字符串返回。拿到 JSON 后可以做条件判断比如检测结果里含UPX就移动到packed_upx目录含VMProtect就移动到vmp目录。写脚本时要注意 DIE 的 JSON 字段结构先手工跑一次diec -j sample.exe把输出打印出来确认字段名再写解析逻辑。自定义签名的思路。DIE 的签名库是文本文件安装目录下的 db 文件夹里按格式、类型拆分。想加自己的规则先打开一个现有规则文件观察它的匹配写法复制一条改成自己的名称然后把样本里提取的特征字节填进去。启动 GUI 后内置的签名列表会多出这一条。这是扩展 DIE 识别私有壳最直接的手段唯一的限制是你的特征要足够精炼太宽泛会大量误报。我在做自动化初筛时有个习惯DIE 的识别结果永远和文件哈希、文件大小、熵值一并记录不单独存壳名。因为单看“UPX”没有意义只有加上熵值和原始哈希才能判断这个加壳样本是从已知文件变种来的还是全新家族。这个习惯救过我一次——某个样本 DIE 报 UPX但哈希碰撞查不到任何历史记录后来确认是伪装壳如果当时只记壳名不记哈希这个问题根本发现不了。希望帮到你。本文还有配套的精品资源点击获取