简介：DIE（Detect It Easy）是一款专业查壳工具，主要面向安全分析、逆向工程与恶意代码检测场景，可快速识别程序加壳类型、编译语言及打包器特征，并支持超大文件读取，相比PEID在复杂程序检测上更具优势。资源包共收录1362个文件，以sg签名库、html说明文档、dll动态库和exe主程序为主，还包含qm语言包、qss样式文件以及zip/rar等压缩样本，整体仅13.55MB，轻巧便携且目录结构清晰，便于按需查阅。该工具绿色免费，无需安装，支持文件拖放、右键菜单、多国语言（含简体中文）和多种皮肤，可跨Windows、Mac、Linux平台使用；同时支持自定义插件、脚本编写与16进制编辑，方便安全人员按需定制检测逻辑，适配不同分析需求。目前已有4145人学习下载，适合安全工程师、CTF玩家以及软件分析爱好者将其作为日常查壳与分析的主力工具。
1. 查壳工具DIE：一次查到底，比PEID更值得装进工具箱
做逆向和样本分析的人，几乎都遇到过这种场面：拿到一个不明程序，习惯性点开PEID，结果要么扫不出任何信息，要么报一个含糊其辞的“Microsoft Visual C++”，换DIE一拖进去，壳名、编译器、区段信息直接列得明明白白。这不是说PEID不行，而是签名库太老，对新壳和变种几乎失明。DIE（Detect It Easy）强就强在它同时用签名匹配和内容特征去判断，能一次查到底，甚至PEID读不了的大文件它也能正常打开。这个工具适合三类人：做样本分析的、搞逆向调试的，以及平时需要快速判断一个程序有没有被加壳的运维和开发。
它最直观的优势就是绿色免安装、支持文件拖放、自带简体中文，还内置了十六进制编辑器，一套下来基本够用。下面从实际使用的角度，把DIE的界面操作、命令行批处理、常见误报和插件扩展一次性讲清楚。
2. DIE核心用法：拖放扫描、右侧信息区与三种扫描策略
2.1 界面启动与多语言切换：第一次打开先做这三件事
解压出来的DIE是一个可执行文件，双击就能跑，不需要安装环境，也不写注册表。我第一次用的时候直接拖了个样本进去，界面响应很快，但默认界面是英文的，对习惯中文提示的人不算友好。设置方法是打开主界面后，进入Options菜单，找到Language子菜单，选Chinese，界面就会切换成简体中文，这个切换是即时生效的。
建议拿到手先做三件小事：第一，确认版本号，老版本的签名库对这两年新出现的壳识别率差很多；第二，在设置里开启“附加信息”显示，这样右侧会额外列出入口点、文件偏移、区段数量这些逆向常用的关键数据；第三，把“加载时自动检查更新”打开，DIE的签名库更新频率不算高，但每次更新都能补上一批新壳特征。
2.2 三种扫描策略：快速、深度和启发式分别什么时候用
DIE的扫描策略是进入工具后最需要先搞明白的部分，它直接决定你点击扫描按钮后要等多久、结果准不准。很多人拿到手直接点扫描，结果发现某些文件卡了很久，其实是没有按文件性质选择正确的扫描模式。主界面左侧选择文件后，右侧会显示“扫描”按钮，旁边就是模式选择下拉框，默认是快速扫描。
快速扫描只匹配已知签名库的头部特征，通常一两秒就能出结果，适合大部分常规样本；深度扫描会把整个文件按区段逐个做特征匹配，速度慢很多，但能识别出修改过头部特征、把壳的特征藏在文件中部的混淆样本；启发式扫描不是靠已知特征，而是根据文件的熵值和结构做猜测，适合快速扫描和深度扫描都查不出结果的新壳或未知壳。
三种模式我最常用的组合是先跑一遍快速扫描，如果结果里没有任何加壳提示、但文件体积和功能明显不符，再切深度扫描确认，最后才上启发式。直接从深度扫描开始是最浪费时间的方式。
| 扫描策略 | 耗时 | 误报率 | 适用场景 |
|---|---|---|---|
| 快速扫描 | 秒级 | 低 | 常规PE、ELF文件识别 |
| 深度扫描 | 数秒到数十秒 | 中 | 修改过文件头的样本 |
| 启发式扫描 | 视文件大小而定 | 最高 | 新壳、未知壳、加密保护 |
补充一个经验：对大文件做深度扫描时如果长时间没反应，先别急着关进程，DIE的状态栏会显示当前正在扫描的区段偏移量，等偏移量走到文件末尾说明快完成了。如果连状态栏都卡住，才考虑是文件本身有问题。
2.3 右侧信息区怎么读：编译器、加壳器、打包器和保护器的判定逻辑
DIE识别出一个文件后，右侧信息区从上到下依次会显示文件类型、检测结果、编译器/加壳器提示、入口点、区段表和熵值。这里最容易被误读的是“检测结果”和“编译器/加壳器”两行，它们的含义完全不同。
检测结果那一行如果显示“UPX”，说明确认识别出了壳；如果显示“Microsoft Visual C++”，这通常是编译器的信息，不是加壳器。很多人看到DIE显示VC++就以为文件没加壳，这是不对的，很多壳加的其实就是编译器的特征字段。判断有没有加壳，重点看两个地方：一是检测结果里有没有出现壳名、打包器名或保护器名；二是区段表里有没有出现UPX0、UPX1、.aspack、.packman这种典型壳区段名。正常编译出来的程序，区段名一般是.text、.data、.rdata。
DIE还能识别非PE格式的文件。输入的项目资料里提到它能处理ACE archive、ARJ这类压缩存档以及Borland编译器的产物，这在分析老程序时很实用。老版本Borland Delphi编译出的程序在PEID里经常被误报成未知或者干脆不识别，DIE能准确列出是Borland系编译器，对定位加壳逻辑有很大帮助。另外，DIE对ELF和Mach-O格式也做了支持，虽然日常用得少，但做跨平台样本分析时不用再切工具。
3. 命令行与批处理：用diec把查壳变成流水线
3.1 diec参数拆解：从图形界面到命令行的关键一步
DIE自带命令行工具diec，路径一般在安装目录或解压目录下的diec.exe（Windows）或diec（Linux/macOS）。图形界面适合单文件检查，批量扫描几百个文件时还是命令行高效得多。diec的核心参数不多，但组合起来能完成很完整的自动化扫描流程。
# 基本用法：扫描单个文件并输出简洁结果 diec -d sample.exe # 深度扫描并输出JSON格式结果 diec -d -j sample.exe # 递归扫描目录下所有文件 diec -d -r ./samples/ # 只显示检测到的壳或编译器信息，节省输出量 diec -d -s sample.exe-d表示深度扫描，-j输出JSON格式方便脚本解析，-r递归扫描目录，-s只显示检测结果。单独跑diec不加参数会打印完整帮助信息，里面有全部可用参数，建议先看一遍再写批处理。
JSON格式是自动化场景里最常用的输出格式，字段含义稳定，省去解析字符串的麻烦。输出内容包括检测到的壳名、编译器信息、格式类型和熵值，字段命名和图形界面的展示是对应的。
3.2 Windows批处理批量扫描：把结果汇总到文本文件
实际做样本收集时，经常拿到一个文件夹下有几百个待检查的程序，手动拖进图形界面不现实。我一般会在Windows下写一个批处理脚本，把结果统一输出到一个文本文件里。
@echo off setlocal enabledelayedexpansion set "TARGET_DIR=D:\samples" set "OUTPUT=scan_result.txt" if exist "%OUTPUT%" del "%OUTPUT%" for /r "%TARGET_DIR%" %%f in (*.exe *.dll *.sys) do ( echo [FILE] %%f >> "%OUTPUT%" diec.exe -d -s "%%f" >> "%OUTPUT%" 2>&1 echo. >> "%OUTPUT%" ) echo Scan complete. pause这段脚本的逻辑很简单：用for /r递归遍历目标目录，匹配exe、dll、sys三类常见可执行文件，逐个调用diec进行深度扫描，把文件路径和扫描结果顺序写入同一个文本文件。加了enabledelayedexpansion是防止文件名包含特殊字符时变量展开出错，这是个容易被忽略的细节。
2>&1把错误输出也重定向到同一个文件，这样diec因为文件损坏或其他原因报错时也能在结果里看到，不会静默丢失信息。小文件多的目录跑起来很快，大文件建议先做一次快速扫描筛掉普通的，再单独对剩余文件做深度扫描。
3.3 Linux下的批量结果整合：用退出码做快速分类
diec在Linux下的用法和Windows基本一致，如果你在收集跨平台的可执行文件样本，可以在Linux下用一个简单的bash脚本把扫描结果按“检测到壳”和“未检测到壳”分开存放。
#!/bin/bash SCAN_DIR="$1" OUT_OK="clean_list.txt" OUT_PACKED="packed_list.txt" : > "$OUT_OK" : > "$OUT_PACKED" while IFS= read -r -d '' f; do if diec -s "$f" | grep -qiE "UPX|ASPack|MPRESS"; then echo "$f" >> "$OUT_PACKED" else echo "$f" >> "$OUT_OK" fi done < <(find "$SCAN_DIR" -type f -name "*.exe" -print0)这段脚本用find -print0配合while read -d ''逐行读取文件路径，避免文件名带空格时被错误拆分。每条路径交给diec扫描，然后通过grep匹配已知壳名关键字，命中就归入packed_list.txt，否则归入clean_list.txt。这样一趟跑下来，几百个样本的分类结果一目了然，再用图形界面单独查带壳的即可。
脚本里的grep关键字可以根据实际样本特征补充扩展，比如加VMProtect、Themida。注意改用grep区分大小写，因为不同壳的输出格式里大小写规则不一致。
3.4 diec返回码：脚本判断壳有无的另一个入口
diec执行结束后会返回一个数字，这个返回码在写自动化脚本时很关键。返回码0通常表示没有检测到已知壳信息；1表示检测到加壳或保护特征；8一般代表文件读取失败或格式无法识别。不同版本可能在具体值上有差异，建议在脚本里先跑一次echo $?确认返回码。
我一般这样用返回码：先跑快速扫描拿返回码，为0的文件直接归入未加壳集合，为1的再做深度扫描确认具体壳类型，为8的单独列出来人工检查。这样分三级过滤，能大幅减少深度扫描的文件数量，处理大批量文件时省不少时间。
diec -s target.exe > /dev/null 2>&1 case $? in 0) echo "clean" ;; 1) echo "packed: $(diec -s target.exe)" ;; 8) echo "unreadable or unknown format" ;; esac这段代码用case语句封装了返回码的三种分支处理逻辑，awk或sed解析JSON输出可以拿到更详细的字段。需要注意返回码含义在不同系统上可能有细微差异，换环境后先跑几个已知文件验证一下是值得的。
4. 避坑与常见问题：误报、假壳与死等六条实战记录
4.1 大文件扫描卡到“假死”
现象是拖入一个数百MB的文件后，DIE界面卡住，鼠标转圈或状态栏长时间不动。原因是DIE默认对文件做深度扫描时，会逐区段读取并计算特征，大文件意味着更多的区段和更大的计算量，而界面上没有明显的进度百分比，看起来就像死掉了。解决方法是先等10到15秒，看状态栏有没有偏移量变化；没有变化再切换成快速扫描模式，快速模式对大文件基本是瞬间完成的；如果必须要深度扫描结果，用命令行diec -d跑，退出码和输出结果会更可控。
4.2 壳名识别成编译器名，被误判为“无壳无保护”
现象是一个文件在DIE里显示“Microsoft Visual C++”就认为没加壳，但运行后发现行为异常。原因是用DIE查壳时没有区分“编译器信息”和“加壳器信息”两个独立概念的差异，不少壳会伪造编译器字段干扰判断。解决方法是不要只看进程名，重点确认右侧检测结果里有没有壳名；再看区段表里有没有UPX0、.aspack这类特征区段；最后用工具的内存加载后的区段对比功能复核，运行前后区段差异大基本说明存在加壳或自解密逻辑。
4.3 启发式扫描误报，普通程序被判成“加壳保护”
现象是一个自己用Visual Studio正常编译的exe，用启发式扫描被提示“可能被加壳”，换快速扫描却一切正常。原因是快速扫描模式拿出的结论本身更可靠，它是基于准确的签名匹配；而启发式是基于熵值、结构做一些概率猜测。高熵区段不一定就是壳，正常运行程序的代码区段也可能有较高熵值。解决方法是先用快速扫描验证，快速扫描结果干净就以快速扫描为准；如果只靠启发式疑似，就把文件丢进沙箱跑一遍，对比入口点和内存特征。
4.4 DIE只扫了第一个区段就出结果，漏掉中后部夹带的壳
现象是快速扫描显示无壳，但实际运行起来有内存修改行为，用深度扫描才能查到检测结果。原因是快速扫描模式默认只匹配文件头部和少量关键偏移处的特征，部分混淆壳会把特征字段写在文件偏移较深处，快速扫描根本碰不到那个位置。解决方法是对于可疑文件一律做深度扫描，同时用-j参数输出JSON结果后用文本搜索关键字；文件体积不大但运行特征明显可疑的，直接上十六进制手工看。
4.5 拖放文件没反应，界面无任何输出
现象是把.exe文件拖进DIE窗口，界面没有任何变化。原因一般是权限问题加拖放源程序以管理员身份运行的情况，比如DIE窗口权限级别低于拖放源进程，文件句柄无法正常传入。解决方法是直接通过文件 -> 打开手动选择路径，或者用命令行传参打开目标。平时用命令行跑批量扫描，基本用不上拖放功能。
4.6 同一文件两次扫描结果不一致，怀疑是DIE的问题
现象是同一个文件先跑一次快速扫描显示“Nothing found”，再跑一次深度扫描却显示有壳。原因不是DIE抽风，而是快速和深度两种模式下读取文件内容的范围和特征匹配策略不同，结果不一定是冲突，而是覆盖了不同层次的信息。解决方法是把深度扫描结果作为准确结果，快速扫描结果仅作初筛；如果深度扫描拿到的结果还是不确定，再用Peid或在线查壳平台交叉验证一次。
5. 进阶用法：自己写查壳规则，把DIE从查壳器变成验壳器
DIE的查壳逻辑本身是脚本化的，它的特征签名目录下放了一堆可以用文本编辑器直接改写的规则文件，这些文件规定了每个壳的特征字节、偏移位置和判定条件。找到安装目录下的db文件夹，里面能看到很多以壳命名的json或db文件，打开后你会发现它们本身是一段结构清晰的文本描述。
{ "name": "MyCustomProtoct", "type": "PE", "pattern": "55 8B EC 83 EC ?? E9 ?? ?? ?? ??", "offset": "ep", "entropy": "0.7 - 1.0" }name是自定义壳名；type指定文件格式（PE/ELF/Mach-O）；pattern是十六进制特征字节序列，??表示模糊匹配；offset填ep就表示从入口点开始匹配，也可以填具体的文件偏移；entropy是可选字段，用于按熵值辅助过滤误报。保存后回到DIE界面对该文件重新扫描，就能在结果里看到自定义壳名而不是“未知”。
这个能力的价值在于，你可以对内部的私有壳做定向识别。之前接触过一个加了自定义壳的老程序，DIE和PEID都查不出具体名字，后来我在db目录里建了一个规则文件，把从入口点偏移处截到的特征字节填进去，从此同源样本一拖进DIE就秒识别。建议把这个规则文件单独复制一份备份，DIE更新签名库时不会覆盖你自己加的文件。
十六进制编辑器在这种场景下也顺手：用DIE内置的十六进制查看器定位到入口点附近，把特征字节直接复制到规则文件里，省去单独开一个Hex编辑器来回切换的过程。整个过程不需要写代码，但能把DIE从“识别已知壳”升级成“识别你自己想识别的壳”，实用性提升一大截。
另外建议每新增一条规则后，用几个已知加壳样本验证一下会不会被误匹配，规则的特征字节不要太短，至少4到6个字节起步，否则很容易把普通程序也测出壳来。我在项目里加过一条只有2字节的规则，结果一批正常编译的程序全被误报成加壳，排查了一下午才发现是特征太短导致的。从那以后我每次写完规则都强制用干净的exe和带壳的exe各跑一遍，确认无误才会纳入正式使用。希望这两条经验能帮你少走点弯路，工具链本身并不复杂，关键是把它用在自己实际场景里。
本文还有配套的精品资源，点击获取
