Daydream

用于防御性逆向工程的 Windows x64 PE 与进程内存取证分析。

## 目录 - [概述](#overview) - [项目状态](#project-status) - [预期用途](#intended-usage) - [当前功能](#current-capabilities) - [环境要求](#requirements) - [构建与测试](#build-and-test) - [使用说明](#usage) - [输出结构](#output-structure) - [特征码与 opcode 目录](#pattern-and-opcode-catalogs) - [项目结构](#project-layout) - [准确性与局限性](#accuracy-and-limitations) - [开发原则](#development-principles) - [贡献指南](#contributing) ## 概述 Daydream 是一个仅适用于 Windows 的 x86-64 Rust 应用程序，用于从以下来源收集结构化的取证分析 数据： - 正在运行的进程及其映射的主镜像。 - 磁盘上原始的 x64 PE（Portable Executable）文件。 该项目旨在为恶意软件分析师、逆向工程师、安全研究人员、学生和防御者提供有用的初步视角， 以便在进行更深入的分析（如使用调试器或反汇编器）之前了解情况。它将 PE 结构、导入表、字符串、调试 元数据、进程结构、特征码匹配、opcode 命中以及精确的位置元数据整合在一个工作流中。 Daydream 是一个取证分析工具。它不打算自动判定文件或进程是否为恶意。收集到的值应当作 分析师的证据，并结合周围的代码、来源、行为以及其他工具进行综合研判。 ## 项目状态 | 领域 | 当前状态 | | --- | --- | | 开发阶段 | 积极开发中 / 原型阶段 | | 支持的操作系统 | 仅限 Windows | | 支持的架构 | x86-64 / PE32+ | | Rust 工具链 | 稳定版 `x86_64-pc-windows-msvc` | | 进程输出 schema | 版本 1 | | 公共 API 稳定性 | 不作保证 | | 主要接口 | 命令行应用 | 目前请不要将当前的输出格式、模块边界或收集器行为视为稳定的公共 API。 ## 预期用途 Daydream 旨在用于合法的防御性工作，例如： - 在受控的分析环境中检查恶意软件样本。 - 为事件响应收集指标和结构性证据。 - 在授权的安全评估期间检查二进制文件。 - 调查您拥有或获得授权进行逆向工程的软件。 - 学习 Windows 进程结构、PE 内部原理、导入表、PDB 记录以及 x64 代码 模式。 - 生成 JSON 产物，以便日后审查、比较或集成到防御性 分析 pipeline 中。 不得使用 Daydream 未经授权访问系统或进程、部署 payload、逃避防御者或造成 破坏。进程内存检查是一项双用途技术能力；合法和合规使用的责任由 操作者承担。 ## 当前功能 ### 运行中进程的取证分析 进程模式使用查询和内存读取权限打开目标，验证其身份， 并在其各个收集器之间重复使用一份已验证的主镜像快照。 当前的进程收集器包括： - 进程身份、可执行文件路径、句柄访问权限以及 PEB 验证。 - 主模块基址、镜像大小、入口点 RVA 以及区段表。 - 稀疏映射镜像读取，并明确跟踪不可用的范围。 - 基于 PE 结构、入口点、`BaseOfCode` 和运行时函数 信息的证据的 x64 代码段选择。 - 标准 PE 导入表以及直接的 RIP 相对 IAT 调用/跳转引用。 - 支持的 `RSDS` 和 `NB10` 记录的 CodeView PDB 发现。 - 来自映射主镜像的 ASCII、UTF-8 和 UTF-16LE 字符串。 - 包含身份和 PEB 指针检查的逐线程 TEB 收集。 - 在受信任的 TEB `StackLimit` 和 `StackBase` 值之间逐区域进行字符串扫描。 - 来自 `patterns64.rs` 的每个已配置的 x64 分析师特征码。 - 来自 `opcodes64.rs` 的断点、调试陷阱和调试寄存器 opcode 命中。 - 适用情况下的 RVA、进程地址、区段和原始文件偏移量元数据。 进程模式在正常收集过程中保持终端安静。它会显示一条不断更新的 进度条，其中包含当前阶段和总体百分比，同时详细结果将 写入 JSON。 ### 原始文件的取证分析 文件模式分析磁盘上的字节，而无需将目标作为进程加载。 当前的文件收集器包括： - 严格的 x64 PE 验证。 - 文件标识、SHA-256、Shannon 熵、原始大小以及 PE 头元数据。 - 区段布局、内容分类、内存特征、RVA 和文件偏移量。 - 标准导入表以及受支持的直接 IAT 调用/跳转引用。 - 调试目录检查和带类型的调试 payload 元数据。 - 在支持的情况下，提供 `RSDS`、`NB10`、POGO、VC feature、可复现构建 (reproducible-build)、校验和、杂项以及 内嵌的与 portable PDB 相关的记录。 - ASCII、UTF-8 和 UTF-16LE 字符串提取。 - 通过 `X64_FILE_SCAN_SIGNATURES` 进行支持通配符的可执行段扫描。 文件模式目前会将收集到的摘要打印到控制台，并且还会保存整理好的 JSON 输出。 ## 环境要求 - Windows x64。 - 通过 [rustup](https://rustup.rs/) 安装的 Rust。 - 稳定版 Rust 工具链。 - `x86_64-pc-windows-msvc` 目标。 - Microsoft Visual Studio Build Tools，包含 MSVC 链接器和 Windows SDK。 - 足够的权限以打开选定进程进行查询和虚拟内存读取 访问。 该仓库的 `rust-toolchain.toml` 指定了： ``` [toolchain] channel = "stable" targets = ["x86_64-pc-windows-msvc"] components = ["rustfmt", "clippy"] ``` 一些受保护的、提权的、跨会话的、对安全敏感的或架构不匹配的 进程可能仍然无法访问，即使 Daydream 本身运行正常。 ## 构建与测试 从 Windows 终端克隆或打开仓库并运行： ``` cargo build cargo test ``` 进行优化构建： ``` cargo build --release ``` 发布版的二进制文件将位于： ``` target\release\daydream.exe ``` 实用的开发检查包括： ``` cargo check cargo test cargo clippy ``` ## 使用说明 ### 分析当前的 Daydream 进程 不带参数运行将回退到对 Daydream 自身的进程分析： ``` cargo run ``` 或者使用编译好的二进制文件： ``` .\target\release\daydream.exe ``` ### 通过 PID 分析正在运行的进程 ``` cargo run -- -p 1234 ``` ``` .\target\release\daydream.exe -p 1234 ``` 目标必须是 Daydream 有权查询和读取的进程。对于已授权的提权目标，可能 需要运行提权的终端，但提权并不会 绕过 Windows 的安全边界或受保护进程的限制。 ### 分析原始 PE 文件 ``` cargo run -- -f "C:\Samples\target.exe" ``` ``` .\target\release\daydream.exe -f "C:\Samples\target.exe" ``` 当前的 CLI 仅接受确切的一个目标模式和目标值： ``` usage: daydream [-f | -p ] ``` ## 输出结构 输出将在终端的当前工作目录下生成。JSON 文件将以 美化打印（pretty-printed）的形式写入。 ### 进程输出 进程输出根目录使用目标可执行文件的文件名主体和 SHA-256 标识： ``` _procdmp_/ ├── PE/ │ ├── image.json │ ├── sections.json │ └── pdb.json ├── Imports/ │ └── imports.json ├── PEB/ │ ├── peb.json │ └── tebs.json ├── Patterns/ │ ├── code_section.json │ ├── pattern_hits64.json │ └── opcode_hits64.json └── strings.json ``` 关键的特征码输出包括： - `code_section.json` — 选定的代码段证据和置信度。 - `pattern_hits64.json` — 标志性的 CRT 入口特征码以及每个配置过的 `X64_ANALYST_SIGNATURES` 匹配项。 - `opcode_hits64.json` — 每个配置过的断点/调试 opcode 匹配项，包括 在需要时的 ModR/M 元数据。 进程 JSON 会保留带类型的失败或部分读取信息，而不是直接静默 丢弃不可用的数据。重用相同的进程输出根目录会更新生成的 JSON 文件并删除过时的旧特征码文件名。 ### 原始文件输出 原始文件输出根目录使用目标的文件名主体和 SHA-256： ``` _/ ├── PE/ │ ├── file_metadata.json │ └── sections.json ├── Imports/ │ └── imports.json ├── PEB/ │ └── debug_directory.json ├── Scanning/ │ └── signature_hits.json └── strings.json ``` 当再次扫描相同的目标内容时，现有的原始文件输出根目录会被重新创建。 ## 特征码与 opcode 目录 ### 添加 x64 分析师特征码 x64 特征码目录位于： ``` src/core/data/patterns64/patterns64.rs ``` 特征码使用 `x64_signature!` 并接受精确的字节以及单字节通配符。贡献者 可以将通配符表示为 `??`、`?` 或 `WILDCARD`： ``` pub const EXAMPLE_SIGNATURE: Signature = x64_signature!( "example signature", [0x48, 0x8B, ??, 0xE8, WILDCARD, WILDCARD, WILDCARD, WILDCARD] ); ``` 每个通配符恰好消耗一个字节；它不是变长的间隙。声明 特征码后，将其添加到符合其预期作用域的目录中： - `X64_CRT_STARTUP_SIGNATURES` - `X64_RUNTIME_ANCHOR_SIGNATURES` - `X64_ANTI_ANALYSIS_SIGNATURES` - `X64_FILE_SCAN_SIGNATURES` - `X64_ANALYST_SIGNATURES` 进程特征码收集会消耗 `X64_ANALYST_SIGNATURES`。原始文件扫描会消耗 `X64_FILE_SCAN_SIGNATURES`。 ### 添加 x64 opcode 记录 断点和与调试相关的 opcode 数据位于： ``` src/core/data/opcode_specific64/opcodes64.rs ``` 每个 `OpcodeBytecode` 都提供一个名称、一个精确的 opcode 前缀以及一个 `requires_modrm` 标志。用于进程扫描的记录必须包含在 `X64_BREAKPOINT_OPCODE_BYTECODES` 中。 对于 `0F 21` 和 `0F 23` 等 opcode，收集器在记录命中之前， 需要并验证一个尾随的寄存器形式 ModR/M 字节。 ## 项目结构 ``` src/ ├── main.rs CLI parsing and mode dispatch └── core/ ├── data/ │ ├── opcode_specific64/ │ │ └── opcodes64.rs x64 breakpoint/debug opcode catalog │ └── patterns64/ │ └── patterns64.rs wildcard-aware x64 signature catalog ├── file_ops/ │ ├── file_processing.rs raw-file orchestration and console presentation │ ├── outputs/ │ │ ├── configs.rs raw-file output layout │ │ └── file_triage_saves.rs │ └── utils/ │ ├── apis.rs imports and direct IAT references │ ├── pdb.rs debug-directory and CodeView parsing │ ├── scanning.rs executable-section signature scanning │ ├── sections.rs section metadata and traits │ ├── strings.rs raw-file string collection │ ├── supports.rs checked PE byte/RVA helpers │ └── validate.rs x64 raw-file validation ├── process_ops/ │ ├── process_processing.rs process orchestration and progress reporting │ ├── outputs/ │ │ ├── config.rs process dump layout and filenames │ │ └── process_triage_saves.rs │ └── utils/ │ ├── detect_code_section_utils.rs │ ├── foundation/ │ │ └── validate_pe.rs mapped-image validation and snapshotting │ ├── importutils.rs process imports and IAT references │ ├── memutils.rs memory reads and region queries │ ├── pdbutils.rs process main-module PDB metadata │ ├── pe_utils.rs sections, locations, patterns, and opcodes │ ├── processutils.rs process, PEB, and main-module validation │ ├── stringdumputils.rs main-image and TEB-stack strings │ ├── strings.rs shared string decoding primitives │ └── tebutils.rs per-thread TEB collection ├── internal/ │ ├── imports/imports.rs │ └── utils/handles.rs owned Win32 handle wrapper └── global_utils/ └── fileutils.rs SHA-256, entropy, and JSON writing ``` `src/core/internal/saves/structure.rs` 也存在于仓库中，但目前 未被 `src/main.rs` 声明。 ## 准确性与局限性 - 特征码或 opcode 命中仅证明扫描 范围内存在匹配的字节。这并不能证明具有恶意意图或已被执行。 - 短的 opcode 特征码——尤其是 `INT3` (`0xCC`)——也可能代表编译器填充、 对齐、内嵌在可执行段中的数据，或者是合法的调试器行为。 - 通配符特征码属于字节模式，而不是解码后的指令语义。 - 对于没有对应原始文件数据作为Backing的映射字节，可能无法获取 文件偏移量。 - 在收集运行期间，进程内存可能会发生改变。线程可能会退出，堆栈可能会 改变，页面可能会变得不可访问。 - 由加载器丢弃的、受保护的、保留的、受保护的或不可读的范围可能会产生部分 结果。当收集器形态支持时，Daydream 会记录这些情况。 - 栈字符串可能是函数返回后留下的过期产物。 - TEB 栈扫描会使用已提交的可读区域，并跳过受保护或不可访问的 页面。跨越不可读边界的字符串可能无法恢复。 - 直接的 IAT 交叉引用收集目前主要关注受支持的 x64 RIP 相对 call 和 jump 形式；它不是一个完整的反汇编器或控制流引擎。 - Daydream 不能替代调试器、反汇编器、沙箱、YARA 引擎、EDR 产品 或分析师的判断。 ## 开发原则 - 验证一次并重复使用结构化的 PE/进程状态。 - 保留 RVA、进程地址、文件偏移量、区段和完整性元数据。 - 将原始文件操作与目标进程操作分开。 - 保留带类型的部分失败，而不是将每一个不可访问的页面视为整个扫描 的失败。 - 将进程访问权限限制在查询和内存检查所需的范围内。 - 优先考虑精确的、上下文相关的证据，而不是通用的字节片段。 - 保持大型扫描在限制范围内，并为耗时的阶段报告进度。 - 直接假定环境为 Windows x64；该项目故意不提供跨平台的 兜底方案（fallback stubs）。 ## 贡献指南 Daydream 正在快速迭代。在进行更改之前： 1. 阅读 `AGENTS.md` 和 `CLAUDE.md` 以了解仓库特定的规则。 2. 将新的原始文件收集器放在 `file_ops` 下，将进程内存收集器放在 `process_ops` 下。 3. 复用已验证的文件或进程快照，而不是在没有 明确需求的情况下重新解析或重新读取。 4. 为匹配、范围、解析器或输出行为添加专注的测试。 5. 至少运行： cargo check cargo test cargo build 6. 将检测结果视为证据，并记录已知的误报情况。 贡献必须保持在项目用于防御、授权的恶意软件分析和 逆向工程的目的范围内。

标签：DAST, Homebrew安装, PE结构分析, Rust, 可视化界面, 安全意识培训, 恶意软件分析, 网络流量审计, 进程分析, 逆向分析, 通知系统