Crow-Eye — Windows 取证引擎

Windows 的取证时间机器。
Crow-Eye 不仅仅是检测——它重建时间线上实际发生的事情，从数据采集一直到可追溯到源记录的可验证结论。

目录

• 概述
• ✨ 亮点
• 👥 Crow-Eye 适用人群
• 🧭 子系统一览
• 🏗️ 架构
• 📥 下载与安装
• 🚀 快速开始
• 📂 支持的取证工件
• 🔧 分析模式
  • 📎 导入证据（第三方数据）
• 🧠 用户行为分析（UBA）
• 🧩 关联引擎
• 👁️ Eye — 取证 AI 助手
• 📖 Eye-Describe — 字节级工件知识库
• 🧪 质量与验证
• 🔬 研究平台
• 🛠️ 技术说明
• 📸 截图
• 🚧 路线图
• 📚 文档
• 🤝 贡献
• 🌐 网站与社区
• 📄 许可证
• 📝 引用 Crow-Eye
• 💖 支持
• 致谢

概述

Crow-Eye 是一个开源（GPL-3.0）Windows 取证引擎，统一了采集、分析、验证、情报和 AI。 大多数安全工具会问 "这是否有害？" 然后清除一切看起来合法的内容。Crow-Eye 提出一个不同的问题："发生了什么？" 它关联所有活动——无论可疑与否——并重建系统上实际发生的事件序列，使调查的真相从证据中重建，而非从警报中猜测。

这种以重建为先的设计正是追踪 APT 和国家支持威胁所需要的：高级对手潜伏在合法工具（powershell.exe、PsExec、certutil）中，也隐藏在行动的序列里——这对那些清除一切看似正常内容的工具是不可见的。由于 Crow-Eye 从不清除任何内容，并且基于执行工件（这些工件在日志篡改和反取证手段下依然存在）进行推理，攻击无法隐藏。同一引擎也保持易用性，适用于日常 DFIR 工作和只想了解计算机上发生了什么的非专业人员。

• 🕰️ 重建，而非仅仅检测 — 重建实际发生事件的时间线。
• 🖥️ 跨平台 — 在 Windows 上支持完整的实时 + 离线分析；在 Linux 上支持离线分析和取证镜像解析（实时解析器仅限 Windows）。
• 🔒 天生隐私保护 — 0 毫秒数据离开设备；Eye AI 助手可完全在隔离环境中运行。
• 🧾 法庭级 — 证据经过加密密封，每一步都可审计。
• 📦 当前版本： 0.13.0 · 关联引擎： 1.7.0 · 许可证： GPL-3.0。

✨ 亮点

• 重建优先于检测。 将所有工件关联成一个可导航、按实体划分的完整故事，而非一堆警报。
• 端到端集成 — 采集 → 关联 → 时间线 → 行为分析 → AI → 密封的案件记忆：现有任何单一工具都无法覆盖的完整流水线。
• 工件深度，而非日志浅层。 Prefetch、Amcache、ShimCache、SRUM、MFT、USN、LNK/JumpLists 等工件能够抵御日志清除和"离地生存"技巧——这些技巧会让仅依赖日志的工具失明。
• Eye AI 助手 — 自然语言取证调查，具备可审计、防篡改的监管链，可在云端、私有服务器或完全离线环境中运行。
• 用户行为分析（UBA） — 将原始工件转化为通俗易懂、可供 HR/检查人员阅读的活动故事。
• 免费且开源（GPL-3.0） — 任何人都可审计，并有活跃的研究和文档工作。

👥 Crow-Eye 适用人群

Crow-Eye 被用于各种截然不同的工作流程。每种流程都通过不同的入口进入引擎：

任何采集器都适用。 Crow-Eye 不需要自己的采集工具。将离线导入器指向一个包含由 Velociraptor、KAPE、EDR 采集包或任何其他采集器生成的原始工件的文件夹——它会索引支持的工件并对其运行离线解析器。此外，来自 Plaso、Autopsy、Volatility 或任何其他工具的输出可通过导入证据以 CSV、JSON 或 SQLite 格式引入，并与原生工件一起关联。

🧭 子系统一览

Crow-Eye 构建为一个集成循环——每个阶段为下一阶段提供输入，从原始磁盘到可辩护的结论。

🏗️ 架构

