迈向通用恶意软件解包技术

# 迈向通用恶意软件解包技术 ## 1. 恶意软件解包分析方法 ### 1.1 手动调试与解包阶段识别 当无法确定基本块的来源时，需要对样本进行手动调试，以识别未标记基本块的内存来源。将相应函数添加到白名单后，检查系统能否将来源归因于基本块。这样做能确保考虑到恶意软件的各种方法，并在出现新方法时及时发出警告。不过，该方法无法记录使用面向返回编程进行的解包行为。 每当执行一个之前由同一解包阶段写入的新基本块时，就会创建一个新的解包阶段。后续的所有内存写入、执行和 API 调用都将归因于这个新的解包阶段。若分析涉及多个进程，该方法会并行处理以适应每个进程，最终分析结果是一系列解包阶段。 ### 1.2 生成打包器标签 解包阶段会被组织成一个列表，连续的阶段会被标记为 Transition 标签。两个解包阶段的执行块集合存在非空交集时，会触发 Share - Code 标签；后续阶段的写操作集合与早期解包阶段的执行代码集合存在非空交集时，会触发 Overwrite 标签；早期阶段的写操作集合与后续解包阶段的执行代码集合存在非空交集时，会触发 Memory - Writer 标签；通过早期解包阶段生成或使用的内存，且后续解包阶段的执行基本块位于其中时，会应用 Memory - Source 标签。这些标签共同描述了恶意软件的解包行为。 ### 1.3 方法局限性 该方法假设代码在写入的位置执行，但对于使用自定义字节码表示的解释型语言编写的恶意软件（如 .NET 恶意软件）并不适用。此外，为了利用 PyPanda 进行实验而进行的运行时优化可能导致结果不准确，例如某些内存写入未被记录或两个解包层之间的重叠代码未被完全记录。不过，这种不精确性对结果的核心结论影响不大，因为核心结论只涉及两个解包阶段之间被覆盖和重叠代码的数量，不影响 Overwrite 和 Share - Code 标签的二元性质。同时，沙箱分析恶意软件时普遍存在的问题也会出现，比如恶意软件可能检测到自己在 PANDA 沙箱中运行并改变行为。 ## 2. 研究实验 ### 2.1 数据集 - **野生恶意软件数据集**：选择 Malpedia 作为野生恶意软件数据集，它是手动整理的数据集，旨在通过涵盖尽可能多的恶意软件家族来实现代表性，同时每个未打包样本仅保留一个唯一版本。使用了其中所有 3714 个 32 位可执行样本，排除了 435 个（11.71%）使用 .NET 框架的样本、382 个（10.29%）无法在虚拟机中运行或未完成分析步骤的样本以及 48 个（1.29%）无法完全描述内存来源或写入者的样本，最终整理后的数据集包含 2897 个样本，系统在其中 1206 个样本（41.63%）中检测到了解包行为。 - **临床数据集**：选择 dataset - packed - pe 作为临床数据集，使用了 2931 个样本。同样排除了 119 个（4.06%）.NET 样本、254 个（8.67%）运行失败的样本和 16 个（0.55%）无法完全描述的样本，最终在 2001 个样本（78.23%）中检测到了解包行为。 ### 2.2 实验设置 同时使用十二个工具实例，设置超时时间为十分钟。虚拟机配置为 2GB 内存，操作系统为 i386 架构的 Windows 7。尽管 Windows 7 相对较旧且用户已迁移到新版本，但它对新旧恶意软件仍有很高的兼容性。 ### 2.3 实验结果 #### 2.3.1 内存来源（Memory - Source） | 内存来源 | Malpedia 样本比例（%） | Packed - PE 样本比例（%） | | --- | --- | --- | | image | 66.09 | 84.91 | | VirtualAlloc | 65.84 | 22.79 | | NtMapViewOfSection | 27.61 | 19.84 | | RtlAllocateHeap | 8.79 | 0.40 | | NtAllocateVirtualMemory | 8.13 | 0 | | codec