尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

用DIE精准查壳:从入口点到熵值识别加壳程序

用DIE精准查壳:从入口点到熵值识别加壳程序 简介DIEDetect It Easy是一款专业级查壳工具面向逆向分析、恶意代码研究及安全爱好者。相比传统PEID它在识别能力上更胜一筹支持一次扫描识别多重壳与编译器信息能读取超大文件及部分其他工具无法打开的程序在Windows、Mac、Linux下均可使用足以替代PEID。资源包为便携绿色版免安装、支持文件拖放与右键菜单自带简体中文等多国语言还提供自定义插件、脚本编写、多种皮肤和16进制编辑等实用功能适合从入门到进阶的安全从业者日常使用。压缩包内共1362个文件大小约13.55MB以识别特征数据库文件为主同时包含exe主程序、dll动态库、qm/qss界面资源、html说明文档等目录结构较为清晰便于按需查阅。目前已有4146人学习下载可帮助读者快速搭建跨平台的加壳识别环境提高样本分析效率。1. 查壳工具 DIE能扛几百 MB 样本还看得到壳的底牌做逆向和恶意样本分析的人第一次用 DIEDetect It Easy往往会有一个共同反应怎么现在才换掉 PEID。PEID 确实是老牌查壳工具但拿到签名被裁剪过的修壳体、几 MB 的小程序还凑合真丢一个几百 MB 的安装包进来它经常直接卡死或者报“什么都没发现”。DIE 不一样它对超大文件的读取能力是写在底层设计里的入口点、节区、熵值、特征库四路并查壳的底牌基本藏不住。查壳工具这个分类里DIE 虽然名气不如 PEID但它是少数能一次查到底、还能用脚本补特征的方案适合做样本分析、脱壳验证、病毒排查的从业者也适合刚学逆向、想确认自己是不是加壳了的新手。2. 上手三分钟界面、扫描模式、右键菜单与拖放解析2.1 先从界面读懂 DIE 在告诉你什么DIE 的界面和其它壳检测工具最大的区别是不只给你一个“壳名”。打开文件后界面主要分三块左侧是文件信息区显示文件类型、入口点地址、文件大小、节区数量和节区名中间是签名检测区展示检测到的壳、编译器、链接器信息右侧是十六进制区和字符区用于人工确认特征码。对刚上手的人来说最容易忽略的是左侧的“入口点”和“熵值”。入口点EP是程序被加载后执行的第一条指令位置。正常情况下VC、Delphi、MinGW 编译出来的程序入口会落在代码节比如.text而加壳程序的入口通常在壳的节区里比如UPX0、UPX1、VMP0、VMP1。DIE 会直接把入口点所在节区标出来这一步比很多工具只报壳名要透明得多。我一般拿到样本会先看一眼入口点落在哪个节再对比签名区的结果如果签名区说是 UPX 但入口点落在.text十有八九是手动改过节名的修壳体。右边还有一个容易被当装饰用的数据熵值图。熵值接近 8 或者持续高亮意味着这段数据接近随机分布通常是被压缩或加密过。程序本体是普通指令熵值一般在 56 左右壳代码因为压缩熵值会明显偏高。它不是唯一判断依据但能帮你在“DIE 报未加壳”的时候保持警惕。2.2 三种扫描模式怎么选DIE 提供多种扫描模式界面上能切换的常用三种快速扫描、深度扫描、全类型扫描。很多人一上来就点深度扫描其实没必要。快速扫描只比对外部签名特征速度最快适合批量拉取文件名列表做初筛。深度扫描会额外做入口点分析、节区检查、熵值统计大多数样本用这个就够了。全类型扫描则是不管文件后缀是什么按多种文件格式逐个尝试解析。扫描模式扫描策略适用场景耗时快速特征码比对大批量初筛秒级深度特征码 入口点 节区 熵值单个样本精确判断数秒全类型按 PE/ELF/Mach-O 等多格式解析文件类型被篡改的样本较长实际操作中我很少用全类型扫描除非文件后缀被改成 .bin 或者 .dat快速和深度扫出来不一致才会切全类型。注意一点深度扫描并不是百分百能扫出所有壳它只是把更多特征纳入比对范围。真正要加规则需要走后面说的自定义脚本这个后面单独讲。2.3 右键菜单和拖放把检查变成顺手的事DIE 是绿色免安装的工具解压就能用。支持拖放文件到窗口也支持添加右键菜单。右键菜单的设置入口一般在菜单栏的“选项”里选中“添加到右键菜单”之后在任意 PE 文件上右键就能直接调起 DIE 检测。这一步对日常处理样本的人来说省很多事不需要先开软件再选文件。添加右键菜单需要写注册表所以 Windows 下执行这一步时要以管理员身份运行 DIE。如果你用的是精简版系统或者公司电脑有权限管控注册表写入会失败界面没有任何明显报错但右键菜单就是不出来。遇到这种情况直接用拖放就好功能完全一致。Linux 和 macOS 下没有右键菜单注册表的说法一般在文件管理器里配置外部工具关联到 DIE 的可执行文件。我个人的习惯是 Windows 下开启右键菜单配合一个快速启动工具基本上鼠标三秒内能完成一个样本的初判。3. 壳特征藏在哪签名库、插件、脚本三层结构与超大文件读取3.1 三层识别体系签名是基础脚本才是扩展的硬手段DIE 之所以敢说比 PEID 强核心在于它的识别架构是三层。第一层是内置签名库覆盖常见压缩壳、保护壳、加密壳和编译器特征这一层和 PEID 的思路类似都是靠特征字节匹配。第二层是插件DIE 允许把特定格式的解析器做成插件比如某些私有壳需要先解析自定义文件头才能看到真实代码写插件可以解决签名匹配无法覆盖的情况。第三层是脚本脚本可以直接读取文件字节、入口点、节区表、导入表等数据然后按自定义逻辑判定是否为某款壳。三层结构带来的实际差别是PEID 遇到不认识的新壳只能躺平而 DIE 用户可以在几天之内靠脚本把新壳识别出来。对做病毒分析和外挂对抗的人来说这个能力值回所有折腾成本。常见做反检测的壳会加随机花指令让固定字节特征完全失效但它们的入口点节区结构、导入表残留、熵值分布仍然有规律用脚本描述这些规律比硬编码特征健壮得多。DIE 的脚本以 Pascal 方言写成签名定义文件常放在程序目录下 dict 或是 scripts 目录不同版本略不一样。加载策略也很直接放入对应目录在 DIE 界面的“选项 → 脚本”里勾选启用重启之后对所有新打开的样本生效。脚本接口具体有哪些全局函数可以打开 DIE 自带的帮助文档查看不同的小版本有些出入。3.2 超大文件读取“读不了”和“不读完”很多人遇到超过 200 MB 的安装包第一反应是扔进 PEID 里碰运气然后卡死在加载阶段。DIE 能处理超大文件的关键在于它没有把整个文件一次性读进内存而是用内存映射加分段解析的方式。操作系统把文件映射到进程地址空间DIE 按需读取文件头、节区表、导入表这些关键结构不需要把后面的压缩数据全部加载进来。这就解决了三个实际场景文件太大PEID 加载直接假死文件带自校验读取过程中会计算文件哈希导致程序崩溃文件被刻意填充了大量垃圾数据放在尾部普通工具会花时间遍历整个文件。DIE 对这类样本的策略是按结构访问文件尾部填充再多数据也不影响前段的解析速度。以前手里接过一个 400 MB 的安装包DIE 打开大概延迟了两三秒就给出了壳名换了另一款工具直接白屏。查壳工具的本质就是解析文件结构而不是读取全部内容这一点 DIE 的设计方向是正确。3.3 熵值和节区壳的“体味”藏在这些数字里只靠签名库会漏报所以 DIE 把熵值计算和节区异常也纳入展示。节区表里如果出现名为.aspack、.vmp0、.pecompact的节基本能对上壳的特征但修壳体最常见的操作就是把节名改回.text、.rdata。这时候熵值就有用了.text节存放的应该是可读的机器指令熵值在 56 区间如果显示为 7.9说明这段代码被压缩过。正常程序不会把代码压缩再解压执行。我曾经遇到一个样本节名全部正常导入表也没有异常DIE 深度扫描报“未加壳”。但注意到.text节熵值 7.6入口点却落在.rdata明显不合理。后来确定是一款小众保护壳特征签名没有收录最后用脚本依据这两条规则把它识别了出来。判断壳这件事特征是充分条件熵值和节区是必要条件两者结合才不会漏。4. 自定义脚本实战给私有壳写一条可复用的 DIE 签名4.1 脚本模板先学会骨架再填特征写 DIE 脚本没有想象中难。它的脚本文件通常以.sb结尾语法接近 Pascal。核心逻辑就是按条件命中后调用AddSignature告诉 DIE“找到了”再决定要不要附加说明信息。先看一个最基础的模板理解 DIE 脚本的骨架function detect(PE) : boolean; begin result : false; if PE.exportContains(VirtualProtect) then begin AddSignature(demo packer v1.0); AddMetadata(ep, PE.entrypoint); result : true; end; end;这段脚本做的事情是检查 PE 文件的导出表里是否包含VirtualProtect这个 API如果存在就把壳名标记为demo packer v1.0。exportContains是脚本里常用的接口用来判断导出函数是否存在AddSignature的字符串会直接显示在 DIE 的签名检测区AddMetadata则把一个附加键值写到检测结果里。注意PE并不是一个固定的对象名字需要按 DIE 当前版本的脚本约定来写有的版本叫PE有的支持直接读取EP全局变量具体以你下载版本的签名示例为准。判断后要显式把result置为true否则 DIE 不会认为这条规则命中了。4.2 一个私有壳判定脚本用节区名 熵值双重验证实际项目中我们不能只凭一个 API 就下结论那样误报率会很高。以一款会改节区名的小众壳为例我就写过一个组合条件的脚本要求同时满足两个条件才报壳名一是入口点落在指定节内二是该节的熵值高于阈值。这样即使节名被伪造成.text逻辑上仍然会被识别。function detect(entrypoint, sections) : boolean; var i: integer; targetSection: string; begin result : false; for i : 0 to sections.count - 1 do begin if sections[i].contains(entrypoint) then begin targetSection : sections[i].name; if sections[i].entropy 7.2 then begin AddSignature(shadow_packer (ep in targetSection )); AddMetadata(section_name, targetSection); AddMetadata(entropy, sections[i].entropy); result : true; exit; end; end; end; end;这段脚本的识别逻辑是遍历 PE 文件的节区表找到入口点所在的那一节接着检查这一节的熵值是否大于 7.2。两个条件同时成立才判定为私有壳。sections[i].entropy是 DIE 暴露出来的节熵值接口属于浮点数直接用比较符判断。exit的作用是命中后立刻跳出循环避免把同一条结果重复叠加。AddSignature里可以拼接字符串targetSection会被替换成实际节区名这样检测结果能直接看到壳代码落在哪个节不用再回头翻节区表。脚本写完后放到 DIE 的dict或者用户自定义目录然后在配置界面勾选启用重新打开样本就能看到新签名。常见的一个坑是脚本目录里的其它签名文件有语法错误导致整个脚本目录加载失败表现为你自己加的规则不生效且界面没有报错。遇到这种情况我一般做二分排除把原目录的脚本临时移走只留自己写的这一个逐个排除语法问题。4.3 让脚本可维护把特征值抽成常量写脚本不能只写一次壳会更新变种规则需要反复调。建议把特征值全部抽到开头类似熵值阈值、节名特征、API 名称都定义成常量后续维护时改一处就行。const MIN_ENTROPY 7.2; SUSPECT_SECTION .data; KEY_API VirtualProtect;把阈值集中定义还有一个好处排查误报时可以直接调熵值从 7.2 降到 6.9 看误报率变化而不用翻遍整个脚本找魔法数。这个习惯是从小项目踩坑换来的一开始把特征值散写在函数里壳更新一次改脚本改到怀疑人生。5. 避坑与常见问题查壳翻车的五个真实现场5.1 判定结果翻车三种典型的误报与漏报现场现象一DIE 报告“未加壳”但行为监控显示程序明显有壳的特征。原因这个样本大概率用了私有壳或者壳特征被刻意混淆过签名库没有覆盖。解决不要只看签名区结合入口点所在节、熵值高亮、导入表异常三项综合判断。熵值高于 7 且入口不在代码节基本可以判定做了手脚。此时按第 4 章的方式补一条自定义脚本把判定逻辑固化下来。现象二同一样本 PEID 报 UPXDIE 报“无签名”。原因壳已经被脱掉或修复过但节区名还残留UPX0、UPX1。PEID 有时只看节名就下结论DIE 更侧重可靠签名。处理时把文件丢进十六进制区查入口点指令看是否为 UPX 解压 stub。如果是脱壳后的文件入口已经指向.text正常指令那就不是壳是残影。现象三同一个文件DIE 连续打开两次显示的壳名不一致。原因DIE 的多线程扫描与自身插件加载偶发冲突或者样本文件正在被其它程序占用导致读取不一致。解决复制一份样本再查或切到深度扫描模式重扫一次。DIE 不是病毒扫描器不会改写文件但文件占用时内存映射可能读到不一致的页这是文件系统的锅。5.2 资源读取阶段翻车界面、权限与文件损坏现象四大文件打开后界面卡死CPU 占满几十秒没响应。原因虽然 DIE 设计上避免全量读文件但部分插件在解析异常格式时会陷入无效循环老版本尤其明显。解决优先升级到较新版本关闭不常用的格式插件只保留 PE、ELF、Mach-O 相关解析器。深度扫描模式下不要同时多开大文件DIE 并不是为并发大样本设计的。现象五Windows 下添加右键菜单没有反应或者菜单项存在但点击出错。原因没有以管理员身份运行写注册表被 UAC 拦截或者程序被移动过位置右键菜单指向的旧路径失效。解决以管理员权限重新执行一次添加操作程序固定放在某一路径后不再移动避免出现悬浮快捷方式。Mac 和 Linux 用户一般是在文件管理器配置自定义动作这里不涉及注册表问题。6. 进阶技巧用 diec 批量体检拿十六进制视图反向验证结果DIE 安装包里有命令行版本可执行文件Windows 下叫diec.exeLinux 下叫diec。它和图形界面共用同一套签名库输出清晰适合对一批样本做批量初筛。常见的做法是写一个循环脚本把目录里所有 PE 文件扫一遍并把结果输出成 JSON 文件存档。#!/bin/bash outputscan_result.json input_dir/data/samples echo [ $output for file in $input_dir/*.exe; do ./diec -d -o json $file $output echo , $output done echo ] $output脚本里-d是深度扫描-o json指定输出格式为 JSON方便后续写脚本抓取“壳名 空”但“熵值 7”的可疑样本。注意最后拼接的,会产生一个尾部逗号不是一个合法 JSON但大多数解析场景只需要逐条 grep不要求一次过校验。如果想得到严格合法 JSON建议逐文件导出再合并。批量扫描不能替代图形界面的交互判断它的价值在于快速筛出高嫌疑样本再把少量命中样本放进图形界面做深度分析。拿到命中样本后我会强制走一遍十六进制验证在 DIE 的十六进制区跳到入口点地址看这条地址指向的机器指令是压缩壳的解压 stub还是程序本体代码。UPX 的入口通常是pushad开头即 0x60VMP 的入口往往是一段长的间接跳转指令序列很难一眼看懂。这一步能有效防止“签名报错判断被带偏”尤其是处理修改过的修壳体。验证通过后才把结果写进分析记录里。从那以后我每个样本都强制走一遍这个流程右击文件、DIE 深度扫描、看入口点和熵值、命令行批量存证、十六进制区确认入口指令。这套操作不超过两分钟但能把误判率压到很低。查壳工具始终是辅助判断真正的结论得靠自己的眼睛确认一遍才算数希望帮到你。本文还有配套的精品资源点击获取
返回列表