Crow-Eye 是一个集成流水线，而非解析器的集合。证据单向流动，每个阶段都保持与源记录的链接。```mermaid %%{init: {"flowchart": {"nodeSpacing": 60, "rankSpacing": 70, "curve": "basis"}, "themeVariables": {"fontSize": "17px", "fontFamily": "system-ui, sans-serif"}} }%% flowchart TB

%% ═══════════ 1. EVIDENCE SOURCE ═══════════ S1["Live Windows system"] S2["Forensic image
E01 · VHDX · VMDK · Raw"] S3["Collected artifacts
Velociraptor · KAPE · EDR"] S4["Third-party output
Plaso · Autopsy · Volatility"]

%% ═══════════ 2. INGEST ═══════════ I1["CROW-CLAW
live acquisition"] I2["IMAGE PARSING
direct, no mounting"] I3["OFFLINE IMPORTER
SCAN → COLLECT → PARSE"] I4["IMPORT EVIDENCE
CSV · JSON · SQLite"]

REPLAY["DIRTY-HIVE REPLAY<br/>transaction logs applied to a working copy"]
PARSERS["ARTIFACT PARSERS<br/>18 artifact types · live and offline"]

%% ═══════════ 3. CASE ═══════════ CASE[("CASE DATABASES
Target_Artifacts/
Imported_Evidence/")]

%% ═══════════ 4. ANALYSIS ═══════════ TL["INTERACTIVE TIMELINE
heat map · week · day"] UB["USER BEHAVIOR ANALYTICS
40 detections · plain-English story"] CE["CORRELATION ENGINE
Feathers → Wings → Engines → Pipelines"] RES[("Correlation results")] DL["DYNAMIC LINKING
non-destructive enrichment overlay"] INTEL[("Crow_Intelligence.db
SID · MAC · hash · GUID → name")]

%% ═══════════ 5. AI LAYER ═══════════ EYE["EYE
GEP-governed AI assistant"] NM["NARRATIVE MAP
hash-chained case memory"] COMP["COMPLIANCE
live GEP status · EvidenceSeal audit"]

OUT["LIVING REPORT<br/>CSV · JSON · HTML"]

%% ═══════════ FLOW ═══════════ S1 --> I1 S2 --> I2 S3 --> I3 S4 --> I4

I1 --> PARSERS
I2 --> PARSERS
I3 --> PARSERS

PARSERS -- "every registry hive,<br/>evidence never written to" --> REPLAY
REPLAY -- "the state Windows<br/>had not finished writing" --> PARSERS

PARSERS -- "parsed artifacts" --> CASE
I4 -- "verbatim copy or<br/>converted to feather" --> CASE

CASE -- "read-only" --> TL
CASE -- "read-only" --> UB
CASE -- "read-only" --> CE
CASE -- "read-only" --> DL
CE --> RES
DL --> INTEL

CASE -- "read-only queries" --> EYE
RES -. "queried on demand" .-> EYE
EYE <== "verdict · narrative · evidence" ==> NM

EYE -- "audited by" --> COMP

EYE -- "report_* tools" --> OUT

%% ═══════════ STYLE ═══════════ classDef src fill:#334155,stroke:#94a3b8,stroke-width:2px,color:#f1f5f9 classDef ing fill:#0f766e,stroke:#2dd4bf,stroke-width:2px,color:#f0fdfa classDef store fill:#92400e,stroke:#fbbf24,stroke-width:3px,color:#fffbeb classDef ana fill:#1e40af,stroke:#60a5fa,stroke-width:2px,color:#eff6ff classDef ai fill:#6b21a8,stroke:#c084fc,stroke-width:2px,color:#faf5ff classDef out fill:#166534,stroke:#4ade80,stroke-width:2px,color:#f0fdf4

class S1,S2,S3,S4 src
class I1,I2,I3,I4,PARSERS ing
class CASE,RES,INTEL store
class TL,UB,CE,DL ana
class EYE,NM,COMP ai
class OUT out

linkStyle default stroke-width:2px

*证据来源 → 摄取 → 案件数据库 → 分析 → AI 层 → 报告*


**如何阅读：**

| 阶段 | 关键点 |
|---|---|
| ① → ② | **进入案件的四个独立入口。** 你永远不需要 Crow-Eye 自带的采集器——来自 Velociraptor、KAPE 或 EDR 包的文件夹可通过离线导入器处理，第三方 CSV/JSON/SQLite 则通过导入证据处理。 |
| ② → ③ | 一切汇聚到一个地方：**案件数据库**。解析后的工件落入 `Target_Artifacts/`；导入的第三方证据落入 `Imported_Evidence/` 并被自动发现。 |
| ③ → ④ | **三条分析路径彼此独立。** 时间线和 UBA 直接读取案件数据库——两者都不需要关联运行。关联引擎是一个*附加*层，而非前置条件。 |
| ③ → ④ | **动态关联与时间线和 UBA 并列**——它是案件数据库的第四个独立读取器（与时间线可视化无关）。它将身份映射（SID → 用户名、MAC → 网络、哈希/GUID → 应用）汇总到每个案件的 `Crow_Intelligence.db` 中，然后通过非破坏性的 `ATTACH` + `LEFT JOIN` 将该上下文**内联叠加到工件数据表中**。它改变的是记录的*呈现方式*，绝不改动证据本身。 |
| ④ → ⑤ | Eye 直接查询案件数据库，并可**按需**拉取关联结果。它从不直接接触证据——它发出工具调用，由 Crow-Eye 执行并记录。 |
| ⑤ → 报告 | **动态报告仅由 Eye 构建**，通过其 `report_*` 工具完成。时间线和 UBA 是分析界面——它们不写入报告。案件级发现仍可通过[搜索与导出](#-search--export)单独导出。 |
| ⑤ ↔ | **叙事图谱是双向的**：Eye 写入它，你也可以写入它，其内容每轮都会被注入到 Eye 的提示中。它是记忆，而你可以指挥它。 |
| ⑤ ⟳ | **合规页面审计 Eye。** Eye 的每一次工具调用都锚定在 **EvidenceSeal** 哈希链上；该页面根据该链和 `EYE_Logs/` 实时渲染每条规则的 **GEP** 状态（10 项原则），并可导出为 `audit_trail.json`。 |

**独立阶段。** 时间线和 UBA **直接**读取案件工件数据库——两者都不需要关联运行，且时间线不依赖关联引擎（它应用自己的轻量级时间分组）。关联是一个附加分析层，Eye 可查询其结果。

**只读设计。** 解析写入案件数据库；每个下游阶段（UBA、时间线、关联查看器、Eye）都以**只读**方式打开这些数据库。原始证据永不被修改——[动态关联](#-analysis-modes)读取案件数据库以构建每个案件的 `Crow_Intelligence.db` 身份映射，并通过非破坏性的 `ATTACH` + `LEFT JOIN` 查询内联丰富工件数据表，而非重写行。

**受治理设计。** Eye 采取的每一个行动都锚定在防篡改的 **EvidenceSeal** 哈希链上，**合规**页面持续依据[Ghassan Elsman 协议（GEP）](https://github.com/ghassan-elsman/crow-eye/blob/main/eye/docs/GEP_standard.md)验证 Eye——实时显示每条规则的状态，可导出到 `EYE_Logs/audit_trail.json`。

## 📥 下载与安装

> **推荐：** 从官方网站获取打包的 Windows 构建版（**MSI 安装程序 / EXE**）——无需 Python 环境，开箱即用。

### ▶️ [下载 Crow-Eye Windows 版 → crow-eye.com/download](https://crow-eye.com/download)

**已安装的 MSI/EXE 构建版是运行 Crow-Eye 的推荐方式**，也是我们**更新的最高优先级**：

- 🛡️ **最快的修复。** 当发现问题或报告 bug 时，我们会**尽快**发布更新的 EXE——打包构建版是修复最先落地的地方。
- 🔄 **内置自动更新。** 在已安装的应用中，打开**设置 → 更新**即可**检查更新并自动安装**——无需手动重装。
- 📦 **零配置。** 无需安装 Python、Node 或任何依赖。

> 更倾向于从源码运行？请参阅下方的**[快速开始](#-quick-start)**。从源码构建面向贡献者，**不包含自动更新器**——如需自动更新请使用 MSI/EXE。

## 🚀 快速开始

### 选项 A — 已安装构建版（推荐）
从 [crow-eye.com/download](https://crow-eye.com/download) 下载 **MSI/EXE**，安装后以管理员身份启动 **Crow-Eye**。创建案件并开始分析。

### 选项 B — 从源码运行（开发者）

> 面向贡献者和高级用户。此路径**不包含自动更新器**——如需自动更新请使用 MSI/EXE。

**要求**（首次运行时自动安装）：
- Python 3.12.4
- **Node.js 与 npm** — **时间线可视化**所需
- 关键包：PyQt5、python-registry、pywin32、pandas、streamlit、altair、olefile、windowsprefetch、sqlite3、colorama、setuptools

**推荐硬件**

| | 最低配置 | 大型案件推荐配置 |
|---|---|---|
| **内存** | 8 GB | 16 GB+（数百万条记录的 MFT/USN 数据集） |
| **磁盘** | 5 GB 可用空间 | 可用空间 ≥ 待解析证据大小的 2 倍 |
| **CPU** | 4 核 | 8+ 核 |
| **操作系统** | Windows 10/11（完整版）· Linux（离线与镜像分析） | — |

> 关联引擎以恒定内存流式处理超大数据集，因此内存很少成为硬性限制——磁盘吞吐量和可用空间通常是瓶颈。

**启动**（以管理员身份运行，以便 Crow-Eye 访问系统工件）：```bash
python "Crow Eye.py"

