Crow-Eye — Windows 取证引擎

Windows 取证时间机器。
Crow-Eye 不只是检测——它会在时间线上重建实际发生的事件，从取证采集一直到可溯源至原始记录的证据判定。

目录

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

概述

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

这种以重建为先的设计正是追捕 APT 和国家资助型威胁 所需要的：老练的攻击者隐藏在合法工具（powershell.exe、PsExec、certutil）和行动的顺序里——这对那些清除一切看似正常内容的工具是不可见的。由于 Crow-Eye 从不清除任何内容，并且基于执行取证对象（artifacts，它们能在日志篡改和反取证手段下幸存）进行推理，攻击无法隐藏。同一引擎对日常 DFIR 工作以及只想了解电脑上发生了什么事的非专家来说同样易于上手。

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

✨ 亮点

• 以重建代替检测。 将所有取证对象关联为一个可导航、按实体划分的完整故事，而不是一大堆告警。
• 端到端集成 —— 采集 → 关联 → 时间线 → 行为分析 → AI → 封存案件记忆：这是任何单一现有工具都无法覆盖的完整流程。
• 深度到取证对象，而非浅层日志。 Prefetch、Amcache、ShimCache、SRUM、MFT、USN、LNK/JumpLists 等都能在日志清除和“living-off-the-land”手段下幸存，而这些手段会让仅依赖日志的工具失明。
• 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"]

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 -- "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 包的文件夹通过 Offline Importer 导入，第三方 CSV/JSON/SQLite 通过 Import Evidence 导入。 |
| ② → ③ | 一切汇聚于一处：**案例数据库**。解析后的痕迹存放在 `Target_Artifacts/`；导入的第三方证据存放在 `Imported_Evidence/`，并会被自动发现。 |
| ③ → ④ | **三条分析路径彼此独立。** Timeline 和 UBA 直接读取案例数据库——两者都不需要运行关联分析。Correlation Engine 是一个*额外*的层，而非先决条件。 |
| ③ → ④ | **Dynamic Linking 与 Timeline 和 UBA 并列**——它是案例数据库的第四个独立读取器（与时间线可视化无关）。它把身份映射（SID → 用户名，MAC → 网络，哈希/GUID → 应用）收集到每个案例的 `Crow_Intelligence.db` 中，然后通过非破坏性的 `ATTACH` + `LEFT JOIN` 将该上下文**内联叠加到痕迹数据表中**。它改变的是记录的*读取*方式，绝不会改变证据。 |
| ④ → ⑤ | Eye 直接查询案例数据库，并可**按需**获取关联结果。它从不接触证据本身——而是发出工具调用，由 Crow-Eye 执行并记录。 |
| ⑤ → Report | **Living Report 仅由 Eye 构建**，通过其 `report_*` 工具完成。Timeline 和 UBA 是分析界面——它们不会写入报告。案例级发现仍可通过 [Search & Export](#-search--export) 单独导出。 |
| ⑤ ↔ | **Narrative Map 是双向的**：Eye 可以写入，你也可以写入，且其内容会每一轮注入到 Eye 的提示词中。它就是记忆，你可以指挥它。 |
| ⑤ ⟳ | **合规页面审计 Eye。** Eye 的每次工具调用都与 **EvidenceSeal** 哈希链锚定；该页面根据该链和 `EYE_Logs/` 实时渲染逐规则 **GEP** 状态（10 项原则），并可导出为 `audit_trail.json`。 |

**独立阶段。** Timeline 和 UBA **直接**读取案例痕迹数据库——两者都不需要运行关联分析，且 Timeline 不依赖 Correlation Engine（它应用自身轻量级的时间分组）。关联分析是一个额外的分析层，Eye 可以查询其结果。

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

**设计上的受管。** Eye 的每一个动作都与防篡改的 **EvidenceSeal** 哈希链锚定，**合规页面**持续对照 [Ghassan Elsman Protocol (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) 验证 Eye——实时逐规则状态，可导出到 `EYE_Logs/audit_trail.json`。

## 📥 下载与安装

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

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

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

- 🛡️ **最快的修复。** 一旦发现问题或收到错误报告，我们会**尽快**发布更新的 EXE——打包版本是修复首发之地。
- 🔄 **内置自动更新。** 在已安装的应用中，打开 **Settings → Updates** 即可**自动检查并安装更新**——无需手动重装。
- 📦 **零配置。** 无需安装 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** — 用于 **Timeline Visualization**
- 关键包：PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**推荐硬件**

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

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

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

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

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

📂 支持的痕迹（Artifacts）

Crow-Eye 解析大量 Windows 执行、文件系统和用户活动痕迹，既可来自**实时（live）系统，也可来自离线（offline）**来源（收集的文件夹或取证镜像）。

Jump Lists 和 LNK 由 Crow-Eye 自有的专用 LNK / Jump List 解析器解析——而非第三方模块。

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

各项痕迹详情

• Jump Lists 与 LNK — 由 Crow-Eye 自有的专用解析器从标准系统位置自动解析（文件访问、目标路径、时间戳和元数据）。
• 注册表（Registry） — 自动解析系统配置单元。如需自定义注册表分析，请将配置单元文件复制到 CrowEye/Artifacts Collectors/Target Artifacts（或您案件的 registry/ 文件夹）：
  • 来自 C:\Users\<Username>\NTUSER.DAT 的 NTUSER.DAT
  • 来自 C:\Windows\System32\config\SOFTWARE 的 SOFTWARE
  • 来自 C:\Windows\System32\config\SYSTEM 的 SYSTEM
  • Windows 在运行期间会锁定这些文件——对于实时系统，请从外部介质（WinPE/Live CD）启动、使用取证获取工具，或分析磁盘镜像。
• Prefetch — 解析 C:\Windows\Prefetch，提取执行历史和取证元数据（包括每次运行的时间戳）。
• 事件日志（Event Logs） — 自动将系统/安全/应用程序日志解析到数据库中，以便进行全面分析。
• ShellBags — 揭示文件夹访问历史和用户导航模式。
• 回收站（Recycle Bin） — 解析 $RECYCLE.BIN，以恢复已删除的文件名、原始路径、删除时间和大小（实时系统和磁盘镜像）。
• MFT — 解析主文件表（Master File Table），获取文件元数据、属性、时间戳和已删除文件信息（NTFS，Windows 7/10/11）。

🔧 分析模式

🦅 Crow-Claw 获取（Acquisition）

Crow-Claw 是 Crow-Eye 的专用获取引擎，用于从实时系统或挂载镜像中收集和保存痕迹。

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

🔍 离线分析（Offline Importer）

无需与目标建立实时连接，即可分析从任何来源收集的痕迹——共三个清晰的操作：

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

解析由 Crow-Eye 专用的离线解析器处理——与实时模式相同的痕迹逻辑，作用于收集到的文件：Prefetch、Registry、MFT、USN（以及 MFT/USN 关联器）、AmCache、ShimCache、SRUM、Event Logs、LNK/JumpLists 和 Recycle Bin。

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

除了原始痕迹之外，Crow-Eye 还能将第三方取证输出直接导入案件——Plaso、Autopsy、Volatility 或任何自定义导出——并使其可供 Eye 和时间线（Timeline）使用，无需先运行关联操作。

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

• Eye — 可与原生痕迹一起用自然语言查询（导入时会刷新模式清单）。
• 交互式时间线（Interactive Timeline） — 以 imported 痕迹类型提供，支持窗口时间过滤和时间边界。
• 关联引擎（Correlation Engine） — 可作为 Feather 使用，与原生痕迹进行跨工具关联。

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

⚡ 实时分析（Live Analysis）

直接从正在运行的 Windows 系统分析痕迹，从其标准位置自动提取，以进行实时取证分析。

🗂️ 案件管理（Case Management）

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

🕰️ 交互式时间线可视化（Interactive Timeline Visualization）

在统一的时间网格上跨痕迹关联事件，提供热力图（Heat Map）、**周（Week）和日（Day）**视图——按身份线索串联、可在法庭上追溯的故事，而非扁平的超级时间线。

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

🔎 搜索与导出（Search & Export）

对案件数据库进行全文搜索，并可导出为 CSV（电子表格）、JSON（与其他工具集成）以及详细 HTML 报告（汇总与搜索词相关的所有痕迹的完整档案）。

🔗 动态关联（Dynamic Linking）

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

🧠 用户行为分析（User Behavior Analytics，UBA）

将原始痕迹转化为通俗易懂的活动叙事——以管理者/HR 可读的方式说明用户及其应用程序实际做了什么，每一条陈述都可追溯到确切来源证据。

用户行为分析（UBA）读取您案件 Target_Artifacts/ 文件夹中已解析的痕迹数据库（严格只读），并通过声明式规则集重放这些数据，生成清晰的按时间顺序排列的活动叙事（Activity Story）。可从**“用户行为（User Behavior）”**工具栏按钮或使用 Ctrl+Shift+B 打开（必须已加载案件）。

• 🧩 40 项声明式行为检测（uba/config/behavior_rules.json）——无需编码即可调优——每项按严重程度分类：常规（routine）· 值得关注（notable）· 可疑（suspicious）· 严重（critical）。
• 🕵️ 检测关键行为：登录 / 注销 / 解锁、程序启动 · 执行 · 安装、文件打开 / 删除 / 推断复制、USB 设备连接、网络共享访问、持久化与自启动、显式凭据使用（runas）、账户与组更改、服务更改、系统时钟篡改（可疑）和事件日志清除（严重）。
• 🗺️ 三种视图——**活动叙事（Activity Story）**信息流、**活动地图（Activity Map）热力图（天 × 小时），以及“我们能看到的（What we can see）”**诚实报告，针对当前案件将每项检测标记为工作正常（Working）/ 有限（Limited）/ 无数据（No data）/ 设计如此（By design）。
• 🔗 **每项活动都有证据支持。**点击任意项目即可打开确切的支持记录（database : table : rowid）——没有来源就不会断言任何事情。
• 👤 **诚实的归因。**行为主体解析为用户 / 应用程序 / 系统（或留空）——UBA 从不猜测是谁做了什么。

检测覆盖范围（Detection Coverage）

这 40 项检测横跨四个严重程度等级，并覆盖已解析痕迹集的全部范围：

**筛选器：**自由文本搜索 · 用户/行为主体（包括“未归因（Unattributed）”和已登录会话开关）· 行为类别（用户 / 应用程序 / 系统）· 严重程度 · 应用程序（跨 200+ 程序的可搜索多选）· 日期时间范围及快速预设（全部时间 / 第一天 / 最后一天 / 最后活动小时）。

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

取证保证（Forensic Guarantees）

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

UBA 是规则驱动的行为关联与分类，而非统计/机器学习异常打分——每项发现都映射到一条明确、可审计的规则。完整的检测目录请参阅 RELEASE_NOTES.md。

🧩 关联引擎（Correlation Engine）

Correlation Engine v1.7.0 ——重建核心。发布历史请参阅 RELEASE_NOTES.md。

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

🎥 用户指南（User Guide）

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

🎯 准确性与证据完整性（Accuracy & Evidence-Completeness）

一次专注的准确性提升，针对一个真实的约 70 万条记录的 Windows 案件进行了端到端验证，并叠加在此前的可靠性工作之上。下方每项修复均由 pytest 回归测试套件锁定，并通过一个全面的验证框架进行验证，该框架在两个引擎上都会运行全部 7 个默认 wing。

身份引擎捕获所有证据

• 修复：身份引擎在时间筛选器激活时只遍历每个 feather 的第一行（时区感知与非时区感知的 datetime 比较会引发 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（High）匹配，在时间引擎中产生 643 条跨 feather 匹配，其余 6 个 wing 每个产生 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 等），以及每个流水线的摘要（已见记录数、产生的高/低置信度匹配、无身份、丢弃桶、无时间戳 feather 联接）。每条记录要么落入匹配，要么落入一个命名的丢弃桶——“无证据遗漏”可从日志中验证。low_confidence_review_mode 默认开启，因此低于阈值的组会变为低置信度匹配，而不是悄然消失。

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

整合的身份注册表——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（wing 的加权评分会升级真实威胁）。

✅ 生产状态（Production Status）

关联引擎已完成生产就绪，并已在调查中积极使用（Correlation Engine v1.7.0）：- ✅ 时间窗口扫描引擎 — 生产就绪，推荐用于基于时间的分析（O(N log N)）

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

主要特性

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

系统架构

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

1. 🗄️ Feathers（数据归一化）

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

• 包含归一化取证工件数据的 SQLite 数据库 — 每种工件类型一个 feather（Prefetch、ShimCache、Event Logs、…），具有标准化的 schema 和元数据，以便高效查询。
• 一种 通用格式，可接受来自任何取证工具的数据。``` 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（关联规则）

目的：定义要关联哪些工件（artifacts）以及如何关联。

• 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. ⚙️ 引擎（关联策略）

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

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

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

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

#### 4. 🔄 管道（工作流编排）

**目的**：自动化从 feather 创建到结果生成的完整分析工作流。管道读取其配置（引擎类型、wings、feathers），通过 EngineSelector 实例化正确的引擎，执行每个 wing，聚合匹配结果，保存结果（DB + 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"]
}

The input is empty — there is no content to translate. Please provide the source chunk text.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

输入：```
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：配置要使用的 wings 和 feathers。
5. 执行：运行 pipeline 并查看关联结果。
6. 分析：使用结果查看器探索时间关系。

📚 关联引擎文档

• 关联引擎概览 —— 系统概览与架构图
• 引擎文档 —— 双引擎架构、引擎选择、性能优化
• 架构 —— 组件集成与数据流
• Feather 文档 —— 数据规范化系统
• Wings 文档 —— 关联规则
• Pipeline 文档 —— 工作流编排
• 添加工件 —— 将新解析器接入引擎的工作流
• 标准字段注册表 —— 由两个引擎和 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 运行其 pipeline——检测意图 → 检索知识 → 执行工具 → 综合生成。
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（导出需要人工批准）。

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

构建关联 Wings 与语义映射

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

一个 Wing 在时间窗口和最小匹配阈值内将 feathers 联系起来，以证明某个断言：

一个语义映射将原始技术值翻译为人类可读的含义（例如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——因为有记录的缺失本身就是一个发现。

合规机制如何运作

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

• 🔗 监管链（证据封条）。 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 编写的任何 Wing 或映射都必须包含取证 reason 和 related_evidence；在 Eye 之外编写的规则是只读的，不能被静默重写。

📖 完整 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 个默认 wings。
• 公开的缺陷历史。 准确性回归及其可测量的影响在 RELEASE_NOTES.md 中公开记录——包括修复使所见记录数改变几个数量级的案例。知道哪里出了问题、何时出问题，正是结果可辩护的一部分。
• 可验证的证据核算。 每条记录要么落入匹配结果，要么落入指定的丢弃桶，按窗口的丢弃分类账让“没有遗留证据”成为您可以从日志中核查而非仅凭信念接受的事项。
• 防篡改日志。 verify_chain() 会重新遍历叙事图谱审计日志和证据封条链以检测篡改——包括对人类可读字段的修改。

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

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

🛠️ 技术说明

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

📸 截图

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

🎥 演示视频：

🚧 路线图

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

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

有想法或想添加一个痕迹？打开一个 issue 或参阅 参与贡献。

📚 文档

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

🤝 参与贡献

Crow-Eye 作为开放研究平台而构建，欢迎任何形式的贡献 — 新的解析器、关联规则、文档和痕迹研究。

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

🌐 网站与社区

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

📄 许可证

Crow-Eye 在 GNU 通用公共许可证 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：一款 Windows 取证引擎*（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/HEAD/eye/docs/GEP_standard.md) 中单独记录。

## 💖 支持

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

## 致谢

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