wren-creator/disk-forensics

# 磁盘取证 这是一款桌面端磁盘取证镜像工具：选择设备，确认其为只读，进行镜像，分析，然后按需恢复。每一个步骤都必须在打开的**案件** (case) 下进行，且每一个操作都会被写入一个只能追加 (append-only) 且带有哈希链的审计日志中，因此该工具生成的是具备法律效力的证据保管链 (chain of custody)，而不仅仅是一个恢复工具。 ## 工作流程 ``` Launch → Open/New Case (forced first screen) → Case dashboard (evidence items, audit log, add evidence) → Add Evidence → Disk Select → Confirm Read-Only → Image → Analyze → Restore → (every step logs to the audit log automatically) → Close Case → seal + chain-of-custody report ``` 如果没有先打开案件，任何操作（磁盘选择、镜像、分析、恢复）都无法运行。工作流程的顺序在 `core/case.py` 本身中就被强制执行（例如，如果你在确认只读之前尝试进行镜像，就会抛出 `WorkflowError`），而不仅仅是通过禁用 GUI 按钮来限制。 ## 布局 ``` gui/ PySide6 screens, wired to core/case.py, see gui/main_window.py core/ case.py Case model: hash-chained audit log, gated methods, seal on close writers.py Pluggable image writer: RawWriter (done), E01Writer (stub) imager.py Streaming read + inline SHA-256 + bad-sector zero-fill disk_enum.py Windows WMI disk listing (Windows-only, see below) analyzer.py pytsk3 wrapper: walks live + deleted files, magic-byte typing report.py Chain-of-custody HTML report generator tests/ pytest, run with `pytest` cases/ per-case output, gitignored, .gitkeep only ``` ## 为什么选择 Windows 原生，而不是 WSL 镜像操作直接通过 `\\.\PhysicalDriveX` 句柄运行（需要通过 pywin32 获取管理员权限），而不是通过 WSL + `usbipd-win` 透传。WSL 透传只能访问 USB 设备，因此内部驱动器和硬件级写保护器 (write-blocker) 是无法访问的，并且它在物理设备和镜像之间增加了一个虚拟化层，这对于取证的可采性 (admissibility) 来说是个隐患。从设备到字节的最短、最易审计的路径才是王道。 ## 证据保管链设计说明 - **审计日志**：每条记录的哈希值都包含了上一条记录的哈希值，因此编辑任何过去的记录都会破坏整条哈希链 (`verify_audit_chain()`)。 - **封存 (Seal)**：在案件关闭时，证据/分析/恢复目录树会被计算哈希值，并写入到案件文件夹*外部*的一个 `.seal.sha256` 文件中。`case.json` 和 `reports/` 被排除在该哈希计算之外，否则两者都会导致哈希值变成自我引用（这是一个早期被捕获的真实 bug，详见 tests/test_case.py）。 - **已知限制**：只读确认目前反映的是 Windows 报告的状态（`StorageDevicePolicies\WriteProtect`），而不是硬件写保护器。这只是一个软件层面的声明，而非绝对保证，GUI 应当如实说明这一点，而不是暗示其他情况。 ## 路线图 - [ ] **E01Writer** — 真正的 Expert Witness Format 支持（压缩、内嵌的元数据/哈希块）。 **依赖决策 (2026-07-21)：选择 `pyewf`，仅作为可选启用，而非默认选项。** 对两个候选库进行了调研： - `pyewf` (libyal/libewf)：LGPL-3.0-or-later，Windows wheels 已发布在 PyPI 上 (cp310–cp312, win32/amd64)，因此最初担心的构建复杂性实际上并不构成阻碍。但 libyal 自身的文档将 Python 绑定标记为“实验性”/“开发中”，并且最新的 PyPI 发布版本是 2024 年 5 月的，已经停滞超过两年。 - `pyaff4` (AFF4, Google/Schatz Forensic)：暂时被排除，因为根据其自身的 issue 追踪器，该库目前的写入支持已损坏，无论格式本身有何优点，这都是一个致命阻碍。此外，比起 E01，AFF4 较少被法庭/EnCase/FTK 所普遍预期。如果/当上游修复了写入支持时，值得重新考虑。 鉴于这是一个证据保管链工具，默认情况下不能信任一个实验性/停滞的 C 扩展绑定来写入证据镜像。计划：基于锁定的确切 `pyewf` wheel 版本（而非浮动的最新版本）实现 `E01Writer`，保留 `RawWriter` 作为默认/官方推荐的路径，并要求在 CI 中通过往返完整性测试（写入已知数据 → 通过 pyewf 读回 → 哈希匹配），然后才将 `E01Writer` 作为除可选/实验性之外的功能在 GUI 中提供。 - [ ] 使用调查员密钥（或基于 TPM/DPAPI 的密钥）对审计日志条目 / 封存文件进行签名，单纯的哈希链可以阻止对单一条目的静默篡改，但无法阻止任何对 `case.json` 有写权限的人进行全面的覆盖重写和重新计算。 - [ ] 硬件写保护器检测/支持，而不仅仅是操作系统的 `WriteProtect` 注册表标志。 - [x] `analyzer.py`：真正的 pytsk3 实现，遍历镜像并通过 magic bytes + 删除元数据对可恢复文件进行分类。已针对手动构建的 FAT12 镜像（`tests/test_analyzer.py`）进行了测试，其中包含一个存活文件和一个按 FAT 实际删除方式删除的文件（0xE5 标记、释放的 FAT 链、目录项/数据原封不动），但仍需要针对真实的捕获镜像运行测试，而不仅仅是合成镜像。 **已知限制：** `recoverability="high"` 意味着 TSK 能够满足读取声明大小的数据，并不代表每一个字节都经过了原始内容验证。FAT 的反删除路径假定簇分配是连续的，如果被删除条目的大小字段已失效，TSK 会静默地在真实数据之后进行零填充而不是报错，在这一层面没有任何信号可以捕获这种情况。 - [x] `restore_screen.py`：通过 `analyzer.extract_file()` 将实际字节提取出来，而不仅仅是记录恢复意图。像镜像/分析一样在后台线程中运行，在每次尝试（包括失败的尝试）时，将恢复的字节数与预期字节数记录到 `case.record_restore()` 中，并且绝不对部分文件进行零填充（否则会歪曲恢复的内容）。 - [ ] `disk_enum.py`：在 Windows 上针对真实的 WMI 输出进行测试（目前是基于 API 编写的，尚未在真实硬件上运行过）。 - [x] 将 `gui/` 各个屏幕与 PySide6 真正连接起来（磁盘选择、确认、镜像进度、分析表格、恢复）。已进行冒烟测试（`tests/test_gui_smoke.py`），但仍需真实设备来进行端到端的镜像/分析路径验证。 - [ ] 证据保管链报告的 PDF 导出功能，目前仅支持 HTML。 ## 运行测试 ``` pip install -r requirements.txt pytest ```

标签：PySide6, 安全规则引擎, 审计日志, 数字取证, 磁盘镜像, 自动化脚本, 身份验证滥用, 逆向工具