主界面打开后，您创建一个案件（case），所有分析输出都会组织在该案件目录下，供后续审查和报告使用。

🖥️ 跨平台说明： 在 Linux 上，实时解析器会被自动禁用，Crow-Eye 以 离线 / 取证镜像 模式运行。完整的实时采集仅限 Windows。

📂 支持的取证对象（Artifacts）

Crow-Eye 可解析广泛的 Windows 执行、文件系统和用户活动取证对象，既支持 实时 系统，也支持 离线 来源（已收集的文件夹或取证镜像）。

跳转列表和 LNK 由 Crow-Eye 自有的 专用 LNK / 跳转列表解析器 解析 — 而非第三方模块。

自定义注册表 / 被锁定的文件： Windows 在运行期间会锁定实时注册表配置单元（NTUSER.DAT、SOFTWARE、SYSTEM）。如需对实时系统进行自定义分析，请从外部介质（WinPE/Live CD）启动、使用取证采集工具，或分析磁盘镜像。

各取证对象详情

• 跳转列表和 LNK — 由 Crow-Eye 自有的专用解析器从标准系统位置自动解析（文件访问、目标路径、时间戳和元数据）。
• 注册表 — 自动解析系统配置单元。如需进行 自定义注册表分析，请将配置单元文件复制到 CrowEye/Artifacts Collectors/Target Artifacts（或您案件的 registry/ 文件夹）：
  • 来自 C:\Users\<用户名>\NTUSER.DAT 的 NTUSER.DAT
  • 来自 C:\Windows\System32\config\SOFTWARE 的 SOFTWARE
  • 来自 C:\Windows\System32\config\SYSTEM 的 SYSTEM
  • Windows 在运行期间会锁定这些文件 — 对于实时系统，请从外部介质（WinPE/Live CD）启动、使用取证采集工具，或分析磁盘镜像。
• Prefetch — 解析 C:\Windows\Prefetch，提取执行历史和取证元数据（包括每次运行的时间戳）。
• 事件日志 — 自动将系统/安全/应用程序日志解析到数据库中，以便进行全面分析。
• 注册表深度解析（0.13.0） — 解析器既读取配置单元 文件，也读取实时注册表，因此可以访问 winreg 即使对管理员也拒绝访问的内容（每个设备的 Properties 子键，以及其中的 USB 连接时间），遍历配置单元的内存分配器以恢复已删除的键和值，并读取类名和键安全描述符。此前包含真实数据但未被任何工具读取的 19 个键现在均被解析 — 包括 Explorer 的 StartupApproved，它表明每个自动启动条目是否实际被允许启动。
• ShellBags — 揭示文件夹访问历史和用户导航模式。
• 回收站 — 解析 $RECYCLE.BIN 以恢复已删除文件的名称、原始路径、删除时间和大小（实时系统和磁盘镜像）。
• MFT — 解析主文件表（Master File Table）以获取文件元数据、属性、时间戳和已删除文件信息（NTFS，Windows 7/10/11）。
• USN 日志 — 跟踪文件创建/修改/删除/重命名事件，含时间戳和完整名称历史，用于时间线重建。
• SRUM — 可视化应用程序资源使用情况（前台/后台时间的时长条）以及每个应用的网络活动。
• 存储取证分析器 — 每个物理磁盘及其分区的完整树状视图；颜色编码的分区类型（EFI、Linux、恢复、隐藏/交换分区等）；对可启动 USB、隐藏的 Linux 根分区和 Intel Rapid Start 发出警告；原始扇区魔数扫描回退机制。

🔧 分析模式

🦅 Crow-Claw 采集

Crow-Claw 是 Crow-Eye 的专用采集引擎，用于从实时系统或已挂载镜像中收集和保存取证对象。

• 选择性收集 — 选择特定的取证对象类别（注册表、事件日志、文件系统）或收集全部内容。
• 深度扫描 — 遍历目录和子目录以查找取证痕迹。
• 安全保存 — 取证对象被存放到结构化的案件目录中，以维护取证完整性。

🔍 离线分析（离线导入器）

分析从任何来源收集的取证对象，无需与目标建立实时连接 — 提供三种清晰的操作：

• SCAN（发现） — 遍历来源，并按 文件名和扩展名模式 索引每个受支持的取证对象（快速、只读；此阶段不读取文件内容，也不进行魔数检查）。不会移动任何内容。
• COLLECT（采集） — 将识别出的文件物理复制到案件的 live_acquisition 文件夹中，并按类型组织。
• PARSE（精细解析） — 按类型（AMCACHE、EVTX、PREFETCH 等）审查识别出的项目，并将所选文件（或全部）解析到取证数据库中。

解析由 Crow-Eye 专用的 离线解析器 处理 — 与实时模式使用相同的取证对象逻辑，但作用于已收集的文件：Prefetch、注册表、MFT、USN（以及 MFT/USN 关联器）、AmCache、ShimCache、SRUM、事件日志、LNK/跳转列表和回收站。

📎 导入证据（第三方数据）

除原始取证对象外，Crow-Eye 还可以将 第三方取证输出直接导入案件 — Plaso、Autopsy、Volatility 或任何自定义导出 — 并使其可供 Eye 和时间线使用，无需先运行关联流程。

由于案件数据库管理器会自动发现案件树下的任何 .db 文件，导入的证据会立即可用于：

• The Eye — 可与原生取证对象一起用自然语言查询（导入时会刷新架构清单）。
• 交互式时间线 — 作为 imported 取证对象类型提供，支持有效的时间窗口过滤和时间边界。
• 关联引擎 — 可作为 Feather 使用，用于与原生取证对象进行跨工具关联。

导入器仅使用标准库（sqlite3 / csv / json），并在后台工作线程上运行，因此大型导入不会阻塞界面。

⚡ 实时分析

直接从正在运行的 Windows 系统分析取证对象，从其标准位置自动提取，用于实时取证分析。

🗂️ 案件管理

