一次恶意样本分析事故让我重新认识了 Detect It Easy【免费下载链接】Detect-It-EasyProgram for determining types of files for Windows, Linux and MacOS.项目地址: https://gitcode.com/gh_mirrors/de/Detect-It-Easy去年秋天我在分析一个可疑的 Windows 可执行文件时卡了整整一下午。文件双击后行为异常但手头的老工具只告诉我这是 PE32既没有识别出加壳器也没提示任何保护特征。无奈之下只能手动翻十六进制、比对特征码效率极低。后来同事递给我一个叫Detect It Easy简称 DIE的工具一条命令不到两秒就给出了完整答案文件被 ASPack 2.12-2.42 加壳编译器是 MinGW链接器是 GNU Binutils 2.28。那一刻我意识到文件类型识别这件事选对工具比埋头苦干重要得多。Detect It Easy 是一款面向安全研究人员、逆向工程师和开发者的跨平台文件分析工具通过签名匹配与启发式分析双重机制识别文件类型、编译器、加壳保护等关键信息支持 Windows、Linux 和 macOS。如果你也遇到过工具识别不出来误报太多格式判断靠猜的困境这篇文章会用三个真实场景带你走一遍从安装到进阶的完整路径读完就能上手。场景一拿到一个来路不明的文件怎么快速定性先交代背景。文件分析的第一步永远是定性——它是可执行文件还是文档有没有被加壳是什么编译器生成的这一步决定你后续用哪套分析流程。1. 安装三条路径任选方式一Linux 发行版包管理器。Parrot OS 和 REMnux 等安全发行版内置了 DIEArch Linux 用户可用 AUR 包openSUSE 用户可通过 OBS 安装。装完直接执行diec命令即可。方式二从源码构建。官方在 docs/BUILD.md 给出了 Debian、Fedora、Arch、macOS、Windows 等全平台的构建说明。以 Ubuntu 为例核心是装好 Qt 依赖后执行# 安装 Qt5 相关依赖 sudo apt-get install qtbase5-dev qtscript5-dev qttools5-dev-tools libqt5svg5-dev -y # 递归克隆仓库 git clone --recursive https://gitcode.com/gh_mirrors/de/Detect-It-Easy cd Detect-It-Easy # 构建并安装 deb 包 bash -x build_dpkg.sh方式三Docker 容器。仓库自带 Dockerfile免去环境依赖烦恼git clone --recursive https://gitcode.com/gh_mirrors/de/Detect-It-Easy cd Detect-It-Easy docker build . -t horsicq:diec docker/diec.sh 你的目标文件2. 第一次跑通命令行三分钟出结果装好后打开终端用官方提供的加壳样本clear32.exe试试手官方 docs/5.png 截图演示了完整过程# -r 递归扫描-d 深度扫描直接传入文件路径 diec -rd clear32.exe预期输出PE32 Packer: ASPack(2.12-2.42)[-] Compiler: MinGW(-)[-] Linker: GNU linker ld (GNU Binutils)(2.28)[GUI32]三行结果包含的信息量远超预期文件是 32 位 PE 格式、被 ASPack 2.12-2.42 加壳、编译自 MinGW、链接器版本 2.28。有了这些后续脱壳和逆向就有了明确方向。整个扫描过程不到两秒。3. GUI 模式适合深度阅读分析结果如果你更习惯图形界面仓库提供了三个版本die完整 GUI、diec命令行、diel轻量 GUI仅扫描。启动die后把文件拖进窗口即可界面分三块顶部信息栏文件类型、大小、入口点、基址中间功能面板PE 结构、内存映射、反汇编、十六进制、字符串、哈希、熵值等 20 多个子视图底部检测结果区签名检测与启发式分析的结论汇总比如分析一个 .NET 程序时GUI 会直接标出Protector: .NET Reactor(6.X)并在启发式结果里列出 Anti-tamper、Anti-ILASM、虚拟化等保护特征。这些信息在命令行里也能拿到但 GUI 的视觉呈现更适合逐条核对。场景二批量扫描一个目录怎么不重不漏单文件分析只是入门。现实中的安全审计往往面对成百上千个文件——一次应急响应、一次恶意样本集筛查都需要批量处理。这时候就要靠diec的参数组合。关键参数速查参数全称作用-r--recursivescan递归扫描目录下所有文件-d--deepscan深度扫描识别更多加壳/保护特征-j--json输出 JSON 格式方便程序解析-x--xml输出 XML 格式-c--csv输出 CSV 格式方便表格处理-e--entropy显示文件熵值快速发现加密/压缩数据-D--database指定自定义签名数据库路径-S--special提取特殊信息如-S Hash计算哈希实战批量扫描并汇总报告假设你要审计/opt/samples/下的 500 个可疑文件一条命令就能产出结构化报告# 递归扫描目录深度检测输出 CSV 便于后续分析 diec -rd /opt/samples/ analysis_report.csv预期输出CSV 前几行File,Type,Detect /opt/samples/001.exe,PE32,Packer: UPX(3.96)[-] /opt/samples/002.bin,ELF64,Compiler: GCC(9.4)[-] /opt/samples/003.apk,APK,Protector: TencentLegU[-]配合-j输出 JSON还能把结果直接喂给 Python 脚本做自动化筛选——比如找出所有被 UPX 加壳的样本统一进入脱壳流程。这也是 DIE 能嵌入安全分析流水线的原因。命令行帮助随时可查记不住参数没关系diec -h会打印完整帮助官方 docs/4.png 截图展示了具体界面。-h配合-v版本信息就能快速确认环境是否正常。场景三工具认不出的文件自己写规则扩展它这是 DIE 区别于普通格式识别器的核心——它的签名库不是写死的而是由脚本驱动用户可以自己扩展。签名数据库位于仓库的 db/ 目录按格式分类存放比如 db/PE/ 下有 800 多个检测脚本db/ELF/ 有 46 个。签名规则是怎么工作的DIE 的签名本质上是十六进制字节模式支持通配符和文本匹配。以 ELF 检测为例见官方 help/Signatures.md// 匹配 ELF 魔数 7F ELF if (Binary.compare(7FELF)) { sName ELF executable; // 根据第 4 个字节区分 32/64 位 switch (Binary.readByte(4)) { case 1: sOptions 32-bit; break; case 2: sOptions 64-bit; break; } }规则语法直观??表示任意单字节$$匹配相对跳转单引号括起来的是 ASCII 文本。你甚至可以直接在 help/Signatures.md 里找到 JPEG、RAR、PNG、SQLite 等几十种格式的现成范例。实战给自家内部格式写一个检测规则假设你们公司有个私有存档格式魔数是0x58 0x21 0xA7。新建文件db/Binary/format_MyCompanyArchive.1.sg写入// 自定义签名MyCompany 私有存档格式 if (Binary.compare(58 21 A7)) { sName MyCompany Archive; sVersion 1.0; _setResult(Archive, sName, sVersion, Internal format); }保存后重新运行扫描DIE 就会像识别 ZIP、RAR 一样识别出你的私有格式。配合-D参数还可以把第三方规则集挂载进来不污染官方数据库。启发式分析签名覆盖不到的部分签名匹配不了未知威胁但 DIE 的启发式模块会分析熵值、入口点特征、节区属性等给出疑似加壳疑似混淆的提示。这就是图 1 中Protector和Heuristic Protection并列出多条结果的原理。签名负责精确启发式负责兜底两者结合把误报率压到很低。我踩过的三个坑提前帮你避开第一次用 DIE 时我在三个地方栽过跟头写出来供你参考。坑一扫描目录时忘了加-r。diec /path/to/dir只会扫描目录本身不会递归子目录。批量审计时漏掉嵌套目录里的文件结果报告残缺不全。记住目录扫描必带-r。坑二把diec输出当最终结论。DIE 给出Compiler: MinGW并不意味着程序一定由 MinGW 编译——它可能只是匹配了特征字节。加壳和编译器信息是强线索但最终判断要结合反汇编和动态分析交叉验证。坑三误以为签名越多越准。自定义规则写得过于宽泛比如只用 2 字节魔数会大幅增加误报。我在 help/Signatures.md 里学到的最佳实践是至少用 4 字节以上特征配合上下文偏移。比如匹配 PE 文件时用4D5A........PE0000比单纯4D5A靠谱得多。常见问题速查问题答案检测结果不准确怎么办更新签名数据库用-d深度扫描检查自定义规则是否过宽命令行和 GUI 版本如何选批量处理用diec深度阅读结构用die轻量扫描用diel支持哪些文件格式PE、ELF、Mach-O、APK、IPA、JAR、DEX、ZIP、ISO9660 等十余类未识别格式走启发式分析如何导入第三方规则用-D /path/to/db指定自定义数据库目录分析大文件很慢大文件优先用 CLI 并关掉不必要的面板GUI 里可调整扫描范围需要计算文件哈希diec -S Hash 目标文件一步到位下一步动手验证这四件事工具是练出来的。建议你按下面顺序实践每步都能在几分钟内完成跑通最小流程找个 PE 或 ELF 文件执行diec 文件路径对照本文结果核对输出格式。批量扫描自己下载的软件包目录用diec -rd加-j看看有没有意外发现加壳或加密特征。为一种你知道魔数的私有格式写签名规则参照 help/Signatures.md 里的范例放进 db/ 后重启验证。把diec集成进你的分析脚本用 JSON 输出做自动化筛选例如自动标记所有 UPX 加壳样本。DIE 的价值不在于一次识别多准确而在于它把文件定性这件脏活变得可复制、可扩展。希望这篇教程能帮你少走我走过的弯路——现在就去跑第一条命令吧。【免费下载链接】Detect-It-EasyProgram for determining types of files for Windows, Linux and MacOS.项目地址: https://gitcode.com/gh_mirrors/de/Detect-It-Easy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 一次恶意样本分析事故，让我重新认识了 Detect It Easy
一次恶意样本分析事故让我重新认识了 Detect It Easy【免费下载链接】Detect-It-EasyProgram for determining types of files for Windows, Linux and MacOS.项目地址: https://gitcode.com/gh_mirrors/de/Detect-It-Easy去年秋天我在分析一个可疑的 Windows 可执行文件时卡了整整一下午。文件双击后行为异常但手头的老工具只告诉我这是 PE32既没有识别出加壳器也没提示任何保护特征。无奈之下只能手动翻十六进制、比对特征码效率极低。后来同事递给我一个叫Detect It Easy简称 DIE的工具一条命令不到两秒就给出了完整答案文件被 ASPack 2.12-2.42 加壳编译器是 MinGW链接器是 GNU Binutils 2.28。那一刻我意识到文件类型识别这件事选对工具比埋头苦干重要得多。Detect It Easy 是一款面向安全研究人员、逆向工程师和开发者的跨平台文件分析工具通过签名匹配与启发式分析双重机制识别文件类型、编译器、加壳保护等关键信息支持 Windows、Linux 和 macOS。如果你也遇到过工具识别不出来误报太多格式判断靠猜的困境这篇文章会用三个真实场景带你走一遍从安装到进阶的完整路径读完就能上手。场景一拿到一个来路不明的文件怎么快速定性先交代背景。文件分析的第一步永远是定性——它是可执行文件还是文档有没有被加壳是什么编译器生成的这一步决定你后续用哪套分析流程。1. 安装三条路径任选方式一Linux 发行版包管理器。Parrot OS 和 REMnux 等安全发行版内置了 DIEArch Linux 用户可用 AUR 包openSUSE 用户可通过 OBS 安装。装完直接执行diec命令即可。方式二从源码构建。官方在 docs/BUILD.md 给出了 Debian、Fedora、Arch、macOS、Windows 等全平台的构建说明。以 Ubuntu 为例核心是装好 Qt 依赖后执行# 安装 Qt5 相关依赖 sudo apt-get install qtbase5-dev qtscript5-dev qttools5-dev-tools libqt5svg5-dev -y # 递归克隆仓库 git clone --recursive https://gitcode.com/gh_mirrors/de/Detect-It-Easy cd Detect-It-Easy # 构建并安装 deb 包 bash -x build_dpkg.sh方式三Docker 容器。仓库自带 Dockerfile免去环境依赖烦恼git clone --recursive https://gitcode.com/gh_mirrors/de/Detect-It-Easy cd Detect-It-Easy docker build . -t horsicq:diec docker/diec.sh 你的目标文件2. 第一次跑通命令行三分钟出结果装好后打开终端用官方提供的加壳样本clear32.exe试试手官方 docs/5.png 截图演示了完整过程# -r 递归扫描-d 深度扫描直接传入文件路径 diec -rd clear32.exe预期输出PE32 Packer: ASPack(2.12-2.42)[-] Compiler: MinGW(-)[-] Linker: GNU linker ld (GNU Binutils)(2.28)[GUI32]三行结果包含的信息量远超预期文件是 32 位 PE 格式、被 ASPack 2.12-2.42 加壳、编译自 MinGW、链接器版本 2.28。有了这些后续脱壳和逆向就有了明确方向。整个扫描过程不到两秒。3. GUI 模式适合深度阅读分析结果如果你更习惯图形界面仓库提供了三个版本die完整 GUI、diec命令行、diel轻量 GUI仅扫描。启动die后把文件拖进窗口即可界面分三块顶部信息栏文件类型、大小、入口点、基址中间功能面板PE 结构、内存映射、反汇编、十六进制、字符串、哈希、熵值等 20 多个子视图底部检测结果区签名检测与启发式分析的结论汇总比如分析一个 .NET 程序时GUI 会直接标出Protector: .NET Reactor(6.X)并在启发式结果里列出 Anti-tamper、Anti-ILASM、虚拟化等保护特征。这些信息在命令行里也能拿到但 GUI 的视觉呈现更适合逐条核对。场景二批量扫描一个目录怎么不重不漏单文件分析只是入门。现实中的安全审计往往面对成百上千个文件——一次应急响应、一次恶意样本集筛查都需要批量处理。这时候就要靠diec的参数组合。关键参数速查参数全称作用-r--recursivescan递归扫描目录下所有文件-d--deepscan深度扫描识别更多加壳/保护特征-j--json输出 JSON 格式方便程序解析-x--xml输出 XML 格式-c--csv输出 CSV 格式方便表格处理-e--entropy显示文件熵值快速发现加密/压缩数据-D--database指定自定义签名数据库路径-S--special提取特殊信息如-S Hash计算哈希实战批量扫描并汇总报告假设你要审计/opt/samples/下的 500 个可疑文件一条命令就能产出结构化报告# 递归扫描目录深度检测输出 CSV 便于后续分析 diec -rd /opt/samples/ analysis_report.csv预期输出CSV 前几行File,Type,Detect /opt/samples/001.exe,PE32,Packer: UPX(3.96)[-] /opt/samples/002.bin,ELF64,Compiler: GCC(9.4)[-] /opt/samples/003.apk,APK,Protector: TencentLegU[-]配合-j输出 JSON还能把结果直接喂给 Python 脚本做自动化筛选——比如找出所有被 UPX 加壳的样本统一进入脱壳流程。这也是 DIE 能嵌入安全分析流水线的原因。命令行帮助随时可查记不住参数没关系diec -h会打印完整帮助官方 docs/4.png 截图展示了具体界面。-h配合-v版本信息就能快速确认环境是否正常。场景三工具认不出的文件自己写规则扩展它这是 DIE 区别于普通格式识别器的核心——它的签名库不是写死的而是由脚本驱动用户可以自己扩展。签名数据库位于仓库的 db/ 目录按格式分类存放比如 db/PE/ 下有 800 多个检测脚本db/ELF/ 有 46 个。签名规则是怎么工作的DIE 的签名本质上是十六进制字节模式支持通配符和文本匹配。以 ELF 检测为例见官方 help/Signatures.md// 匹配 ELF 魔数 7F ELF if (Binary.compare(7FELF)) { sName ELF executable; // 根据第 4 个字节区分 32/64 位 switch (Binary.readByte(4)) { case 1: sOptions 32-bit; break; case 2: sOptions 64-bit; break; } }规则语法直观??表示任意单字节$$匹配相对跳转单引号括起来的是 ASCII 文本。你甚至可以直接在 help/Signatures.md 里找到 JPEG、RAR、PNG、SQLite 等几十种格式的现成范例。实战给自家内部格式写一个检测规则假设你们公司有个私有存档格式魔数是0x58 0x21 0xA7。新建文件db/Binary/format_MyCompanyArchive.1.sg写入// 自定义签名MyCompany 私有存档格式 if (Binary.compare(58 21 A7)) { sName MyCompany Archive; sVersion 1.0; _setResult(Archive, sName, sVersion, Internal format); }保存后重新运行扫描DIE 就会像识别 ZIP、RAR 一样识别出你的私有格式。配合-D参数还可以把第三方规则集挂载进来不污染官方数据库。启发式分析签名覆盖不到的部分签名匹配不了未知威胁但 DIE 的启发式模块会分析熵值、入口点特征、节区属性等给出疑似加壳疑似混淆的提示。这就是图 1 中Protector和Heuristic Protection并列出多条结果的原理。签名负责精确启发式负责兜底两者结合把误报率压到很低。我踩过的三个坑提前帮你避开第一次用 DIE 时我在三个地方栽过跟头写出来供你参考。坑一扫描目录时忘了加-r。diec /path/to/dir只会扫描目录本身不会递归子目录。批量审计时漏掉嵌套目录里的文件结果报告残缺不全。记住目录扫描必带-r。坑二把diec输出当最终结论。DIE 给出Compiler: MinGW并不意味着程序一定由 MinGW 编译——它可能只是匹配了特征字节。加壳和编译器信息是强线索但最终判断要结合反汇编和动态分析交叉验证。坑三误以为签名越多越准。自定义规则写得过于宽泛比如只用 2 字节魔数会大幅增加误报。我在 help/Signatures.md 里学到的最佳实践是至少用 4 字节以上特征配合上下文偏移。比如匹配 PE 文件时用4D5A........PE0000比单纯4D5A靠谱得多。常见问题速查问题答案检测结果不准确怎么办更新签名数据库用-d深度扫描检查自定义规则是否过宽命令行和 GUI 版本如何选批量处理用diec深度阅读结构用die轻量扫描用diel支持哪些文件格式PE、ELF、Mach-O、APK、IPA、JAR、DEX、ZIP、ISO9660 等十余类未识别格式走启发式分析如何导入第三方规则用-D /path/to/db指定自定义数据库目录分析大文件很慢大文件优先用 CLI 并关掉不必要的面板GUI 里可调整扫描范围需要计算文件哈希diec -S Hash 目标文件一步到位下一步动手验证这四件事工具是练出来的。建议你按下面顺序实践每步都能在几分钟内完成跑通最小流程找个 PE 或 ELF 文件执行diec 文件路径对照本文结果核对输出格式。批量扫描自己下载的软件包目录用diec -rd加-j看看有没有意外发现加壳或加密特征。为一种你知道魔数的私有格式写签名规则参照 help/Signatures.md 里的范例放进 db/ 后重启验证。把diec集成进你的分析脚本用 JSON 输出做自动化筛选例如自动标记所有 UPX 加壳样本。DIE 的价值不在于一次识别多准确而在于它把文件定性这件脏活变得可复制、可扩展。希望这篇教程能帮你少走我走过的弯路——现在就去跑第一条命令吧。【免费下载链接】Detect-It-EasyProgram for determining types of files for Windows, Linux and MacOS.项目地址: https://gitcode.com/gh_mirrors/de/Detect-It-Easy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考