简介Detect It EasyDIE是一款专业且免费的查壳工具定位为替代老牌PEID的进阶选择适合逆向分析初学者与安全爱好者。与PEID相比它检测能力更强能一次识别多层加壳并支持超大文件读取、自定义脚本与插件扩展兼容多平台。这份资源打包了DIE的完整绿色版共1362个文件体积约13.55MB主要文件类型包括大量检测签名sg、可执行程序exe、动态库dll以及HTML帮助文档、Qt界面与语言文件qm/qss等无需安装即可使用。目前已有4147人学习下载社区认可度较高。通过该资源可立即获得开箱即用的多语言查壳环境省去自行配置签名库的麻烦适合需要频繁查壳、比PEID更高效准确的分析场景。1. 查壳工具 DIE为什么我把它放在 PEID 前面先用一句话说结论PEID 查不到的壳DIEDetect It Easy大概率能查到PEID 打开就卡死的文件DIE 照样能读。这不是夸张是我把同一个加了多重壳的样本分别丢给两把工具实测后的结果。PEID 在 2006 年前后确实是查壳的代名词但它的特征库和扫描逻辑停在了那个时代面对 VMProtect、Themida 的新版本以及各种魔改壳经常只能给出一个“未知”或者干脆报错。DIE 不一样它是把“扫特征”和“看数据”两件事结合着做的特征库更新到近年还支持脚本二次验证查壳结果能精确到编译器、加壳工具、甚至加壳工具的版本号。这篇文章不讲大道理就讲 DIE 怎么装、怎么查、怎么写脚本以及我在实际拆样本时踩过的那些坑。2. 从 PEID 到 DIE检测原理和选型理由PEID 的核心玩法叫“特征码匹配”它拿目标文件的一段字节序列去和 userdb.txt 文本库里记录的已知壳特征做比对命中就报壳名。这个机制简单直接但有两个致命弱点。一是特征库太老新壳、魔改壳基本没见过二是纯文本行扫描误报率不低某个开源压缩壳的特征如果恰好出现在一段正常代码里PEID 就会神经质地报错。DIE 把检测逻辑拆成了两层第一层是它的“签名库”这个库不是简单文本行而是按 PE、ELF、Mach-O 文件格式的结构化条目来组织的每条签名可以指定文件偏移、字节掩码、熵值范围等条件第二层是“启发式和熵分析”当文件头部被破坏或者壳的入口点被抹掉时DIE 会计算整个文件或者指定区块的信息熵结合入口点代码特征做判断。这就是为什么它能做到“查一次查到底”——壳的签名壳在表层但壳的代码密度、加密段落的熵值分布是藏不住的。2.1 为什么 DIE 敢说自己能替代 PEID我做了个对比测试找了五个常见场景UPX 壳、ASPack 壳、VMProtect 加壳的 DLL、一个 2GB 的镜像文件、还有一个 PEID 一打开就报“Unknown”的混淆过的 exe。PEID 的测试结果里UPX 和 ASPack 能识别VMProtect 只能识别到旧版本号2GB 文件直接无法打开混淆 exe 报未知。DIE 在这些场景里的表现是UPX 和 ASPack 精确到版本号VMProtect 识别到对应版本2GB 文件打开和扫描都正常混淆 exe 给出了“可能为 Themida”的启发式结果。这里的关键差异在文件读取机制。PEID 用的是传统的文件映射方式大文件容易在内存映射阶段就出问题DIE 用的是分段读取结合流式扫描只有必要时才把整个文件载入内存。配合它的“熵值检测”逻辑即使文件达到数 GB也能先看文件头、再看分段熵值分布来决定要不要深扫这就是它敢说“其他工具打不开的它都能读取”的技术底气。2.2 安装和界面配置三分钟上手DIE 是绿色软件下载对应系统的版本后直接解压就能运行不需要安装。首次打开时建议做三件事。第一切语言菜单 Options - Language选简体中文。第二确认一下右键菜单有没有加上方便之后在文件上直接右键“扫描”。第三把皮肤调成你顺眼的深浅色这个无所谓但 DIE 自带的深色皮肤在高分屏下看十六进制数据比较舒服。一个实用设置是“检测模式”里的阈值调整。菜单里找到“选项 - 设置 - 扫描参数”把“启发式灵敏度”从默认调到高。这样做会让普通文件的扫描速度慢一点点但对加了花指令的样本检测率提升明显。我一般处理可疑样本时用高灵敏度处理常规软件时用默认值避免误报。Options - Language - 简体中文 Options - Skin - 选择你习惯的主题 Options - Settings - 扫描参数 - 启发式灵敏度 - High这几步配置的意义在于DIE 的默认灵敏度是平衡型的适合日常绿色软件检测而如果你在处理的是对抗性样本加壳软件的常见目标高灵敏度才能触发基于熵值和入口点代码的启发式规则。参数调整后不需要重启立即生效。3. 实战上手用 DIE 扫描文件并读懂结果检测一个文件最简单的动作就是把它拖进 DIE 主窗口。程序会自动识别文件格式如果是 PE 文件会按 DOS 头、NT 头、节表、导入表、导出表、资源段、入口点等结构逐项展示。查壳结果会直接显示在最上方摘要区通常是“编译器/加壳器: xxx [版本号]”这样的行。3.1 从拖文件到看懂三行关键结果拖一个 UPX 加壳的 exe 进去你会看到类似这样的摘要文件: sample.exe 类型: PE32 (x86-64) / EXE 大小: 153,600 字节 入口点: 0x4010A0 时间戳: 2023-05-12 10:22:33 检测结果: UPX(3.96) [Win32 EXE] .UPX0 .UPX1这里最值得注意的不是“UPX”三个字母而是括号里的版本号 3.96以及后面跟着的区块名 .UPX0、.UPX1。区块名直接证明了加壳器留下的痕迹UPX 的标准做法就是生成 .UPX0、.UPX1 两个区块。如果你看到检测结果只显示“UPX”但区块名不是这个就要怀疑是不是改过区块名的魔改版本后面手动脱壳时不能直接用通用脱壳机。如果是 VMProtect 加壳的文件DIE 的检测结果可能是检测结果: VMProtect(2.13.0) [Win32 DLL] .vmp0 .vmp1VMProtect 的检测原理比 UPX 复杂DIE 不是靠特征字节命中而是先识别出入口点处那一段特殊的代码混淆模式通常是 push jmp 配合栈帧伪指令再结合区块名和熵值分布综合判断。如果你手头只有一个新版本 VMProtect 的样本DIE 有时会给出“VMProtect(unknown version)”这时不要觉得是没查到它已经确认了壳家族只是特征库还没收录对应版本的标识字节。3.2 十六进制查看器验证检测结果的第一现场DIE 内置的十六进制查看器不是摆设它是验证查壳结果最直接的工具。点击主界面的“Hex”标签页你会看到文件原始字节和右侧的 ASCII 解码区。在 PE 文件里第一行的“MZ”头是固定标识偏移 0x3C 处的四字节指向 PE 头起始位置PE 头的“PE\0\0”标志后面就是机器类型、节表数量、时间戳等结构。我之前收到过一个样本直接拖进 DIE 查壳结果报“未知”但看十六进制数据时发现文件中间某个位置出现了连续的 0x90 填充NOP 指令而且节表里有两个区块的 RawSize 远大于 VirtualSize——这是典型的手动修改过头部的加壳文件。用“Hex”标签页的搜索功能搜“UPX”字符串会在资源段找到一个残留的版本信息字符串于是结论明确这是 UPX 壳只是入口点被抹掉了DIE 的签名匹配落空但残留字符串暴露了真相。所以我的习惯是查壳结果出来后先去十六进制区扫一眼入口点附近的 50 个字节再看区块表里的名称和大小关系。这两个动作加起来不超过一分钟能排除掉大部分误报和漏报情况。3.3 超大文件扫描的边界在哪DIE 的“超大文件”能力有一个实际的边界它能打开和扫描 4GB 以上的 PE 文件但前提是文件格式本身没坏。我实测过一个 2.8GB 的 exe某些游戏客户端长这样PEID 打开直接无响应DIE 大概花了 10 秒完成扫描结果指向一个不太常见的保护壳。但当我把一个损坏的 3.5GB 镜像文件丢给它时DIE 能读取文件头部分但在后续区块扫描时返回“文件结构异常”的提示。这个提示反而有用说明这文件被人为改过区块大小或破坏了 PE 结构。超大文件扫描时有一个设置值得改默认的“完整扫描”模式在大文件上耗时会很长建议把“扫描模式”改成“快速模式头入口点”。这会让 DIE 只检查文件头和入口点所在区块耗时从几分钟降到了几秒。当然代价是漏过隐藏在资源段或重叠区块里的壳特征所以有疑虑的文件还是切回完整模式再扫一遍。扫描模式: Full Scan默认 - 适合常规文件结果全面 Head Entrypoint快速 - 适合超大文件速度优先这个模式切换的核心逻辑在于大多数壳在加壳时都会把真正的入口点代码改写而文件头和入口点附近又是壳特征最密集的区域快速模式先扫这两个位置能覆盖绝大多数常见壳的识别需求。当你面对的是一大批文件要做初步筛查时这个开关能节省大量时间。4. 检测到壳之后借助 DIE 的扩展能力做深入分析查壳只是第一步更关键的是知道这是个什么样的壳、能不能快速脱、能不能提取出原始入口点。DIE 在“查壳识别”之外还自带了三个实用层次插件系统、脚本系统和十六进制编辑。这三个层次从低到高正好对应了“批量检测 - 自定义特征 - 手动修复文件”三种分析需求。4.1 插件系统把 DIE 变成你的检测工作台DIE 的插件是以 DLL 或 .py 脚本形式存放在插件目录里的。安装插件的路径通常在 DIE 安装目录下的 plugins 文件夹Windows 版本支持 .dll 插件跨平台版本则支持 .py 脚本插件。插件能做的最有价值的事情是“自动化脱壳”比如对 UPX 壳的样本一个合格的插件可以在检测到 UPX 后直接调用脱壳逻辑把结果写到指定目录。插件开发方式不算复杂如果你会 Python可以写一个脚本监听文件扫描事件# 伪代码示例展示 DIE 插件的基本逻辑 # 放在 plugins 目录下DIE 启动时会自动加载 import_die_api() def on_scan_completed(file_path, result): # result 里包含 detection.name、detection.version if result.detection.name UPX: unpacker UPXUnpacker() # 调用外部 upx -d 命令必须做超时控制 success unpacker.run(file_path, timeout30) if success: log(Unpacked: file_path)这段代码的逻辑是监听到 UPX 壳就自动触发脱壳操作。实际落地时要注意两点一是弹出的外部进程必须设置超时否则遇到自修改壳可能无限等待二是脱壳是否成功不能只看退出代码要再回调一次 DIE 的检测接口做二次确认。我一般会在脱壳后用 DIE 重新扫描一次输出文件确认壳特征消失再交付结果。对不想写脚本的人来说DIE 自带的几个标准插件已经够用。插件菜单打开后能看到文件头扫描增强、导入表分析器、资源提取器。资源提取器对分析安装包类样本很有价值可以把嵌入的资源段完整导出省去了自己写解析脚本的时间。4.2 脚本编写定义你自己的查壳规则DIE 的脚本系统是它区别于 PEID 的地方之一。脚本用类似 Python 的语法写在 .py 文件里可以被扫描引擎调用用于定义“如果满足某些条件则判定为某种壳”的自定义规则。官方英文文档把这种机制叫“script signatures”非常准确——它让壳特征从静态的字节模式进化成了可编程的判断逻辑。一个常见的脚本场景是检测“伪装成 UPX 的魔改 UPX”普通 UPX 的特征是入口点附近出现 pushad/popad jmp 的组合魔改版会删掉 pushad/popad但保留 .UPX0 区块和特定的节表属性。用脚本写这个规则# 自定义魔改 UPX 检测脚本 # 逻辑区块名 节表属性 入口点代码特征综合判断 def detect(data, file_offset, args): # data 是目标文件经过 DIE 预处理后的字节流 # 先检查是否存在 .UPX0 和 .UPX1 两个区块名 has_upx_sections (data.search_section(.UPX0) and data.search_section(.UPX1)) if not has_upx_sections: return None # 再检查入口点附近是否缺少标准 UPX 的 pushad 指令 entry data.get_entry_point() bytes_at_entry data.read_bytes(entry, 10) has_pushad (bytes_at_entry[0] 0x60) # pushad opcode # 如果区块名符合但入口点不是标准 pushad判定为魔改版 UPX if not has_pushad: return { name: UPX (modified), version: unknown, detail: UPX sections found but entrypoint modified } return None这段脚本的核心逻辑是拿“区块名”和“入口点代码”做交叉验证。DIE 脚本引擎会把这个函数的返回值直接汇入检测结果。写新规则时建议先用十六进制查看器确认特征字节的偏移再写进脚本不然很容易误报。脚本调试也简单把写好的 .py 文件放进 scripts 目录重新扫描目标文件如果结果里没有出现自定义名称说明脚本没被加载或条件未触发可以用 print 到 DIE 的日志窗口辅助排查。4.3 十六进制编辑手动修复加壳文件的最后手段遇到自动脱壳工具失效的情况DIE 内置的十六进制编辑功能能派上用场。它支持对文件字节做原地修改改完直接保存。这项能力在做“入口点修复”时最实用——很多壳会把原始入口点OEPOriginal Entry Point加密存储在某个区块里自动脱壳机识别不到时你就可以在十六进制界面里手动定位 OEP 数据把它填写到 PE 头的 AddressOfEntryPoint 字段。操作路径是十六进制标签页 - 定位到 PE 头偏移通常是 0x3C 处指示的值- 找到 0x28 处的入口点字段 - 右键编辑这 4 个字节。处理前务必先备份原文件并把十六进制编辑器的“写保护”关闭。我做这个操作时惯用一组工具配合先用 DIE 查壳和看区块表和入口点再用一个轻量十六进制工具去做修改改完再回 DIE 验证结构是否完整。DIE 的十六进制编辑适合小幅修改不适合大段算术操作——大范围的数据修复还是交给专业十六进制编辑器这是工具的边界。5. 查壳避坑笔记现象、原因和解决路径以下五条是处理真实样本时踩过的坑。每条都是一个闭环现象 - 原因 - 解决直接照搬能少走弯路。坑一DIE 报“无可用信息”但 PEID 报 UPX现象同样的 UPX 加壳文件PEID 能识别DIE 显示“无可用信息”。原因这个文件被改过区块名.UPX0/.UPX1 被改成了 .data/.rdata且入口点不是标准 UPX 开头DIE 的特征库规则没触发而 PEID 的 userdb.txt 匹配到了残留的 UPX 字符串。解决别急着否定 DIE。切到十六进制页签搜“UPX”字符串把入口点附近的字节手动贴到 DIE 的“自定义签名”里做个临时匹配或者用脚本规则按残留字符串 熵值双重特征做判定。坑二DIE 把普通编译器识别的文件报成“可能是加壳”现象一个正常的 VC 编译 exeDIE 给出“可能加壳”的启发式结果。原因启发式灵敏度调的过高。VC 编译器的启动代码段有大量 call/jmp 交替和某些壳的特征在熵值分布上很像。解决把灵敏度调回默认值或者用“检测模式 - 仅使用签名库”关闭启发式判断。需要说明的是这类现象在加了 MSVC 链接器的 /GUARD:CF 安全机制的 exe 上更常见这是正常编译器行为。坑三超大文件打开后界面卡了十几秒现象把一个 2GB 的 exe常见于大型单机游戏拖进 DIE整个界面假死约 15 秒后才恢复。原因DIE 默认做了完整扫描对 2GB 文件要逐区块读取。解决点开检测模式选择“快速模式头 入口点”。如果是临时打开可以用 CtrlO 换成“打开为数据流”模式只读头部信息不触发全盘扫描。坑四多文件批量查壳时个别文件被跳过现象用 DIE 的批量扫描功能分析整个文件夹时某些 exe 没有输出结果。原因这些文件在扫描过程中抛出了异常通常是文件被其他进程独占锁定或者文件结构损坏触发了引擎保护分支。解决批量扫描时先看 DIE 的日志输出窗口被跳过的文件会留下错误代码。90% 的情况是文件锁定先关闭占用进程再重扫。损坏文件则单独处理确认结构后决定是否保留。坑五DIE 的检测结果和 VirusTotal 上的壳报告对不上现象同一个样本本地 DIE 报“无壳”VirusTotal 上 20 个引擎里有 3 个报了个加壳器名字。原因VT 是多引擎聚合它报的“壳”可能来自某个标记常驻的引擎那个引擎的判定逻辑偏向保守把某种编译特征当成壳。解决以 DIE 的熵值分析和区块表数据为准。如果在区块表里找不到任何壳特征对应的区块大概率是误报。反过来DIE 报了壳而 VT 上没有人报通常只是这个壳比较冷门许多引擎不收录它的特征不代表 DIE 错——这时用十六进制视图人工核实入口点代码就能定论。6. 末级技巧用 DIE 验壳结果反推加壳方式把“查壳”变成“定位工具”查壳这个动作很多人拿到结果就结束了但其实检测结果里藏着加壳方式的密码。以 UPX 为例DIE 报出的版本号区间直接决定了能否用 upx -d 一键脱壳UPX 3.x 的压缩结构相对稳定脱壳成功率极高UPX 4.x 改了部分头部的布局老的脱壳机容易失败。DIE 的检测结果里如果版本号后面带着“(.upx0)”这种区块标记就能确认壳的加壳布局手动脱壳时可以直接定位原始入口点位于 .text 段还是其他自定义段。验证这个判断的最快路径是在 DIE 拿到壳版本后打开十六进制视图看两个位置的值文件偏移 0x3C 处的 PE 头偏移以及 PE 头偏移 0x28 处的入口点 RVA。对标准 UPX 壳入口点 RVA 几乎总是指向最后一个节区头部附近如果这里的值和节表里的 VirtualSize 关系异常说明加壳器重写了入口点字段脱壳时要多做一步 ——把入口点改成第一个节区通常是 .text 或 .UPX0的真实代码地址。另一个实用技巧是把 DIE 作为“加壳方式分类器”来用同一个加壳器家族的多个版本在区块命名习惯、入口点指令模式、节表属性上有很强的共性。你可以在 DIE 的脚本引擎里按这些共性写一条批量规则配合它的命令行模式扫一个目录里的所有文件输出为 CSV——一小时内就能完成一个样本集的加壳方式统计。实际用法是把 DIE 的可执行文件路径和待扫描目录传给命令行接口输出文件里会包含每个文件的检测名称、版本号和置信度拿这个做样本归类报告比手动一个个看快一个数量级。我这套“先 DIE 查壳 - 看十六进制验证熵值特征 - 必要时写脚本固化规则”的流程在近半年的样本分析里基本没有翻过车。期间有一个印象深刻的教训一次分析一个加了多层壳的样本我图省事只看了 DIE 的表面检测结果就下了结论是 VMProtect结果脱壳阶段发现内层还有一个 Themida——要从那以后我每次都强制走一遍“查验结果 - 验证区块表与入口点 - 结合熵值确认”的闭环宁可慢两分钟也不愿再看一次表面结果。希望这条习惯能帮到你少踩一个半隐藏的坑。本文还有配套的精品资源点击获取