每项调查都是一个 案件：一个自包含的目录，用于组织取证对象数据库和分析输出。Crow-Eye 会跟踪最近的案件（支持收藏、标签和状态），在打开时验证案件，以原子方式（崩溃安全）写入配置，并支持案件配置导入/导出以及带有现成语义映射的模板。

🕰️ 交互式时间线可视化

在统一的时间网格上跨取证对象关联事件，提供 热力图、周视图 和 日视图 — 呈现的是按身份线索串联、可在法庭上追溯的故事，而非扁平的超级时间线。

时间线 直接 读取案件的已解析取证对象数据库，并且 独立于 关联引擎 — 您无需构建 feathers、编写 wings 或运行流水线即可使用它。它应用自身的轻量级时间分组（精确时间戳和时间窗口关联，按应用程序、路径或用户分组）来关联网格上的事件。通过 导入证据 引入的证据也会以 imported 取证对象类型出现在时间线上，支持有效的时间窗口过滤和时间边界。

🔎 搜索与导出

跨案件数据库进行全文搜索，并可导出为 CSV（电子表格）、JSON（与其他工具集成）以及 详细 HTML 报告（整合与搜索词相关的每个取证对象的完整档案）。

🔗 动态链接

即时将原始技术标识符 — SID、MAC 地址、哈希值 — 转换为人类可读的上下文。动态链接使用 非破坏性的 SQL ATTACH 查询 来丰富视图，因此原始证据永远不会被修改，并且它可以摄取批量 IOC 威胁源，以内联方式标记已知恶意指标。

🧠 用户行为分析（UBA）

将原始取证对象转化为通俗易懂的活动故事 — 一份可供管理层/HR 阅读的账户，说明用户及其应用程序实际做了什么，且每项陈述都可追溯到确切的来源证据。

用户行为分析（UBA） 读取您案件 Target_Artifacts/ 文件夹中的已解析取证对象数据库（严格 只读），并通过一组声明式规则重放它们，以生成清晰、按时间顺序的 活动故事。可从 "User Behavior" 工具栏按钮或按 Ctrl+Shift+B 打开（必须已加载案件）。

• 🧩 40 项声明式行为检测（uba/config/behavior_rules.json）— 无需编写代码即可调整，每项均按严重性分类：常规 · 值得注意 · 可疑 · 严重。
• 🕵️ 检测重要行为：登录 / 注销 / 解锁、程序启动 · 执行 · 安装、文件打开 / 删除 / 推断复制、USB 设备连接、网络共享访问、持久化和自动启动、显式凭据使用（runas）、账户和组更改、服务更改、系统时钟篡改（可疑）以及 事件日志清除（严重）。
• 🗺️ 三种视图 — 活动故事 信息流、活动地图 热力图（天 × 小时），以及一份 "我们能看到的" 诚实报告，为本案中的每项检测标注 有效 / 有限 / 无数据 / 设计如此。
• 🔗 每项活动都有证据支持。 点击任意项目即可打开确切的支撑记录（database : table : rowid）— 没有来源就不会断言任何内容。
• 👤 诚实的归属。 行为主体解析为用户 / 应用程序 / 系统（或留空）— UBA 从不猜测谁做了什么。

检测覆盖范围

40 项检测涵盖四个严重性等级，并覆盖已解析取证对象集的全部范围：

过滤器： 自由文本搜索 · 用户/行为主体（包括"未归属"和已登录会话切换）· 行为类别（用户 / 应用程序 / 系统）· 严重性 · 应用程序（200+ 程序的可搜索多选）· 日期时间范围及快速预设（全部时间 / 第一天 / 最后一天 / 最后活动小时）。

数据来源： 安全、系统和应用程序事件日志 · USN 日志 · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / 跳转列表 · 回收站 · SRUM（应用程序、网络、连接）· 注册表配置单元。

取证保证

• 只读。 源数据库以只读方式打开；分析绝不会触碰证据。
• 完整溯源。 每个事件都携带 database → table → rowid，并可随时打开真实的源数据行。
• 归属从不猜测。 事件归属于用户、应用程序、系统 — 或留空。交互式登录会话仅用作上下文标签（"在 <用户> 的会话期间"），绝不用于归属某个操作。
• 诚实的措辞。 措辞区分有意交互（UserAssist、SRUM 前台）与应用程序也可能生成的取证对象（ShellBags、LNK、跳转列表），并在卡片上显示明确的注意事项。
• 缺失会被明确说明，而非暗示。 我们能看到的 报告会针对此特定案件标注每项检测，因此缺失数据绝不会被静默解读为"什么都没发生"。

UBA 是 规则驱动的行为关联和分类，而非统计/ML 异常评分 — 每项发现都对应一条明确、可审计的规则。完整检测目录请参阅 RELEASE_NOTES.md。

🧩 关联引擎

关联引擎 v1.7.0 — 重建核心。版本历史请参阅 RELEASE_NOTES.md。

Crow-Eye 关联引擎 是一个生产级取证关联系统。它从任何来源摄取 Windows 取证对象，将其规范化，并呈现时间和身份关系，将孤立的记录转化为关于系统上发生了什么、何时发生以及涉及谁的一致叙述。它开箱即用，内置针对最常见调查问题的关联规则（Wings），允许分析人员在不接触代码的情况下编写自定义规则，并将含义交由可编写的规则和调查人员决定 — 而非黑盒评分。

🎥 用户指南

通用数据导入：关联引擎可以接受 任何取证工具 以 CSV、JSON 或 SQLite 格式输出的结果，并将其转换为 Feather 数据库。这意味着您可以将第三方工具（Plaso、Autopsy、Volatility 等）的数据与 Crow-Eye 的原生取证对象进行关联，从而在所有取证数据源上创建统一的关联分析。

🎯 准确性与证据完整性

一次 自 0.11.0 周期起 的聚焦准确性验证，针对一个真实的约 70 万条记录的 Windows 案件进行了端到端验证，并叠加在此前可靠性工作的基础之上。以下每项修复均由 pytest 回归测试套件锁定，并通过整体验证框架验证；该框架测试了当时随附的七个默认 wings — 如今已随附十一个。下文引用的匹配计数是在该版本的规则下测量的：0.13.0 更改了匹配的定义（匹配现在必须跨越多个 feather）以及置信度评分的含义，因此请将其视为该次验证的记录，而非当前数据。

身份引擎捕获所有证据

