Detect-It-Easy 快速上手：3 步完成从文件识别到加壳检测的完整工作流

【免费下载链接】Detect-It-EasyProgram for determining types of files for Windows, Linux and MacOS.项目地址: https://gitcode.com/gh_mirrors/de/Detect-It-Easy

Detect-It-Easy（DiE）是一款跨平台的文件识别与静态分析工具，覆盖 PE、ELF、APK、IPA、DEX、JAR、ISO9660、Mach-O 等 15 种以上格式，并能进一步报出文件的编译器、链接器、加壳器和混淆方案。它最适合经常接触未知二进制的人：逆向、恶意软件分诊、安全审计场景下，手上一份可疑样本，需要三秒内回答"这是什么、被谁加工过"，它就是第一件要拿出来的工具。

🚀 跑起来：一条 diec 命令拿到第一个有效结果

DiE 提供三个入口：die图形界面、diec命令行、diel轻量 GUI。命令行最适合验证和自动化，安装也最省事：Windows 上 chocolatey 有die包，Arch Linux 的 AUR 有detect-it-easy-git，Linux 环境下也可以不装任何东西，直接在容器里跑仓库自带的docker/diec.sh [文件名]。

装好之后先跑一次深度扫描。下面的-r开启递归扫描，-d开启深度扫描，这条命令就是对单个文件做一次彻底检查：

diec -rd sample.exe

如果样本是一个用 MinGW 编译、被 ASPack 加壳的程序，输出就是四行：PE32 格式、Packer: ASPack(2.12-2.42)、Compiler: MinGW、Linker: GNU linker ld。类型、壳、编译器一次给齐，这就是"第一个有效结果"。

常用选项都在diec -h里，值得记住的几个：-u开启发式扫描（长参数--heuristicscan），-e输出熵值，-i输出文件信息，-S "Hash"附加哈希，-j输出 JSON。批量场景最常用的组合是递归加 JSON：

diec -r -j /path/to/samples/ > report.json

扫描结果直接落成 JSON，方便接进自己的报告或研判流水线。

🔍 看明白：签名 + 启发式双引擎怎么协同

跑通了，下一个问题是：DiE 凭什么报出这些结果？核心是两层机制在协同。

第一层是签名数据库。db/目录按格式组织，db/PE/下有 900 多个.sg文件，db/MSDOS/有 300 多个。每个.sg其实是一个 DiE-JS 脚本模块：用meta("packer", "UPX")声明自己识别什么，然后在detect()里做条件判断——字节模式、节区名、导入表对上就置bDetected = true。字节模式是一门小语言：十六进制按字面匹配，??是通配符，文本用单引号包裹，$处理相对跳转，完整语法在help/Signatures.md。这一层快、精确，每条命中都是明确的规则匹配。

第二层是启发式引擎。PE 方向上它是 DosX 维护的完整分析引擎，纯静态工作：文件不落地运行，引擎遍历文件头、数据目录、节区、导入导出、资源、.NET 元数据和入口点可达代码，检查反分析、解包器特征、自修改代码等异常。它和签名层的关键区别：

最后一行很关键。启发式结果永远不会和签名结果混在一起，特定情况下它会推翻误导性的签名——比如编译器签名指向 C/C++，而结构和运行时证据指向 Rust，最终输出就是(Heur) Language: Rust。启用后它作为独立的高层分析运行，配合-b（verbose）加-u可以看到最完整的证据链。

上图里 "Protector: .NET Reactor" 是签名命中，红色(Heur)行是启发式推断的混淆、反分析、打包器特征，且每条都带证据说明。GUI 里还能同时跑多套独立引擎：DiE 本体、Nauz File Detector（NFD）、YARA，以及经典老工具 PEiD（规则库在peid_rules/）。它们的输出是互补关系——三个引擎同时命中一条弱签名，也不会变成证明。

🛠️ 玩出花：三个进阶玩法

写一条 DiE-JS 规则抓自己的目标

场景：你发现某个私有加壳工具主签名库里没有，它产出的文件都带一个叫upxd的节区。DiE 签名系统完全开放，不用动主库，把规则文件放进自定义规则目录db_custom/即可。最小规则就几行：

meta("packer", "MyPacker"); function detect() { if (PE.isSectionNamePresent("upxd")) { sVersion = "1.0"; bDetected = true; } return result(); }

你会看到：下次扫描该文件时，结果里多出一条 MyPacker (1.0) 的记录。结果字段由引擎提供，不能重复声明：bDetected标记命中，sVersion/sOptions填版本和限定词，sLang附加语言结论。动手前先读help/Global.md的全局函数和你目标格式对应的 API 文档（比如help/PE.md），再看help/Signatures.md的模式参考——字节模式不是正则表达式，别拿正则的习惯去写。

YARA 规则直接挂进来扫

场景：你手里有一套恶意家族的 YARA 规则，想和 DiE 扫描一起跑。yara_rules/目录是默认规则库，DiE 自带DiE_BasicHeuristics_by_DosX.yar、DiE_EnhancedHeuristics_by_DosX.yar等几套规则做交叉验证；把自己的.yar放进来或在 GUI 的 YARA 标签页加载，文本、字节、逻辑条件都支持。GUI 里还有独立的 Signature 搜索窗口：输入字节模式点 Scan，返回所有匹配偏移和地址，适合快速验证一条新规则在样本上的落点。

多窗口 GUI 里深挖结构

场景：命令行说"有壳"，你想亲眼看一遍确认。用die图形界面打开同一个文件，是一组多面板视图：Visualization 把节区熵值画成热力图，高熵的压缩或加密节区一眼就能看出来；Strings 按编码和最小长度过滤提取字符串，找 C2 域名、硬编码配置最常用；Hex、Disasm、Import、Memory map 各自独立成窗口，互不干扰。热力图 + 字符串 + 导入表这个组合，是恶意软件分诊里出活最快的三板斧。

⚠️ 排雷与取舍

几个容易踩的坑先说清楚：

• 别手改dbs_min/：那是生成产物，规则要改就改db/或db_custom/再重新生成。db_extra/里是没被批准进主库的规则，官方明确不建议拿它当质量参考，抄规则时绕开。
• 启发式结果不是杀毒判定：DiE 不是杀毒软件，"没报警"只代表"启用的规则没找到它认识的静态证据"。启发式结论是线索，不是恶意证明，动态分析和信誉服务回答的是别的问题。
• 性能上有取舍：启发式扫描是独立的一组分析通道，大目录批量扫的时候按需开-u，别默认全开；写规则时先用廉价的结构条件做门槛，再做昂贵的字节搜索——这是社区 review 时的硬性性能要求。
• 多条弱命中不等于强证据：多个引擎同时报一条弱签名，只是多个弱证据，GUI 里对这一点也明确提示。

和同类工具放一起看：

顺带一提，DiE 本身就内置了经典 PEiD 引擎（peid_rules/），但把它当第二证据用——老数据库里噪声签名不少。什么情况下它不是最优选择？需要动态行为、沙箱 detonation 或杀毒式判定，DiE 干不了；只是算个哈希或查哈希，任何哈希工具都比它快。

下一步建议

拿一份你手上的真实样本，先跑diec -rd确认壳和编译器，然后翻help/PE.md找一个 API，在db_custom/里写出你的第一条规则——CONTRIBUTING.md里对规则和性能的完整要求，正好是这次练习的标准答案。

【免费下载链接】Detect-It-EasyProgram for determining types of files for Windows, Linux and MacOS.项目地址: https://gitcode.com/gh_mirrors/de/Detect-It-Easy