简介Detect It EasyDIE是一款专业跨平台查壳工具定位上直接对标PEID但检测能力更强适合逆向分析、恶意代码排查及软件调试场景。压缩包共1362个文件、13.55MB以sg格式文件为主另有110个html说明、exe/dll主程序以及qm/qss、_init等配置/界面文件基本对应工具主程序、文档、界面资源与插件扩展便于按需提取或二次开发。资源已有4146人浏览学习相比PEID具备免安装、拖放检测、16进制编辑、自定义插件与脚本等特色还能读取多数查壳工具无法打开的超大文件。通过该包可获得可直接运行的DIE多平台绿色版支持Windows、macOS与Linux内置文档还覆盖多语言切换、皮肤更换、插件开发与脚本编写可快速掌握从拖放检测到十六进制编辑的完整流程。其文件组织可在离线环境下完整运行对入门新手和逆向老手都很有帮助。1. 最好的查壳工具DIE为什么老牌PEiD越来越不好用如果你和我一样拿到一个来历不明的 exe先不急着双击第一件事是查壳。查壳工具 DIEDetect It Easy这几年基本取代了我当年常用的 PEiD它开源、跨平台能扫出 PE、ELF、Mach-O 三类文件还会在结果里同时给出加壳器、编译器、保护器和附加数据比 PEiD 那个年代的要么报壳名、要么什么都没有体验强太多。PEiD 不是不好是停更太久遇到新壳和 Linux 下的样本就力不从心DIE 胜在还有人在维护、特征库可自定义、命令行能接脚本。这篇文章按我自己的使用习惯把 DIE 的原理、界面操作、命令行批量和几个典型踩坑点一次讲完。2. DIE 在查什么识别逻辑、签名格式与 PEiD 的差距2.1 一次查壳动作背后发生了什么PE 结构解析与特征匹配查壳工具不是玄学它做的是静态特征比对。DIE 拿到一个文件后第一层先解析容器结构如果是 PE 文件就依次读 DOS 头、NT 头、节表和导入表如果是 Linux 下的 ELF就解析节头。这一步的目的是把文件拆成哪些字节是头、哪些是代码、哪些是数据后续的匹配才有坐标可依。拆完之后DIE 会同时在三个层面找线索而不是只查一个点第一是节区特征。UPX 加壳后的文件通常出现UPX0、UPX1这样的区段名区段权限也被改成了可读写可执行ASPack 一类壳也有自己的区段命名习惯。签名库里存的就是这些一看就很可疑的组合。第二是入口点EP特征。加壳器为了在运行时解压总要在入口处放一段特殊的启动字节序列比如老版本 UPX 常见的pushad开头。DIE 会把入口点附近的几十个字节和签名库里的 EP 特征做模糊匹配。很多变形壳专门抹掉这部分字节所以入口点对不上也是常见结果不能因此断定没壳。第三是熵值。加壳和加密的区段数据分布接近随机计算出来的字节熵明显偏高。DIE 的信息面板会按区段给出熵值我一般把这个当作独立于签名库的第三重证据即使签名库一个都没命中某个区段熵值异常高也应该把它当成疑似有壳。理解了这三层就明白为什么 DIE 有时会换一个模式结果不一样了。普通扫描跑的是精确签名匹配深扫模式会放宽匹配条件、尝试更多偏移位置甚至对入口点之外的区域做交叉比对代价是扫描时间变长。这不是工具抽风是匹配策略本身分了两档。2.2 从 PEiD 的 userdb 到 DIE 的签名两代签名体系的差别PEiD 时代的核心资产是一个叫userdb.txt的文本文件里面每一行是一条签名规则格式固定想新增一条特征只能照着老格式手写写错一个偏移位就白搭。PEiD 停更后社区虽然做过一些扩展包但整体维护节奏慢了下来遇到新出的商用保护壳基本靠碰运气。DIE 的签名体系是结构化设计的。它按 PE、ELF、Mach-O 分文件类型维护签名库每条签名可以表达入口点附近有某段字节、同时某个区段名符合条件、再配合一个偏移掩码这种组合规则而不是一根筋的串匹配。这个设计带来的实际好处有两个一是误报率明显比 PEiD 时代低因为单点命中就能报壳的情况变少了二是用户自定义签名不需要动主库DIE 有独立的签名管理和导入导出入口我手里的私有壳特征可以单独存一份升级工具时也不会被覆盖。拿我自己换工具的经历来说当年最让我受不了的场景是PEiD 对一个用 Delphi 写的正常小工具报了 Nothing found其实就是签名库对编译器特征覆盖不全而 DIE 打开后直接标出Compiler: Delphi。这种编译器识别能力在 PEiD 时代经常被忽视但恰恰是它让我对结果有了基本信任——先知道文件是用什么写的才能判断后续该不该继续脱壳分析。下面这个对比表可以直观看出两者的差别对比项PEiDDIE签名格式固定文本行结构化条件、支持掩码与组合支持文件类型以 PE 为主PE、ELF、Mach-O维护状态基本停止社区持续维护扫描模式单一模式普通扫描 深扫熵值辅助无按区段展示跨平台WindowsWindows / Linux / macOS2.3 选型边界DIE 能查什么不能查什么聊到这儿得把边界说清楚免得期望错位。DIE 能告诉你文件是什么编译器写的、有没有加壳、加的什么壳、壳的大致版本、文件尾部有没有附加数据Overlay、入口点在哪、每个区段的熵值多少。这些信息对恶意样本初筛、打包器识别、加壳前后对比已经非常够用了。但 DIE 不负责脱壳。识别出 UPX 只是第一步解不开、入口点不对、导入表被破坏这些事它帮不上忙。DIE 也不做行为判断它不会告诉你这个文件是不是恶意软件只告诉你它的静态特征长什么样。我经常提醒刚入门的朋友不要把查壳结果当成安全结论壳只是一个维度特征全绿的文件照样可能是恶意样本。还有一点容易被忽略DIE识别不到不直接等于没有壳这个判断要留到深扫和熵值都看过之后再做。后面避坑章节我会专门展开。3. 第一次跑通 DIEGUI 扫描、看懂结果面板和 Deep 模式3.1 解压即用的工作流拖文件、点扫描、看结果我这里说的 DIE 是它的 GUI 版Windows 下解压就能运行不用安装。打开后界面不复杂上方是文件路径和扫描选项中间结果区等扫描完会列出识别到的条目旁边信息面板显示文件头、节表、入口点和熵值这些细节。一个最小工作流是这样的从压缩包解压出 DIE 的主程序双击运行。把待分析文件拖进窗口或者点文件选择按钮定位到目标。同时把扫描模式切到 Deep深扫再点扫描按钮。看结果列表里的分类和名称。再去信息面板核对入口点、区段名和熵值。我一般在隔离环境里操作这一步不在宿主机上双击任何来路不明的文件——静态扫描虽然不执行数据但养成这个习惯对整体安全很重要。文件拖进去之后DIE 的响应速度通常很快一个小型 exe 用深扫也就一两秒如果样本是个几十 MB 的自解压包深扫会明显变慢这时候可以先跑普通扫描拿个初步结果。3.2 Deep 深扫模式为什么普通扫描报 Nothing found 不能当真DIE 的普通扫描和深扫差别是什么普通扫描只在签名库里按预设规则走一遍匹配到哪条就报哪条速度快但容易漏。深扫会额外尝试放宽的条件组合比如入口点特征被改写时它仍然会去其他区段找壳的特征字节或者通过节区权限异常来兜底判断。实际效果是很多普通扫描报干净的样本切到深扫立刻现出原形。我遇到过一个典型情况一个被人手动改过区段名的 UPX 压缩包普通扫描列出的是编译器特征完全没有 UPX 字样切到深扫之后结果里才出现Packer: UPX。事后分析是壳的版本特征被改了一两个字节普通模式那条签名精确匹配失败深扫用更宽的条件才命中。实操建议很简单直接用深扫作为日常默认不要每次先普通扫一遍再补扫。DIE 对普通文件做深扫的额外耗时很小但对大文件和网络驱动器的样本会放大延迟。我自己的习惯是本地文件一律深扫网络路径拉回来的大文件先普通扫一次决定值不值得深扫。3.3 看懂结果字段Compiler、Packer、Protector、Overlay 的区别DIE 的结果列表不是简单报一个壳名就完事它会按类型归类。新手最容易在这一步犯迷糊因为看到任何英文标签都当成有壳。我把常见类型整理成一张表结果类型含义常见示例下一步动作Compiler编译器特征Visual C、Delphi、Go正常构建痕迹一般无需处理Packer加壳器UPX、ASPack可能需要脱壳或继续分析Protector保护器Themida、VMProtect高强度保护静态分析难度大Overlay附加数据文件尾部附加内容用十六进制查看尾部可能有配置或内嵌包看到Compiler类结果时不用紧张它只是说明这个文件是用什么语言/编译器生成的。看到Packer或Protector才说明存在代码保护这时候才值得进入下一步脱壳或动态分析。Overlay 是很多人忽略的部分文件尾部如果带附加数据DIE 会单独标出来我一般会顺手用十六进制工具看一眼经常能发现签名、配置字符串甚至内嵌的其他文件。信息面板里的熵值这一项也建议养成看的习惯。如果整个文件熵值都异常高即使类型列干干净净也拿着当疑似加密或加壳处理别因为签名库没命中就把样本放行。4. 把 diec 接进分析流程命令行批量扫描与输出解析4.1 diec 最小用法单文件扫描与帮助输出DIE 自带命令行版diecWindows 发行包里对应的是diec.exe。它和 GUI 共用同一套签名库也就是说你在 GUI 里能识别的命令行一样能识别。对做批量样本初筛的人来说这是 DIE 比 PEiD 顺手很多的关键点——PEiD 时代想批量查壳得手动写插件DIE 直接给了一个独立的 CLI 工具。最常见的调用方式很直接cd D:\tools\DIE diec.exe sample.exe命令执行后会在标准输出里逐行打印识别结果。先跑这一条确认你的 DIE 目录和路径没错再看输出内容长什么样。不同版本的diec支持的参数会有些差异最稳的做法是直接看当前版本的帮助diec.exe -h这里我不用背参数表因为每个版本列出的选项不完全一样你只需要记住一个原则不带参数直接跟文件路径这个用法是通用的带参数之前先-h确认一次。有些版本支持输出 JSON 格式有些支持在扫描时指定深扫这些都以实际帮助输出为准。4.2 批量目录扫描一个 Python 调用脚本有了 CLI批量扫描就变成了一件很朴素的事遍历目录下所有文件逐个调diec.exe把输出汇总起来。这是我常用的一个最小脚本直接抄过去改路径就能用import subprocess from pathlib import Path DIE_CLI rD:\tools\DIE\diec.exe def scan_one(path: Path) - str: result subprocess.run( [DIE_CLI, str(path)], capture_outputTrue, textTrue, encodingutf-8, errorsignore, timeout30, ) return result.stdout.strip() if __name__ __main__: target_dir Path(samples) for sample in target_dir.glob(*.exe): out scan_one(sample) print(f{sample.name}: {out})解释一下这里几个关键参数capture_outputTrue是让子进程的输出被截获而不是直接打印到终端脚本才能拿到结果encodingutf-8配合errorsignore是为了兼容不同 Windows 系统的默认代码页DIE 输出以英文为主这样处理基本不会乱码timeout30给单个文件设了 30 秒上限防止某个超大文件或畸形文件让子进程卡死整个脚本挂在那里等。这个参数值我一般保持 30扫描目录里出现几十 MB 的自解压包时够用也不会因为单个样本拖垮整批任务。脚本的重点是glob(*.exe)这个模式只匹配了根目录下的 exe不会递归进子目录。实际场景里样本目录经常有多层结构需要改成rglob(*)再结合suffix后缀判断。改法很简单但第一次跑的时候建议先拿一个小目录验证输出格式再放开到全量样本。4.3 输出解析的坑先肉眼看一次再写解析规则接 CLI 输出的时候最容易翻车的地方是解析逻辑写得比实际输出格式更复杂。我的经验是别按网上的旧教程直接写正则先用 4.1 的命令手动跑一个样本把 stdout 原样贴出来看一眼。DIE 的输出格式在不同版本之间有微调完全按照记忆中的列名去解析很可能得到一堆空结果。就我实际使用的体会diec的输出里每个识别项一般是一行文本包含类型关键字和名称。脚本里做粗过滤时不需要精确到每一列只关心有没有出现关键类型就够了比如在 4.2 脚本基础上加一个简单判断if Packer in out or Protector in out: print(f{sample.name}: 疑似加壳 - {out})这条逻辑对应的是日常初筛的真实需求Compiler 类直接放行只有 Packer 和 Protector 才需要人跟进。如果你真的需要结构化结果优先看当前版本是否支持 JSON 输出支持就直接解析 JSON别拿文本切片去拼字段。文本解析不是不行而是遇到多行输出和首尾空白时容易出怪问题JSON 至少能让字段边界稳定下来。另一个容易被忽略的点是子进程的退出码。diec对大多数文件都能正常退出但碰到损坏的 PE 文件可能会有非零退出码Python 的subprocess.run默认不会抛异常脚本会默默把空输出当成没识别到。稳妥做法是在scan_one里检查result.returncode非零时单独标记出来避免把工具自身的错误误判成无壳。5. 查壳避坑识别了不等于能脱没识别也不等于没壳5.1 把编译器当壳最常见的误读翻车现象DIE 扫描结果里出现Microsoft Visual C、Delphi、Go Build Info新手马上紧张起来以为文件被加了壳到处找脱壳教程。原因DIE 的签名库里包含的是文件是怎么构建出来的这个维度的信息。编译器特征是正常程序的痕迹不是代码保护。PEiD 时代这类识别少很多人形成了只要工具报英文名就是加了东西的刻板印象换到 DIE 上就误读。解决先看结果类型字段。类型是Compiler就直接放行它和加壳没有任何关系只有Packer、Protector才值得进入下一步。这个判断用熟了之后会很快但新手阶段建议每看到一个结果先确认类型再决定要不要分析别看到英文就紧张。5.2 普通扫描和深扫结果不一致不是工具抽风是漏匹配现象同一个文件普通扫描报Nothing found或者只报编译器切到深扫后明显多出Packer: UPX之类的结论。有朋友认为是深扫扫描算法不一样产生了玄学差异实际不是算法问题是匹配规则宽严的差异。原因很多加壳器会对自身体积和特征做过微调比如修改 UPX 版本号字段、改变区段名的个别字符、在入口点字节序列里插入无关指令。普通扫描的精确匹配在这些变形面前会失效深扫用更宽松的组合条件才能命中剩下来的节区特征和入口语义。解决日常直接把扫描模式固定在 Deep。如果深扫之后依然什么都没有再考虑可能确实没有已知壳而不是拿普通扫描的Nothing found直接下结论。另外注意一个边界深扫命中的是特征匹配不是一定存在保护逻辑最终判断还是要结合入口点和熵值一起来看。5.3 认出 UPX 却脱不掉查壳和脱壳是两件事现象DIE 明确报出Packer: UPX于是执行upx -d想一键脱壳结果报错或者脱出来的程序双击就崩溃就回头质疑 DIE 报错了。原因DIE 识别的是特征不代表这个 UPX 壳是标准未修改的状态。很多样本的 UPX 壳被二次处理过区段名改过、入口点重写过、甚至壳的版本字段被清空。upx -d只能解自己标准格式的包遇到上述情况自然解不动。解决先别急着把upx -d当解药。正确姿势是用 DIE 记录下入口点、区段名和节区权限然后带着这些信息进调试器。常见流程是在 x64dbg 里跑到壳的还原指令附近比如 UPX 的popad位置跟到原始入口点OEP再 dump 内存并重建导入表。这套手动脱壳流程是另一个话题但至少方向要清楚查壳工具给了你它是什么而怎么解要靠调试和分析。5.4 新壳漏报特征库滞后靠什么兜底现象拿一个用新版本 Themida 或 VMProtect 保护的文件给 DIE 扫结果只有Protector: Themida甚至干脆什么都报不出来。原因商用保护壳更新周期短每次大版本迭代都会新增防识别手段DIE 的签名库是社区维护的永远存在滞后窗口。这不是 DIE 不行是静态查壳本身的天花板。解决升级 DIE 本身和更新签名库是第一步但别只依赖这个。日常初筛我会做两件额外的事第一看熵值被加密或压缩过的节区熵值会明显高于普通代码节区熵值异常高但签名库没命中时按疑似有壳标记等待人工分析第二看入口点DIE 信息面板会给出文件入口点地址如果入口点落在最后一个节区或者权限异常的节区里这不是正常编译器会做的事值得再深挖一层。记住一句话查壳工具识别出来是白捡的识别不出来才是常态兜底靠的是熵值和节区异常这两类证据。6. 进阶与验证用自己的样本确认 DIE 一直在正常工作6.1 先验证签名库是醒的用 UPX 做一个最小实验查壳工具用久了容易踩一个盲区不知道当前环境的签名库到底覆盖到什么程度。我的习惯是隔一段时间就做一个最小实验验证 DIE 的识别链路没断。实验成本很低。拿一个自己编译的 Hello World 程序或者任何一个小体积的可执行文件用 UPX 加壳然后让 DIE 深扫同一个文件upx -k hello.exe diec.exe hello.exe加壳前如果先扫一次结果应该是Compiler: XXX加壳后深扫结果里应该多出Packer: UPX相关条目。如果加壳后 DIE 仍然只报编译器那说明你手头这个 DIE 版本对 UPX 的识别已经过时了该考虑换新版本或更新特征库再继续干活了。这个验证的价值在于它能帮你区分工具没识别出来和样本确实无壳这两种情况只凭一次扫描结果下判断容易把责任搞混。6.2 把 DIE 的结论接进判断习惯而不是只看壳名进阶使用 DIE 到最后拼的不是某个冷门参数而是怎么组织判断流程。我现在拿到一个待分析样本动作是固定的DIE 深扫 - 看类型字段 - 看熵值和入口点 - 再决定要不要手动跟。这一套下来大部分普通样本在几分钟内就能分类清楚真正需要投入精力的永远是少数几个特征异常的样本。自定义签名这件事也值得在需要时用起来。DIE 支持把用户自己的特征单独存放在独立位置遇到私有壳或内部工具时可以自己录特征而不影响官方签名库的升级覆盖。具体录入格式以你当前版本的签名编辑器提示为准不同版本细节有差异但独立保存、升级不覆盖这个原则是一致的。我当年花在 PEiD 上的时间不少换到 DIE 之后最直接的感受是查壳这一步终于不再依赖碰运气了结构化结果加上熵值佐证让初筛环节有了一条稳定的判断路径。这不算什么高深技巧但确实帮我省下了大量冤枉时间。希望帮到你。本文还有配套的精品资源点击获取