SakaChan33/SMA

GitHub: SakaChan33/SMA

一个基于 Rust 的静态恶意软件分析框架,在不执行样本的前提下提取二进制文件特征(熵值、导入表、可疑 API、字符串、控制流图),用于恶意软件分流与研究。

Stars: 0 | Forks: 0

# 静态恶意软件分析框架 当前正在开发中 最后编辑:2026-07-17 主要的研究问题是什么? 本研究调查了在不执行程序的情况下提取的结构和语义特征——包括头部、各节熵值、导入表、可疑 API 组合、嵌入的字符串/IOC 以及控制流结构——是否能为将可执行文件分类为恶意或良性提供足够的证据;并刻画了在对抗性条件(加壳、混淆、隐藏导入)下,纯静态证据何时会变得不足。它将静态分析定位为一个**能低成本进行可疑度排序的分流层**,而不是一个绝对的分类器。 以下十四个问题是这一总问题的**子问题**——每个里程碑提取的特征都会成为同一实验中的一个变量(哪些特征最能区分类别,哪些会导致误报,哪些恶意软件能抵抗静态分析,以及该技术在何处失效)。 需要考虑的问题: 1. 可执行文件的静态特征能多准确地将恶意软件与良性软件区分开来? 这是一个经典的分类问题,且范围足够广泛,足以支撑起整篇论文。 2. 哪些静态特征对恶意软件分类准确性的贡献最大? 研究的是特征重要性,而不仅仅是构建一个检测器。 3. 仅凭导入表分析,能在多大程度上预测一个 PE 可执行文件是否为恶意? 专注于一种常用的静态技术。 4. 熵分析作为加壳或混淆恶意软件的指标有多有效? 评估基于熵的启发式方法的优势与劣势。 5. 在恶意软件检测中,静态启发式方法的组合能否优于单一启发式方法? 研究多个弱信号是否能组合成更强的分类器。 6. 静态分析技术抵御常见恶意软件混淆方法的鲁棒性如何? 检查当攻击者故意隐藏行为时静态分析的局限性。 7. 可执行文件的元数据与恶意分类准确性之间有何关系? 考察时间戳、节名称、编译器产物、证书、资源、版本信息及类似元数据。 8. 可疑 API 的使用情况能在多大程度上准确预测恶意功能? 衡量基于 API 的启发式方法是否与恶意行为相关联。 9. 嵌入的字符串和妥协指标在多大程度上能改进静态恶意软件分类? 评估 URL、注册表路径、互斥锁名、IP 地址、域名及其他嵌入的产物。 10. 使用相同提取特征时,基于规则的静态恶意软件分类与统计或机器学习方法相比表现如何? 如果你决定包含一个简单的 ML 基线,这是一个极具对比价值的研究问题。 11. 仅使用静态分析,哪些类型的恶意软件最难区分? 探索勒索软件、窃密器、释放器、加载器、RAT、挖矿程序等。 12. 可执行文件加壳如何影响静态恶意软件分析的可靠性? 针对静态分析中最大的挑战之一进行的专项研究。 13. 静态恶意软件检测中误报和漏报的主要原因是什么? 这通常能产生极具价值的研究,因为理解失败与报告准确性同样重要。 14. 可解释的启发式评分能否在不显著降低检测性能的前提下,提高分析人员的理解能力? 研究可解释性,这在网络安全工具中变得越来越重要。 15. 静态恶意软件分析的实际极限在哪里?在什么情况下必须使用动态分析? 这提供了一个契机,探讨静态分析在何处能取得成功,以及在何处它从根本上无法回答某些问题。 一个在不运行可执行二进制文件的情况下,提取有意义特征以支持恶意软件分流和行为预测的框架。 - **实现:** (`src/`) 是主要的研究产物,这是一个 Rust 命令行工具,用于解析 PE 和 ELF 二进制文件,提取特征并生成结构化报告。它的设计是*安全*的(绝不执行样本)且*具有确定性*的(相同的输入始终产生相同的输出)。 - **语言:** Rust —— 恶意软件解析器需要处理充满敌意、格式畸形的输入,因此一种*本身无法被构造的恶意二进制文件利用*的内存安全语言是正确的工程选择。这一论点也是研究背景的一部分。 ## 为什么选择“静态”?(以及为什么这样做是安全的) **静态分析**检查程序的*字节和结构*——包括头部、节、导入函数、嵌入的字符串、代码布局——**而从不执行它**。与之相反的*动态分析*则是在沙箱中运行样本并观察其行为。 静态分析是作为首个项目的正确选择,原因如下: - **它是安全的。** 我们从不执行样本,因此不需要虚拟机、沙箱或隔离的实验室环境。格式畸形的输入可能会让*解析器*崩溃,但 Rust 能够控制住这种情况。 - **它是确定性的。** 同一个文件始终产生相同的特征——非常适合用于可复现的实验。 - **它是快速的。** 每个文件仅需几毫秒,因此我们可以在大型数据集上进行评估。 这种权衡——我是去*测量*它而不是隐藏它——在于加壳、加密和混淆可能会使静态特征失效。然而,恰恰是*这些失败*引发了怀疑,并促使我们进行进一步的分析。准确地量化静态分析*何时*失效,正是本项目的核心研究贡献之一。 早期分析表明,静态特征具有惊人的预测能力。甚至连合法软件也经常触发与恶意软件相同的启发式规则。这使得静态分析更像是一个*分流工具*,而不是绝对的分类器。静态恶意软件分析可以快速识别出可疑的可执行文件以供进一步检查,但它永远无法达到 100% 的准确率。 ## 威胁模型与范围 | 方面 | 决策 | |---|---| | **对手** | 试图规避*静态*检测(加壳、混淆、隐藏导入)的潜在恶意可执行文件的作者。 | | **范围内** | 首要支持 PE (Windows);其次为 ELF (Linux);Mach-O 已建立存根。特征提取 + 基于规则/评分的恶意程度估算。 | | **范围外** | 执行样本、内核/驱动分析、完整反编译、网络 C2 交互。 | | **信任边界** | 每一个输入字节都是**不可信**的。解析器在面对充满敌意的输入时绝不能崩溃或越界读取——这是我们要测试的一项安全属性。 | ## 里程碑 | M | 交付成果 | 对应研究内容 | |---|---|---| | **M0** | 研究脚手架:本 README、威胁模型、样本策略、文档模板 | 框架构建、可复现性 | | **M1** | PE 解析器(DOS → NT 头 → 节)→ 结构化输出 | 解析可执行文件格式 | | **M2** | 每节 Shannon 熵 → 加壳启发式检测 | 熵、加壳器检测 | | **M3** | 导入表提取(DLL + API) | 导入库/API | | **M4** | 可疑 API 规则(注入、反调试、持久化、网络、加密) | 可疑 API 使用 | | **M5** | 字符串 + IOC 提取(URL、IP、注册表键) | 恢复嵌入字符串 | | **M6** | 格式抽象层 → 添加 ELF | 多平台抽象 | | **M7** | 函数控制流图 → Graphviz | CFG 构建 + 可视化 | | **M8** | 机器可读的 JSON 报告(+ 可选 HTML) | 机器可读报告 | | **M9** | 插件架构(分析器作为插件) | 可扩展性 | | **M10** | **评估:** 在带标签数据集上运行 → 查准率/查全率/F1,ROC/AUC 对比基线;记录误报与局限性 | **状态:** M0–M7 已完成 —— PE 解析器、熵、导入表、可疑 API 规则、字符串 + IOC、**支持 ELF 的格式抽象层**(一个 `sma` 即可同时分析 Windows PE 和 Linux ELF),以及**反汇编器 + 控制流图**(`sma -d`,支持文本或 Graphviz DOT 格式,基于 Capstone 构建)。M8(机器可读的 JSON 报告)是下一步计划。 ## 使用方法 `sma` 是一个**命令行工具**:你可以在终端中运行它,传入一个文件路径,它就会将静态报告打印到标准输出。它绝不执行样本——只读取字节。 ### 安装 **选项 1 —— 下载预编译二进制文件(不需要工具链)。** 从 [Releases](../../releases) 页面获取适用于你操作系统的独立二进制文件——`sma-windows-x86_64.exe` 或 `sma-linux-x86_64`——并运行它。无需安装,也没有额外的依赖库:Capstone(反汇编引擎)已被编译进该二进制文件中,因此它是一个单一文件。 ``` # Windows (PowerShell):重命名并运行 ./sma-windows-x86_64.exe --help # Linux chmod +x sma-linux-x86_64 && ./sma-linux-x86_64 --help ``` **选项 2 —— 使用 Rust 从源码构建**(需要 `rustup` + 用于编译 Capstone 的 C 工具链,在 Windows/Linux 上构建过程会自动找到它): ``` cargo install --path . # builds a release binary and puts `sma` on your PATH sma --help # now callable by name from any terminal ``` (对于开发而言,在项目目录下执行 `cargo run -- ` 即可生效;编译完成的二进制文件会生成在 `target/release/sma` 目录下。) ### 模式 单个二进制文件,包含多种分析模式(扫描和反汇编模式已实现;调试模式已声明,以便在项目扩展时保持接口稳定): ``` sma [MODE] [options] -s, --scan static report (default): headers, entropy, imports, capabilities, strings/IOCs -d, --disassemble build a function's control-flow graph (CFG) -b, --debug dynamic / debug analysis [planned: future] -h, --help show help scan options: -f, --full also print the COMPLETE hex of the headers and every section to stdout (massive; redirect it to a file) --dump-sections write per-section hex files (see below) disassemble options: --addr function start address (default: the entry point) --dot emit Graphviz DOT instead of a text listing ``` ### 示例 ``` sma -s "C:/Windows/System32/notepad.exe" # or just: sma sma "C:/Windows/explorer.exe" | grep -A20 '^capabilities' # pipe like any Unix tool sma "C:/Windows/System32/cmd.exe" > output/cmd.exe.analysis.txt # save a report # -f 将每个 section 的完整 hex 追加到报告中。重定向到文件: sma -s -f "C:/path/to/big.exe" > output/big.full.txt # e.g. 223 MB exe -> ~1 GB text # -d 构建函数的 control-flow graph(默认:entry point)。 sma -d "C:/Windows/System32/cmd.exe" # readable text CFG (one function) sma -d "C:/Windows/System32/cmd.exe" --dot > cfg.dot # Graphviz; dot -Tpng cfg.dot -o cfg.png sma -d "C:/Windows/System32/cmd.exe" --addr 0x27c54 # a specific function # --all 对整个程序进行 linear-disassembles(每个函数)。重定向到文件: sma -d --all "C:/path/to/app.exe" > output/app.disassembled.txt # can be multi-GB # --calls 列出程序的 call targets(函数 RVA + 调用频率), # 这样你就可以使用 --addr 跳转到任意一个: sma -d --calls "C:/path/to/app.exe" > output/app.calls.txt sma -d --addr 0x509e900 "C:/path/to/app.exe" # inspect one function from that list ``` CFG(`-d`)展示包含分支/循环结构的*单个函数*;`--all` 则以平铺方式展示每个可执行节中的*每一条*指令(类似于 `objdump -d`)。 完整的十六进制数据是*流式输出*的(内存占用恒定),因此即使是 200 MB 以上的二进制文件,在重定向到文件时也能在几秒钟内完成转储。在 Git-Bash/MSYS shell 中将其通过管道传递给另一个程序会慢得多(管道缓冲区较小)——建议直接重定向到文件。 **按节输出完整十六进制数据** —— 标准输出仍然保持通用报告格式;原始字节会输出到独立的文件中(每个节一个文件 + 一个头信息文件),每个文件都包含该节的具体细节(熵、标志、大小、RVA),随后是其**完整**的十六进制转储: ``` sma --dump-sections output/ > output/.analysis.txt ``` 生成 `output/.headers.txt` 和 `output/.section-NN-.txt` 文件。 注意:某个节的十六进制文件大小约是原大小的 10 倍,因此转储一个体积庞大的二进制文件的 `.text` 节(例如 Electron 应用)可能会产生数百兆字节的文件。 ### 扫描报告显示的内容 分为五个部分,每个里程碑对应一个:PE 头摘要(M1),各节**熵值** + 加壳检测结果(M2),**导入表**(M3),带严重级别的**能力发现**(M4),以及**字符串 + IOC**(M5)。一项发现代表一个*需要进一步查证的理由*,绝不是确凿的定论——良性软件也会不断触发这些规则。 ## 目录结构 ``` static_malware_analysus/ README.md ← you are here src/ MY implementation (Rust) Cargo.toml ``` ## 软件产物 ## 研究产物 ## 实验结果 ## 贡献 本研究并不试图取代像 Ghidra 或 IDA 这样成熟的逆向工程框架。 相反,它提供了一个可复现的实验平台,用于提取静态可执行文件特征,并评估这些特征预测恶意程度的能力。 实现部分存在的目的是通过受控实验来回答上述研究问题。 ## 待补充内容 以下是一些额外需要考虑的问题。这不一定是为了研究本身,而是针对该产物和读者本身的考量。 - 编写了多少行 Rust 代码? - 包含多少个模块? - 支持多少种可执行文件格式? - 识别了多少种 API? - 应用了多少启发式规则? - 提取了多少种 IOC 类型? - 解析器架构是什么样的? - 使用了哪些 crates? - 性能表现如何?
标签:DAST, Rust, 云安全监控, 云资产清单, 可视化界面, 恶意软件分析, 网络流量审计, 逆向工程, 通知系统, 静态分析