• 已修复：启用时间过滤器时，身份引擎仅遍历每个 feather 的 FIRST 行（时区感知与朴素日期时间比较引发 TypeError 并中止了逐行循环）。验证案件中的已见记录数从 3,558 跃升至 745,615。
• 已修复：日志记录将每个事件折叠为其事件 PROVIDER 作为身份（全部 33,855 条 SecurityLogs 记录共享一个身份）。逐取证对象映射现在优先考虑真实的逐行实体（User、ComputerName、NewProcessName、TargetUserName），然后才是通道/提供程序元数据。
• 已修复：取证对象感知的字段映射从未触发，因为解析器不会在每行上标记 artifact 列。引擎现在回退到 feather_metadata.artifact_type，因此 SecurityLogs / SystemLogs / ApplicationLogs 使用其取证对象专属的身份优先级。
• 已修复：占位符字符串成为虚假身份（'N/A'、'Unknown'、'-'、nil-GUID 将不相关的记录捆绑在一起）。验证器现在拒绝 30+ 种占位符变体。
• 当时在一个全范围窗口上的净结果：Execution Proof wing 在身份引擎中浮现了 2,856 个跨 feather（高）匹配，在时间引擎中浮现了 643 个跨 feather 匹配，该版本的其他六个 wings 每个有 24–118 个跨 feather 匹配。

不再出现"一切都是 Low — 出问题了"

• 已修复：单 feather 匹配被标记为 High。 feather_count == 1 的匹配现在获得 confidence_category="Low - single feather"，因此 High 视图聚焦于真正的跨 feather 关联。
• 已修复：路径感知的复合键将同一身份拆分到多个 feather 中（每个 feather 以不同方式存储路径，因此 chrome 有 10+ 个键且从未关联）。键现在仅基于名称 — 跨 feather 关联恢复正常。

通过路径分类进行伪装检测 — 形成匹配后，引擎将每条记录的路径分类为 TRUSTED（Program Files、System32、WinSxS、BAM/SRUM 的 /device/harddiskvolumeN/... 形式等）或 SUSPICIOUS（Temp、Downloads、Public、AppData\Local\Temp、回收站、可移动根目录、网络共享）。跨越两种分类的匹配会引发 impersonation_alert（约 0.05% 的比率，每个都是真实候选）。诚实证据核算 — 一个按窗口划分的丢弃分类账，包含命名桶（no_identity_field、normalize_failure、below_threshold_skipped 等），外加每个管线的摘要（已见记录数、高/低置信度输出数、无身份记录数、丢弃桶、无时间戳羽毛连接数）。每条记录要么落入匹配结果，要么落入命名丢弃桶——"无证据遗漏"可从日志中验证。low_confidence_review_mode 默认开启，因此低于阈值的分组会变成低置信度匹配，而不是悄然消失。

无时间戳羽毛身份富集 — 没有逐行时间戳的羽毛（AutoStartPrograms、MUICache、SystemServices、TypedPaths）不再在每一行上打上伪造的生成时间戳；相反，在定时匹配形成后，引擎会按身份将每个无时间戳羽毛中的匹配记录连接起来，作为补充证据。

统一身份注册表 — config/standard_fields/identities.json 是引擎和 Eye 需要查询的每一列的唯一事实来源：98 个类别，1,146 个列同义词（应用/进程、文件、哈希、用户、主机/设备、网络、注册表、服务/任务、事件、电子邮件、浏览器、云、Windows 内部机制、证书、容器、操作系统对象）。添加新的列同义词只需编辑 JSON，无需修改代码。

语义映射误报修复 — 多指标门控现已真正强制执行（data-exfiltration-pattern 要求 ≥2 个指标）；不可能的 AND 规则（4625 AND 4624）改写为 OR；擦除器/远程工具规则使用真实正则表达式，而不是对每条 Prefetch 条目都触发；基线活动规则从 high/critical 降级为 info/low（该翼的加权评分会升级真正的威胁）。

✅ 生产状态

关联引擎已可投入生产，并积极用于调查中（关联引擎 v1.7.0）：

• ✅ 时间窗口扫描引擎 — 可投入生产，推荐用于基于时间的分析（O(N log N)）
• ✅ 基于身份的引擎 — 可投入生产，推荐用于身份追踪（O(N log N)）
• ✅ 羽毛构建器 / FeatherWriter — 从任何工具导入 CSV/JSON/SQLite；事务性批处理 + 模式元数据
• ✅ 翼系统与管线编排 — 创建/管理关联规则并自动化工作流
• ✅ 身份分组 — 在引擎、查看器和语义阶段之间统一
• ✅ 标准字段注册表 — 集中式字段同义词唯一事实来源
• ✅ 多时间戳扇出 — 每个 JSON 列表时间戳均被关联
• 🔄 并行关联 — 基础已就绪；性能剖析 + 进程池调度为下一步
• 🔄 语义映射与关联评分 — 持续增强中

主要特性

