企业官网建设流程全解析

Detect-It-Easy 文件类型识别完全指南：从 diec 命令到加壳识别实战

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

拿到一个来路不明的 .exe，或一份"扩展名很可疑"的交付文件，你通常想知道三件事：它到底是什么类型、谁编译的、有没有被加壳。Detect-It-Easy（DiE）就是干这个的：一个跨 Windows / Linux / macOS 的文件检测工具，从文件头、签名数据库和启发式推断三个角度给出文件类型识别结果，全程不用运行文件、不用开沙箱。下面从装到能用讲起，再讲原理、批量用法和多引擎协作。

一、📦 Detect-It-Easy 怎么安装？

DiE 有三种发行形态：die是完整图形界面，diec是命令行版（批量处理主力），diel是只保留扫描功能的轻量 GUI。Linux 上多数发行版（Kali、Parrot OS、Arch AUR 等）有现成包，包管理器里装完直接跑diec即可。没有现成包就用 Docker：

git clone --recursive https://gitcode.com/gh_mirrors/de/Detect-It-Easy cd Detect-It-Easy docker build . -t horsicq:diec

装好后的第一扫：

diec -rd malware_samples/

-r递归进子目录，-d深度扫描。几秒钟后你拿到的就是每个文件的类型、加壳器、编译器、链接器结论。

二、🔍 如何判断文件是否被加壳？

先看结果再谈方法。把文件拖进 die 界面，扫描区会直接给出这几行关键信息：

上图来自官方 README：一个 PE32 文件被标出Protector: .NET Reactor，下面三条红色条目（Obfuscation、Anti Analysis、Packer）是启发式层补充的判断，右侧还能看到 .NET 版本、节区数、时间戳。加壳判断看两个地方：精确签名命中（绿色条目，对应签名库里某条已知加壳器规则）和(Heur)标记的启发式结论（红色条目，来自综合证据推断，比如"入口点代码被改 + 高熵 + 节区命名异常"）。

命令行版结论一致，扫一个 ASPack 加壳样本：

$ diec -rd clear32.exe PE32 Packer: ASPack(2.12-2.42) Compiler: MinGW Linker: GNU linker ld (GNU Binutils)(2.28)[GUI32]

三行输出就回答了三件事：壳是谁、编译器是谁、链接器是谁。

三、🧠 DiE 是怎么识别文件的？签名和启发式分别在干嘛？

DiE 的识别分两层，理解这两层，你看结果时就不会被一堆条目绕晕。

第一层：签名匹配。仓库db/目录里按格式分了 30 多个子目录，共 4500 多条规则文件（.sg后缀），仅 PE 格式就有 909 条。每条规则是一个 JavaScript 片段，用 DiE 自己的字节签名语法做匹配：十六进制字节按字面值比较，??匹配任意单字节，'SQLite format 3'这种单引号写法直接匹配文本，$$$$$$$$匹配带 4 字节跳转距离的指令。完整语法见 签名规则说明。签名库本质就是"这个字节模式 = 这个东西"的对照表，命中即精确。

第二层：启发式分析。启发式是不依赖固定签名的判断方法：文件被改过、签名失效时，引擎综合多个维度的证据来推断——入口点附近的指令流、节区权限与命名、导入导出表、资源、熵值（字节的随机程度，0~8，超过 7.5 通常意味着压缩或加密内容）、.NET 元数据、版本信息、反调试痕迹。4.0.0 版本专门引入了 DosX 维护的 PE 启发式引擎，README 明确列出它检查的反分析、多态壳、.NET 混淆等方向，并给每条结论附上证据链。所以你在输出里看到的(Heur) Packer: Generic [Pushal at EP + High entropy + ...]不是拍脑袋，括号里就是它凭什么这么判断。

这两层始终分开显示：精确命中和启发式推断不会混成一行，看到(Heur)就知道这条是推断出来的。

四、⌨️ diec 命令行常用参数

批量场景全靠 diec。下面是常用参数速查（完整列表直接跑diec --help）：

一个典型自动化流程：diec -rj samples/ | jq ...把整个样本目录的扫描结果落成 JSON，后续筛选加壳文件、按编译器归类都能用脚本完成。

五、🔬 DiE 内置了哪些检测引擎？怎么一起用？

GUI 版把四个独立引擎收进同一个界面：DiE 本体、Nauz File Detector（NFD）、YARA、PEiD。它们规则模型各不相同，输出是互补的——README 的原话是"三个引擎重复一条弱签名，也不会变成证据"。遇到难判断的文件，逐个引擎跑一遍，往往能补出单引擎漏掉的信息，比如 PEiD 的历史规则库对老加壳器仍然有效。仓库yara_rules/目录自带 DiE 编写的基础版和增强版 YARA 启发式规则，可以配合yara_rules/peid.yar等文件使用。

上图是同一个文件的多视图状态：左侧导航列出全部引擎和 Hex / Disasm / Strings / Memory map / Entropy 等面板，底部 Visualization 面板用颜色块画出文件各区域的熵值分布——哪段被压缩、哪段是明文，一眼可见。

六、🎯 三个典型使用场景

• 恶意样本初筛：diec -rd扫整个样本目录，批量标出加壳文件、高熵文件和已知壳，再决定哪几个值得进沙箱。
• 取证与供应链审计：对第三方交付的组件核对编译器、链接器、签名与构建信息，发现"自称 A 公司编译、实为 B 工具链"的异常；配合-i（文件信息）和-e（熵值）生成审计记录。
• 陌生文件排查：先看熵值（>7.5 基本是压缩/加密），再看签名与启发式是否指向可执行、压缩包或脚本。扩展名与真实类型不符时，DiE 会直接给出 PE 感知的文件名异常判断。

七、🛠️ 如何编写自定义检测规则？

DiE 的规则库完全开放，你自己也能加规则。先按格式选目录：PE 规则放db/PE/，ELF 放db/ELF/，真正与格式无关的才进db/Binary/。最小规则骨架长这样：

meta("compiler", "Example Compiler"); function detect() { if (PE.isSectionNamePresent(".lz-algo")) { sVersion = "1.0"; sOptions = "LZMA"; bDetected = true; } return result(); }

meta()声明规则类型和名字，detect()里用格式 API（如PE.isSectionNamePresent）做判断，命中就置bDetected = true，最后return result()交回结果。

规则库是怎么分层的？

• db/主库，规则经过审核；
• db_custom/个人规则目录，本地实验放这里；
• db_extra/未过审规则，官方明确不推荐当质量参考；
• dbs_min/自动生成的精简库，不要手改。

扫描时用-D指向你自己的库即可加载。提交规则前请先看 代码格式规范，PR 要求附可复现样本和误报说明。

收尾：DiE 能干什么、不能干什么

DiE 是静态初筛工具，不是杀毒软件——README 专门写了这一条。扫描干净不代表文件安全，启发式命中也不等于恶意实锤，它给的是证据：谁编译的、像不像原件、哪个壳在保护它、下一步该看哪里。这些判断帮你决定哪个文件值得深入、按什么顺序深入。

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