• 🔄 双引擎架构：在时间窗口扫描（O(N log N)）和基于身份（O(N log N)）关联策略之间选择。
• 📊 多工件支持：关联 Prefetch、ShimCache、AmCache、事件日志、LNK 文件、跳转列表、MFT、USN、SRUM、注册表、回收站等。
• 🔌 通用导入：从任何取证工具导入 CSV/JSON/SQLite 输出，并转换为羽毛数据库。
• 🎯 智能身份分组：Chrome.exe/chrome.dll/Chrome.EXE 等变体会合并为一个桶；版本和架构限定符保持区分。
• 🕒 宽容的时间戳解析：FILETIME、ISO 8601、Unix 纪元（秒/毫秒/微秒）、YYYYMMDD、美式斜杠格式以及带注释的字符串均能首次正确解析。
• 📈 多时间戳扇出：JSON 时间戳列表（Prefetch run_times）被展开，使每次执行都能获得自己的关联事件。
• 🧰 单一事实来源：字段同义词位于 config/standard_fields/*.json；每表元数据位于 correlation_engine/config/feather_schemas.json — 通过编辑 JSON 扩展，而非修改代码。
• ⚡ 流式 + 线程安全：O(1) 内存的 query_time_range_iter；带锁保护的羽毛缓存；为并行关联做好准备。
• 🔍 灵活规则：使用可配置参数定义自定义关联规则（翼）。
• 📋 诚实诊断：每窗口统计行（records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted），让您始终知道证据是否被丢弃。
• 🧪 锁定质量：一套 pytest 回归测试套件，涵盖时间戳解析、身份规范化、扇出、写入器契约、Eye 编写（写入侧 GEP 治理）以及标准字段注册表。

系统架构

关联引擎由四个主要组件组成：

1. 🗄️ 羽毛（数据规范化）

用途：将原始取证工件转换为标准化、可查询的格式。

• 包含规范化取证工件数据的 SQLite 数据库 — 每种工件类型一个羽毛（Prefetch、ShimCache、事件日志等），具有标准化模式和元数据，以便高效查询。
• 一种通用格式，可接受来自任何取证工具的数据。``` Any Tool Output → Feather Builder → Normalized Feather Database (CSV/JSON/SQLite) (SQLite with standard schema)

Examples:

• Plaso CSV → Feather Builder → timeline.db
• Autopsy JSON → Feather Builder → autopsy_artifacts.db
• Volatility CSV → Feather Builder → memory_artifacts.db
• Custom Output → Feather Builder → custom.db

**支持的导入格式：** CSV（任何带表头的文件）、JSON（扁平或嵌套）以及 SQLite（直接导入）。自动列映射、数据类型检测、时间戳标准化为 ISO、验证以及优化索引。```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Wings（关联规则）

用途：定义要关联哪些工件以及如何关联。

• JSON/YAML 规则，指定时间窗口、最小匹配数、锚点优先级以及要关联的 feathers（含权重）——可在多个案例中复用。每个 Wing 均可编写并封存（记录其作者、编写原因以及促成该规则的证据）。```json { "wing_id": "execution-proof", "wing_name": "Execution Proof", "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2, "anchor_priority": ["Prefetch", "SRUM", "AmCache"] }, "feathers": [ {"feather_id": "prefetch", "weight": 0.4}, {"feather_id": "shimcache", "weight": 0.3}, {"feather_id": "amcache", "weight": 0.3} ] }

#### 3. ⚙️ 引擎（关联策略）

**用途**：执行关联逻辑，以发现工件之间的关系。结构链接**优先**；在此基础上叠加分层加权评分，作为*解释/排序*依据，而非匹配的基础。

**时间窗口扫描引擎** — 最适合基于时间的分析和系统性时间关联。以固定时间间隔扫描时间轴，从每个窗口中的所有羽毛收集记录，应用语义字段匹配 + 加权评分，并通过 MatchSet 跟踪防止重复。**O(N log N)**（基于索引的时间戳查询）；批处理（约 2,567 个窗口/秒）。

**基于身份的关联引擎** — 最适合大型数据集（>1,000 条记录）和身份追踪。提取并规范化身份，按身份对记录分组，在每个聚类内构建时间锚点，将证据分类为主要/次要/辅助证据，并以恒定内存对超大型集合（>5,000 个锚点）进行流式处理。**O(N log N)**；每种类型支持 40+ 种身份字段模式。

**引擎选择**：时间分析使用时间窗口引擎，身份追踪使用基于身份的引擎——两者均已生产就绪，并通过索引查询针对大型数据集进行了优化。

#### 4. 🔄 流水线（工作流编排）

**用途**：自动化从羽毛创建到结果生成的完整分析工作流。流水线读取其配置（引擎类型、翼、羽毛），通过 EngineSelector 实例化正确的引擎，执行每个翼，聚合匹配结果，保存结果（数据库 + JSON），并在 GUI 中通过过滤和可视化进行展示。```json
{
  "pipeline_name": "Investigation Pipeline",
  "engine_type": "identity_based",
  "wings": [{"wing_id": "execution-proof"}, {"wing_id": "file-access"}],
  "feathers": [
    {"feather_id": "prefetch", "database_path": "data/prefetch.db"},
    {"feather_id": "srum", "database_path": "data/srum.db"},
    {"feather_id": "eventlogs", "database_path": "data/eventlogs.db"}
  ],
  "filters": {
    "time_period_start": "2024-01-01T00:00:00",
    "time_period_end": "2024-12-31T23:59:59"
  }
}

各部分如何协同工作```

1. Data Preparation Raw Forensic Data → Feather Builder → Feather Databases
2. Configuration Wing Configs + Feather References → Pipeline Config
3. Execution Pipeline Executor → Engine Selector → Correlation Engine
4. Correlation Engine loads Feathers + applies Wing rules → Correlation Results
5. Visualization Results Database → Results Viewer GUI

### 示例用例：查找执行证据

**场景**：证明 `malware.exe` 曾在系统上被执行。```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

由于没有提供具体的输入内容，我无法进行翻译。请提供需要翻译的文本。```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

I need the actual content of chunk 20 to translate it. Please provide the Markdown text you'd like translated from English to Chinese.```
Identity: malware.exe
  Anchor 1 (2024-01-15 10:30:00):
    ✓ Prefetch: malware.exe executed at 10:30:00
    ✓ ShimCache: malware.exe modified at 10:30:15
    ✓ AmCache:  malware.exe installed at 10:29:45

  Conclusion: Execution proven with 3 corroborating artifacts

性能基准

关联引擎快速入门

1. 启动：python -m correlation_engine.main
2. 创建羽毛（Feathers）：导入您的取证工件（Prefetch、ShimCache 等）。
3. 创建翅膀（Wings）：为您的调查定义关联规则。
4. 创建管道（Pipeline）：配置要使用的翅膀和羽毛。
5. 执行：运行管道并查看关联结果。
6. 分析：使用结果查看器探索时间关系。

📚 关联引擎文档

• 关联引擎概述 — 系统概述及架构图
• 引擎文档 — 双引擎架构、引擎选择、性能优化
• 架构 — 组件集成与数据流
• 羽毛文档 — 数据标准化系统
• 翅膀文档 — 关联规则
• 管道文档 — 工作流编排
• 添加工件 — 将新解析器接入引擎的工作流程
• 标准字段注册表 — 两个引擎及 Eye 加载的规范列名同义词
• 贡献指南 — 如何为引擎做出贡献
• 快速链接：引擎选择 · 故障排除 · 性能优化

👁️ Eye — 取证 AI 助手

一个强大的助手，而非替代品。 Eye 自动化并验证调查人员的假设——它永远不会替您做决定。

Eye 是 Crow-Eye 内置的取证 AI 助手：一位由真实 Windows 工件知识库支撑的资深取证调查员。它为您提供自然语言界面，用于查询、关联和记录案件中的一切——Prefetch、MFT、注册表、事件日志、AmCache、ShimCache、SRUM 等——同时保留一份可审计、防篡改的完整操作记录。Eye 可以完全在您自己的硬件上运行（包括完全物理隔离），符合 Crow-Eye 的**“0 毫秒数据离机”**隐私立场。完整架构：eye/README.md。

Eye 将对话式问题（“显示 22:00 之后从 C:\Temp 执行了什么”）转化为真实的取证工作：它规划方法、检索相关工件知识、对案件数据库运行 SQL 和跨工件搜索，并综合出经过验证的答案。每个答案同时产生于两个位置——一个是给您的聊天回复，另一个是写入实时报告工作区的结构化块，使案件档案随调查推进自动构建。

Ghassan Elsman 协议（GEP）

Eye 所做的一切都锚定于 Ghassan Elsman 协议（GEP）——一项供应商中立、工具无关的标准，规定了任何 AI 在数字取证中应如何使用。它包含10 项原则，符合标准的系统必须遵守，以确保 AI 辅助的发现保持真实、可追溯到源记录，并由可审计、防篡改的链条支撑，同时由人类调查员掌控：

Crow-Eye 的 Eye 是 GEP 的参考实现；支撑该协议的产品内行为称为操作规则。📜 阅读标准：eye/docs/GEP_standard.md。

部署模式

Eye 通过三种部署模式适应您的威胁模型：

在 CLI 代理模式下，Crow-Eye 驱动一个已有的 AI 终端/命令行代理作为模型——而非云端 API 或本地离线服务器——因此您可以用已在使用中的代理进行调查。

调查循环：

1. 打开或创建案件 — Eye 将自身限定于该案件的工件数据库和历史。
2. 用自然语言提问，或启动一键式全面分类。
3. Eye 运行其管道 — 检测意图 → 检索知识 → 执行工具 → 综合。
4. 您获得双重输出 — 直接的聊天回答以及实时报告中的新块。
5. 批准受限操作 — 导出和其他关键步骤等待您的签署。

您可以在运行时使用 switch_model 工具更换模型。切换仅限于同一后端，因此证据绝不会被静默发送到与您所选不同的提供商。

追踪 LLM 思考过程

Eye 的设计让您能够看到——并在之后证明——如何得出结论。Eye 工作时，会实时向 UI 流式传输结构化的 ThinkingStep 更新；每个更新携带 step_id、type、人类可读的 label、status（active → done，或 error）以及可选的 tool/params/detail。

典型查询展开为 thinking → rag → thinking → tool_call → synthesis，每个案件都会在磁盘上保留可事后检查的追踪工件：

工具执行

Eye 是工具驱动的：模型从不直接接触证据。它发出工具调用，Eye 针对案件数据库执行这些调用并返回结果——因此每个操作都是显式、已记录且可复现的。工具定义在 configs/llm_config.json 中，通过 eye/services/context_manager.py 分发。

调查工具 — 读取和分析证据：

报告工具构建实时报告工作区：report_append_section、report_add_data_table、report_add_chart、report_add_timeline、report_add_heatmap、report_add_chain_of_custody、report_add_chat_transcript、report_add_image、report_edit_section、report_delete_section、chat_add_table 和 export_report（导出需要人工批准）。

创作工具（受治理——参见构建关联翅膀与语义映射）：correlation_create_wing、correlation_edit_wing、correlation_create_semantic_mapping、correlation_edit_semantic_mapping。工具调用会被转换为活动后端所期望的格式——云端 API 和本地服务器使用原生函数调用，CLI 代理则使用 XML <tool_call> 包装器。

构建关联翅膀与语义映射

Eye 不仅查询关联引擎——它还能帮助扩展它。当 Eye 发现重复出现的跨工件模式时，它可以提出新的翅膀（关联规则）和语义映射（技术到人类的翻译）。这是受治理的创作：Eye 提出建议，分析人员审查保存的工件，每个更改都有理由支撑并有证据依据。

一个翅膀在时间窗口和最低匹配阈值内将羽毛关联起来以证明一项主张：

一个语义映射将原始技术值翻译为人类可读的含义（例如 EventID 4624 → “成功登录”）。它有两种形式：简单的 mapping（单个值/正则 → 语义值）或多条件的 rule（条件以 AND/OR 连接）。两者都支持 category、severity、confidence 和 scope，且都需要 reason + related_evidence。

治理——维护 GEP 的写入侧规则：

• 理由必填（维护 GEP-9 + GEP-2）：每次创建和编辑都必须包含取证 reason。
• 证据链接（维护 GEP-2）：每次创建必须引用至少一个 database:table:rowid 引用。
• Eye 盖章 / 其他内容只读（维护 GEP-7 + GEP-9）：Eye 标记其作者身份 + 理由 + 编辑历史，且只能编辑 Eye 自己创作的内容——内置和人工编写的规则保持只读。

自愈上下文

长时间调查可能超出模型的上下文窗口——尤其是较小的离线模型。Eye 不会崩溃或静默丢弃证据，而是在每次模型调用前自动压缩自身上下文（在其受保护的生成路径内，完全审计）。

每次调用前，Eye 测量完整载荷并为回复预留空间（窗口的 10%，最少 512 个 token，绝不超过一半）。如果仍无法容纳，它按两个有序步骤进行修复，绝不触碰受保护的消息（固定的、自动检测到的证据或工具结果）：

1. 摘要步骤 （一次） — 非受保护的历史折叠为一个摘要，记录为 SUMMARIZED。
2. 丢弃步骤 — 最旧的非受保护消息逐条移除，直到容纳为止，记录为 TRUNCATED。

如果不可缩减的证据核心（固定的 + 工具结果 + 当前问题）仍然溢出，Eye 拒绝继续而非截断证据（REFUSED_OVERFLOW），并请您缩小查询范围或使用 analyze_large_dataset。最终发送给模型的内容就是为监管链封存的精确载荷。

🗺️ 叙事地图 — Eye 的持久案件记忆

Eye 在轮次之间无状态——因此叙事地图是案件“我们所知与所结论”的存放之处。它是 Eye 的持久、可审计、防篡改的工作记忆，其内容在每一轮都被注入 Eye 的提示中（地图实际上就是记忆）。

• 🧭 裁决 → 叙事 → 证据。 严格的层级结构：一个案件裁决，其下的叙事（主张，每个带有状态——proven · open · negative · needs · absolute），以及其下由工件支撑的证据。
• 🪟 独立窗口。 从 Eye 聊天窗口中的**“叙事地图”**按钮打开，您可以并排查看聊天、实时报告和案件记忆；它会随变化实时刷新。
• ↔️ 双向——您可指挥的记忆。 Eye 的编辑和您自己的笔记都通过单一的 GEP 验证提交流动，并封存到哈希链式审计日志（narrative_map_audit.jsonl）中。您可以添加、编辑和删除其主张和证据，直接塑造 Eye 对案件的理解和解读。
• 🚫 绝不断言无支撑的内容。 Eye 的叙事在调查期间可以保持 open 且无证据，但绝不能在无证据的情况下变为 proven；Eye 检查过但发现为空的主题会自动转换为 negative——因为有记录的缺失本身就是一项发现。

合规性如何运作

合规不是事后附加的功能——它在管道中被强制执行。

• 🔗 监管链（证据封存）。 Eye 发送给 LLM 的每个载荷都被封存：精确字节的 SHA-256、token 计数、模型及其上下文限制，以及每个证据行的来源（database:table:rowid，加上 MFT 记录的计算偏移量）。封存是仅追加且哈希链式连接的，写入 <case>/EYE_Logs/eye_payload_seal.jsonl——单个被更改或删除的记录就会破坏链条，因此该日志在数学上证明了模型分析的是哪些字节。
• 🚫 无静默截断。 当上下文紧张时，Eye 自愈并按严格顺序重新分配预算：优先级 1（不可移动）：原始证据 + 系统提示 › 优先级 2（可牺牲）：随意对话 › 优先级 3（灵活）：RAG 上下文。如果证据核心仍无法容纳，Eye 拒绝而非静默丢弃证据。
• 🧾 截断审计追踪。 每个上下文决策都记录到 <case>/EYE_Logs/truncation_audit.log（SUMMARIZED、TRUNCATED、PRESERVED、PINNED、UNPINNED、BUDGET_REDUCED），每个都带有哈希。检测到的证据在置信度阈值以上自动固定；您也可以手动固定消息。
• 📑 证据到报告的任务。 Eye 必须在聊天中回答并将支撑证据持久化到报告中；未能记录证据会被标记为协议违规。
• ⚖️ 关联治理。 Eye 创作的任何翅膀或映射都必须包含取证 reason 和 related_evidence；Eye 之外编写的规则为只读，不能被静默重写。
• 🔐 隐私与物理隔离。 在离线模式下，Eye 零出站调用；云端 API 密钥存储在操作系统原生钥匙串中——绝不硬编码，绝不写入日志。

📖 完整 Eye 架构： eye/README.md。

📖 Eye-Describe — 字节级工件知识库

🔗 探索 Eye-Describe → crow-eye.com/eye-describe

历史上，调查人员常陷入信任取证工具而不理解底层工件行为或工具如何解析它们的陷阱。今天的风险只是将*“工具”替换为“AI”*。AI 可以以完美的技术准确性解析一条记录，却仍将其置于错误的上下文中——从而改变证据的整个含义。

Eye-Describe 的存在是为了让人类和模型都无需猜测。它是 Windows 工件原始二进制结构的交互式字节级参考，同时扮演两个角色：

通过将 AI 层锚定到已记录的工件行为，Crow-Eye 不是在要求您信任模型——而是在约束模型尊重原始取证。

不要用对 AI 的信任取代对工具的信任。理解数据。

🧪 质量与验证

取证工具只有在输出可辩护时才有用。Crow-Eye 的正确性工作刻意保持可见：- 回归测试套件。 关联引擎由一套 pytest 套件锁定，覆盖时间戳解析、身份归一化、多时间戳扇出、写入器契约、Eye 编写（写入侧 GEP 治理）以及标准字段注册表。UBA 引擎自带其测试套件，包括针对真实案例的端到端运行。

• 验证测试平台。 一个整体测试平台在真实的约 70 万条记录的 Windows 案例上，对两个引擎运行全部 7 个默认翼。
• 已发布的缺陷历史。 准确性回归及其测量影响在 RELEASE_NOTES.md 中公开记录——包括修复使记录可见数发生数量级变化的案例。了解问题所在及发生时间，是使结果具有可辩护性的重要组成部分。
• 可验证的证据核算。 每条记录要么落入匹配结果，要么落入指定的丢弃桶，而按窗口的丢弃账本使“无遗留证据”成为可从日志中核查的事项，而非仅凭信任。
• 防篡改日志。 verify_chain() 会重新遍历 Narrative Map 审计日志和证据封条链，以检测修改——包括对人类可读字段的修改。

🔬 研究平台

Crow-Eye 不仅仅是软件——它是一个开放研究平台，加速整个 Windows 取证领域的发展。该项目专注于：

• 发布关于内部工件结构的详细文档。
• 共享关联逻辑和方法论。
• 支持同行评审、透明度和学术合作。
• 为取证社区的共同知识做出贡献。

🛠️ 技术说明

• 注册表解析需要完整的注册表配置单元文件。
• 由于 Windows 文件锁定机制，某些工件需要特殊处理（参见 自定义注册表 / 锁定文件）。
• LNK 和跳转列表解析由 Crow-Eye 自有的专用解析器处理。

📸 截图

Crow-Eye 界面和分析视图精选。

🎥 演示视频：

🚧 路线图

计划中及进行中的工作（已发布变更参见 RELEASE_NOTES.md）：

• 📊 高级 GUI 视图与报告 — 更丰富的可视化和报告功能。
• 🔄 增强的搜索对话框 — 支持自然语言的高级过滤。
• 🎯 增强的语义映射 — 覆盖所有工件类型的全面字段映射。
• 📈 高级关联评分 — 精细化、可解释的置信度评分。
• ⚡ 并行关联 — 进程池调度，默认对大型工作负载启用。

有想法或想添加工件？提交 Issue 或参见 贡献。

📚 文档

• TECHNICAL_DOCUMENTATION.md — 架构、组件和开发指南。
• RELEASE_NOTES.md — 每个版本的新增内容（UBA、Narrative Map、云 Eye 后端、案例管理加固……）。
• 关联引擎文档 — 概述、引擎、feathers、wings、pipelines。
• 时间线架构 — 时间线模块内部机制。
• Eye 架构 和 GEP 标准 — AI 助手及其治理协议。

🤝 贡献

Crow-Eye 作为开放研究平台构建，欢迎各类贡献——新的解析器、关联规则、文档和工件研究。

• 一般贡献： CONTRIBUTING.md
• 关联引擎（优先领域）： correlation_engine/CONTRIBUTING.md
• 联系方式： [email protected] · 或提交 Issue / 拉取请求。

🌐 网站与社区

• 🌍 官方网站： crow-eye.com — 资源、文档和下载。
• 💬 Discord： 加入 Crow-Eye Discord — 直接获取帮助、工件研究和版本发布公告。

📄 许可证

Crow-Eye 根据 GNU General Public License v3.0（GPL-3.0）发布。在该许可证条款下，可自由使用、研究、共享和修改。

📝 引用 Crow-Eye

如果您在学术工作、已发表研究或案例报告中使用了 Crow-Eye，请引用：```bibtex @software{elsman_crow_eye, author = {Elsman, Ghassan}, title = {Crow-Eye: A Windows Forensics Engine}, url = {https://github.com/Ghassan-elsman/Crow-Eye}, license = {GPL-3.0}, year = {2026} }

Elsman, G. *Crow-Eye: A Windows Forensics Engine*（GPL-3.0）。https://github.com/Ghassan-elsman/Crow-Eye

关于方法学引用，Ghassan Elsman 协议在 [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/main/eye/docs/GEP_standard.md) 中单独记录。

## 💖 支持

Crow-Eye 是免费开源的，由一人构建和维护。如果它对您的工作有帮助，请考虑赞助——这将直接资助新的解析器和研究：**[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/main/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**。

## 致谢

由 **Ghassan Elsman** 创建并维护。