Crow-Eye — Windows Forensics Engine

Криминалистическая машина времени для Windows.
Crow-Eye не просто обнаруживает — он реконструирует, что именно произошло на временной шкале: от сбора данных до вердикта, прослеживаемого до исходных записей.

Оглавление

• Обзор
• ✨ Ключевые возможности
• 👥 Для кого предназначен Crow-Eye
• 🧭 Подсистемы вкратце
• 🏗️ Архитектура
• 📥 Скачать и установить
• 🚀 Быстрый старт
• 📂 Поддерживаемые артефакты
• 🔧 Режимы анализа
  • 📎 Импорт доказательств (сторонние данные)
• 🧠 Аналитика поведения пользователей (UBA)
• 🧩 Механизм корреляции
• 👁️ Eye — криминалистический ИИ-ассистент
• 📖 Eye-Describe — база знаний об артефактах на уровне байтов
• 🧪 Качество и валидация
• 🔬 Исследовательская платформа
• 🛠️ Технические заметки
• 📸 Скриншоты
• 🚧 Дорожная карта
• 📚 Документация
• 🤝 Участие в разработке
• 🌐 Сайт и сообщество
• 📄 Лицензия
• 📝 Цитирование Crow-Eye
• 💖 Поддержка
• Credits

Обзор

Crow-Eye — это движок криминалистики Windows с открытым исходным кодом (GPL-3.0), объединяющий сбор данных, анализ, проверку, разведку и ИИ. Большинство инструментов безопасности спрашивают «это вредоносно?» и вычёркивают всё, что выглядит легитимным. Crow-Eye задаёт другой вопрос: «что произошло?» Он коррелирует всю активность — подозрительную или нет — и реконструирует фактическую последовательность событий в системе, чтобы истина расследования восстанавливалась из улик, а не угадывалась по оповещениям.

Именно такой подход — реконструкция в первую очередь — необходим для охоты на APT и угрозы уровня национальных государств: изощрённые противники живут внутри легитимных инструментов (powershell.exe, PsExec, certutil) и в последовательности действий, что невидимо для инструментов, отбрасывающих всё, что выглядит нормально. Поскольку Crow-Eye ничего не отбрасывает и рассуждает на основе артефактов исполнения (которые переживают подчистку логов и антикриминалистику), атака не может спрятаться. Этот же движок остаётся доступным для повседневной работы по DFIR и для неспециалистов, которые просто хотят узнать, что произошло на компьютере.

• 🕰️ Реконструкция, а не просто обнаружение — восстанавливайте временную шкалу того, что действительно произошло.
• 🖥️ Кроссплатформенность — полный живой и офлайн-анализ на Windows; офлайн-анализ и разбор криминалистических образов на Linux (живые парсеры доступны только в Windows).
• 🔒 Конфиденциальность по замыслу — 0 мс данных не покидает устройство; ИИ-ассистент Eye может работать полностью в изолированной среде (air-gapped).
• 🧾 Уровень суда — доказательства криптографически опечатываются, и каждый шаг проверяем.
• 📦 Текущая версия: 0.12.6 · Механизм корреляции: 1.7.0 · Лицензия: GPL-3.0.

✨ Ключевые возможности

• Реконструкция вместо обнаружения. Связывает все артефакты в одну навигируемую историю по каждой сущности, а не в кучу оповещений.
• Интегрирован от начала до конца — сбор → корреляция → временная шкала → аналитика поведения → ИИ → опечатанная память дела: полный конвейер, который не охватывает ни один отдельный существующий инструмент.
• Глубина артефактов, а не поверхность логов. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists и другие переживают подчистку логов и приёмы «living-off-the-land», которые ослепляют инструменты, работающие только с логами.
• ИИ-ассистент Eye — расследование на естественном языке с проверяемой цепочкой хранения доказательств, защищённой от подделки; работает в облаке, на приватном сервере или полностью офлайн.
• Аналитика поведения пользователей (UBA) — превращает сырые артефакты в понятную историю действий на простом английском языке, доступную HR и экспертам.
• Бесплатно и с открытым исходным кодом (GPL-3.0) — может быть проверен кем угодно, при активных исследовательских и документационных усилиях.

👥 Для кого предназначен Crow-Eye

Crow-Eye используется в самых разных рабочих процессах. Каждый из них входит в движок через свою дверь:

Работает с любым коллектором. Crow-Eye не требует собственного инструмента сбора. Укажите офлайн-импортёру папку с сырыми артефактами, созданными Velociraptor, KAPE, пакетом сбора EDR или любым другим коллектором, — он индексирует поддерживаемые артефакты и запускает по ним офлайн-парсеры. Отдельно выходные данные Plaso, Autopsy, Volatility или любого другого инструмента можно импортировать в виде CSV, JSON или SQLite через Import Evidence и коррелировать наряду с собственными артефактами.

🧭 Подсистемы вкратце

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

*Источник доказательств → Приём данных → Базы данных дела → Анализ → ИИ-слой → Отчёт*


**Как это читать:**

| Этап | Что важно |
|---|---|
| ① → ② | **Четыре независимых входа в дело.** Вам никогда не понадобится собственный сборщик Crow-Eye — папка от Velociraptor, KAPE или EDR-пакета проходит через Offline Importer, а сторонние CSV/JSON/SQLite — через Import Evidence. |
| ② → ③ | Всё сходится в одном месте: **базы данных дела**. Разобранные артефакты попадают в `Target_Artifacts/`; импортированные сторонние доказательства попадают в `Imported_Evidence/` и автоматически обнаруживаются. |
| ③ → ④ | **Три пути анализа независимы друг от друга.** Timeline и UBA читают базы данных дела напрямую — ни один не требует запуска корреляции. Correlation Engine — это *дополнительный* слой, а не обязательное условие. |
| ③ → ④ | **Dynamic Linking находится рядом с Timeline и UBA** — четвёртый независимый читатель баз данных дела (он не имеет отношения к визуализации Timeline). Он собирает сопоставления идентификаторов (SID → имя пользователя, MAC → сеть, hash/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. Это память, и вы можете им управлять. |
| ⑤ ⟳ | **Страница Compliance проверяет Eye.** Каждый вызов инструмента, который делает Eye, привязан к защищённой от вмешательства хэш-цепочке **EvidenceSeal**; страница отображает в реальном времени статус **GEP** по каждому правилу (10 принципов), проверенный по этой цепочке и `EYE_Logs/`, с возможностью экспорта в `audit_trail.json`. |

**Независимые этапы.** Timeline и UBA читают базы данных артефактов дела **напрямую** — ни один не требует запуска корреляции, и Timeline не зависит от Correlation Engine (он применяет собственную облегчённую временную группировку). Correlation — это дополнительный слой анализа, результаты которого Eye может запрашивать.

**Только для чтения по замыслу.** Парсинг записывает в базу данных дела; все последующие этапы (UBA, Timeline, просмотрщики корреляции, Eye) открывают эти базы **только для чтения**. Исходные доказательства никогда не изменяются — [Dynamic Linking](#-analysis-modes) читает базы данных дела, чтобы построить `Crow_Intelligence.db` с сопоставлениями идентификаторов для дела, и обогащает таблицы данных артефактов на месте с помощью неразрушающих запросов `ATTACH` + `LEFT JOIN`, а не перезаписи строк.

**Управление по замыслу.** Каждое действие Eye привязано к защищённой от несанкционированного вмешательства хэш-цепочке **EvidenceSeal**, а страница **Compliance** непрерывно проверяет Eye на соответствие [Ghassan Elsman Protocol (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) — статус по каждому правилу в реальном времени, экспортируемый в `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**, и она является нашим **главным приоритетом для обновлений**:

- 🛡️ **Самые быстрые исправления.** Когда обнаруживается проблема или сообщается об ошибке, мы выпускаем обновлённый EXE **как можно скорее** — исправления в первую очередь попадают в готовую сборку.
- 🔄 **Встроенное автоматическое обновление.** В установленном приложении откройте **Настройки → Обновления**, чтобы **проверить наличие обновлений и установить их автоматически** — без ручной переустановки.
- 📦 **Никакой настройки.** Не требуется установка Python, Node или зависимостей.

> Предпочитаете запускать из исходников? Смотрите **[Быстрый старт](#-quick-start)** ниже. Сборка из исходного кода предназначена для контрибьюторов и **не включает автообновление** — для автоматических обновлений используйте MSI/EXE.

## 🚀 Быстрый старт

### Вариант А — Установленная сборка (рекомендуется)
Скачайте **MSI/EXE** с [crow-eye.com/download](https://crow-eye.com/download), установите и запустите **Crow-Eye** от имени администратора. Создайте дело и начните анализ.

### Вариант Б — Запуск из исходников (для разработчиков)

> Для контрибьюторов и продвинутых пользователей. Этот путь **не включает автообновление** — для автоматических обновлений используйте MSI/EXE.

**Требования** (устанавливаются автоматически при первом запуске):
- Python 3.12.4
- **Node.js и npm** — требуются для **визуализации Timeline**
- Ключевые пакеты: PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**Рекомендуемое оборудование**

| | Минимум | Рекомендуется для больших дел |
|---|---|---|
| **ОЗУ** | 8 ГБ | 16 ГБ+ (наборы MFT/USN из миллионов записей) |
| **Диск** | 5 ГБ свободно | Свободное место ≥ 2× размера разбираемых доказательств |
| **Процессор** | 4 ядра | 8+ ядер |
| **ОС** | Windows 10/11 (полная) · Linux (автономный режим и анализ образов) | — |

> Корреляция обрабатывает очень большие наборы данных потоково с постоянным использованием памяти, поэтому ОЗУ редко является жёстким ограничением — обычно это пропускная способность диска и свободное место.

**Запуск** (запускайте от имени администратора, чтобы Crow-Eye мог получать доступ к системным артефактам):```bash
python "Crow Eye.py"

Основной интерфейс открывается, вы создаёте дело (case), и все результаты анализа сохраняются в каталоге этого дела для последующего просмотра и составления отчётов.

🖥️ Примечание о кроссплатформенности: на Linux живые парсеры автоматически отключаются, и Crow-Eye работает в режиме офлайн / криминалистический образ. Полный сбор с живой системы доступен только в Windows.

📂 Поддерживаемые артефакты

Crow-Eye анализирует широкий набор артефактов Windows — исполнение, файловая система и активность пользователя — как с живой системы, так и из офлайн-источников (собранные папки или криминалистические образы).

Jump Lists и LNK обрабатываются собственным специализированным парсером LNK / Jump List компании Crow-Eye — а не сторонним модулем.

Пользовательский анализ реестра / заблокированные файлы: Windows блокирует живые кусты реестра (NTUSER.DAT, SOFTWARE, SYSTEM) во время работы. Для пользовательского анализа живой системы загрузитесь с внешнего носителя (WinPE/Live CD), используйте инструменты криминалистического сбора или проанализируйте образ диска.

Детали по каждому артефакту

• Jump Lists и LNK — автоматически извлекаются из стандартных системных расположений собственным выделенным парсером Crow-Eye (доступ к файлам, пути назначения, метки времени и метаданные).
• Реестр — автоматически анализирует системные кусты. Для пользовательского анализа реестра скопируйте файлы кустов в CrowEye/Artifacts Collectors/Target Artifacts (или в папку registry/ вашего дела):
  • NTUSER.DAT из C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE из C:\Windows\System32\config\SOFTWARE
  • SYSTEM из C:\Windows\System32\config\SYSTEM
  • Windows блокирует их во время работы — для живой системы загрузитесь с внешнего носителя (WinPE/Live CD), используйте инструменты криминалистического сбора или проанализируйте образ диска.
• Prefetch — анализирует C:\Windows\Prefetch, извлекая историю запусков и криминалистические метаданные (включая метки времени каждого запуска).
• Журналы событий — автоматический разбор журналов System/Security/Application в базу данных для всестороннего анализа.
• — раскрывает историю доступа к папкам и особенности навигации пользователя.

🔧 Режимы анализа

🦅 Сбор Crow-Claw

Crow-Claw — это специализированный механизм сбора Crow-Eye для сбора и сохранения артефактов с живых систем или подключённых образов.

• Выборочный сбор — выберите конкретные категории артефактов (реестр, журналы событий, файловая система) или соберите всё.
• Глубокое сканирование — обход каталогов и подкаталогов для поиска криминалистических следов.
• Безопасное сохранение — артефакты сохраняются в структурированный каталог дела, сохраняющий криминалистическую целостность.

🔍 Офлайн-анализ (Offline Importer)

Анализ артефактов, собранных из любого источника, без живого подключения к целевой системе — три чёткие операции:

• SCAN (обнаружение) — обход источника и индексация всех поддерживаемых артефактов по шаблону имени файла и расширения (быстро, только чтение; содержимое файлов не читается, проверка магических байтов на этом этапе не выполняется). Ничего не перемещается.
• COLLECT (сбор) — физическое копирование выявленных файлов в папку live_acquisition дела с сортировкой по типу.
• PARSE (детальный разбор) — просмотр выявленных элементов по типам (AMCACHE, EVTX, PREFETCH, …) и разбор выбранных файлов (или всех) в криминалистическую базу данных.

Разбор выполняется выделенными офлайн-парсерами Crow-Eye — той же логикой артефактов, что и в живом режиме, но работающей с собранными файлами: Prefetch, реестр, MFT, USN (плюс коррелятор MFT/USN), AmCache, ShimCache, SRUM, журналы событий, LNK/JumpLists и корзина.

📎 Импорт доказательств (данные сторонних инструментов)

Помимо исходных артефактов, Crow-Eye может принимать результаты сторонних криминалистических инструментов напрямую в дело — Plaso, Autopsy, Volatility или любой пользовательский экспорт — и делать их доступными для Eye и Timeline без необходимости предварительного запуска корреляции.

Поскольку менеджер базы данных дела автоматически обнаруживает любые .db в дереве дела, импортированные доказательства сразу становятся доступны для:

• The Eye — доступны для запросов на естественном языке наряду с нативными артефактами (манифест схемы обновляется при импорте).
• Интерактивной Timeline — предоставляются как тип артефакта imported с работающей фильтрацией по временному окну и границами времени.
• Correlation Engine — могут использоваться как Feather для кросс-инструментальной корреляции с нативными артефактами.

Импортёр использует только стандартную библиотеку (sqlite3 / csv / json) и работает в фоновом потоке, поэтому большие импорты не блокируют интерфейс.

⚡ Живой анализ

Анализирует артефакты непосредственно с работающей системы Windows, автоматически извлекая их из стандартных расположений для криминалистического анализа в реальном времени.

🗂️ Управление делами

Каждое расследование — это дело: автономный каталог, в котором организованы базы данных артефактов и результаты анализа. Crow-Eye отслеживает недавние дела (с избранным, тегами и статусом), проверяет дело при открытии, атомарно записывает конфигурацию (устойчиво к сбоям), поддерживает импорт/экспорт конфигурации дел и шаблоны с готовыми семантическими сопоставлениями.

🕰️ Интерактивная визуализация Timeline

Сопоставление событий между артефактами на единой временной сетке с представлениями Heat Map, Week и Day — это связанная по идентичностям, прослеживаемая в суде история, а не плоская супер-хронология.

Timeline читает проанализированные базы данных артефактов дела напрямую и не зависит от Correlation Engine — вам не нужно создавать feather, писать wings или запускать пайплайн для её использования. Она применяет собственную лёгкую временную группировку (корреляцию по точным меткам времени и временным окнам, группировку по приложению, пути или пользователю) для связывания событий на сетке. Доказательства, загруженные через Import Evidence, также появляются на таймлайне как тип артефакта imported с работающей фильтрацией по временному окну и границами времени.

🔎 Поиск и экспорт

Полнотекстовый поиск по базе данных дела, а также экспорт в CSV (электронные таблицы), JSON (интеграция с другими инструментами) и подробные HTML-отчёты (полные досье, объединяющие все артефакты, связанные с поисковым запросом).

🔗 Динамические связи

Преобразование сырых технических идентификаторов — SID, MAC-адресов, хэшей — в читаемый человеком контекст на лету. Динамические связи обогащают представление с помощью неразрушающих SQL-запросов ATTACH, поэтому исходные доказательства никогда не изменяются, а также могут принимать массовые потоки IOC-индикаторов для инлайн-пометки известных вредоносных индикаторов.

🧠 Аналитика поведения пользователя (UBA)

Превращает сырые артефакты в понятную историю активности на простом английском — отчёт для менеджеров/HR о том, что на самом деле делал пользователь и его приложения, причём каждое утверждение прослеживается до точного исходного доказательства.

Аналитика поведения пользователя (UBA) читает проанализированные базы данных артефактов в папке Target_Artifacts/ вашего дела (строго только чтение) и прогоняет их через декларативный набор правил, формируя понятную хронологическую Activity Story. Открывается через кнопку на панели инструментов "User Behavior" или по сочетанию Ctrl+Shift+B (должно быть загружено дело).

• 🧩 40 декларативных детекторов поведения (uba/config/behavior_rules.json) — настраиваются без кода, каждый классифицирован по степени серьёзности: routine · notable · suspicious · critical.
• 🕵️ Обнаруживает значимое поведение: вход / выход / разблокировка системы, запуск · выполнение · установка программ, открытие / удаление / предполагаемое копирование файлов, подключение USB-устройств, доступ к сетевым ресурсам, персистентность и автозапуск, использование явных учётных данных (runas), изменения учётных записей и групп, изменения служб, вмешательство в системные часы (suspicious) и очистка журналов событий (critical).
• 🗺️ Три представления — лента Activity Story, тепловая карта Activity Map (день × час) и отчёт честности "What we can see", помечающий каждый детектор как Working / Limited / No data / By design для данного дела.
• 🔗 Каждое действие подтверждено доказательствами. Нажмите на любой элемент, чтобы открыть точную подтверждающую запись (database : table : rowid) — ничто не утверждается без источника.
• 👤 Честная атрибуция. Исполнители определяются как User / Application / System (или остаются пустыми) — UBA никогда не угадывает, кто что сделал.

Охват детектирования

40 детекторов охватывают четыре класса серьёзности и весь спектр анализируемого набора артефактов:

Фильтры: полнотекстовый поиск · пользователь/исполнитель (включая «Unattributed» и переключатель сеанса входа) · класс поведения (user / application / system) · серьёзность · приложение (поиск с множественным выбором среди 200+ программ) · диапазон дат и времени с быстрыми пресетами (всё время / первый день / последний день / последний час активности).

Источники данных: Security, System и Application Event Logs · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · корзина · SRUM (приложения, сеть, подключения) · кусты реестра.

Криминалистические гарантии

• Только чтение. Исходные базы данных открываются в режиме только чтения; анализ никогда не затрагивает доказательства.
• Полное происхождение. Каждое событие несёт database → table → rowid и открывает реальные исходные строки по требованию.
• Атрибуция никогда не угадывает. Событие приписывается пользователю, приложению, системе — или остаётся пустым. Интерактивные сеансы входа используются только как контекстные метки («во время сеанса <user>»), но никогда для атрибуции действия.
• Честные формулировки. Формулировки различают намеренное взаимодействие (UserAssist, SRUM передний план) и артефакты, которые приложение также может создавать (ShellBags, LNK, JumpLists), с явными оговорками на карточке.
• Отсутствие данных заявляется, а не подразумевается. Отчёт What we can see помечает каждый детектор для данного конкретного дела, поэтому отсутствующие данные никогда не читаются молча как «ничего не происходило».

UBA — это управляемая правилами поведенческая корреляция и классификация, а не статистическое/ML-скоринговое обнаружение аномалий — каждый вывод сопоставляется с явным проверяемым правилом. Полный каталог детектирования см. в RELEASE_NOTES.md.

🧩 Correlation Engine

Correlation Engine v1.7.0 — ядро реконструкции. История версий: RELEASE_NOTES.md.

Crow-Eye Correlation Engine — это промышленная криминалистическая система корреляции. Она принимает артефакты Windows из любого источника, нормализует их и выявляет временные и идентификационные связи, превращающие отдельные записи в связное повествование о том, что произошло в системе, когда и кто был вовлечён. Работает «из коробки» со встроенными правилами корреляции (Wings) для наиболее распространённых вопросов расследования, позволяет аналитикам создавать собственные правила без изменения кода и оставляет интерпретацию настраиваемым правилам и следователю — а не «чёрному ящику» оценки.

🎥 Руководство пользователя

Универсальный импорт данных: Correlation Engine может принимать вывод любого криминалистического инструмента в формате CSV, JSON или SQLite и преобразовывать его в базу данных Feather. Это означает, что вы можете коррелировать данные сторонних инструментов (Plaso, Autopsy, Volatility и т. д.) с нативными артефактами Crow-Eye, создавая единый корреляционный анализ по всем вашим криминалистическим источникам данных.

🎯 Точность и полнота доказательств

Целенаправленный проход по повышению точности, проверенный сквозным образом на реальном Windows-деле с ~700K записей, поверх более ранних работ по надёжности. Каждое исправление ниже закреплено регрессионным набором pytest и проверено целостным проверочным стендом, который прогоняет все 7 стандартных wings на обоих движках.

Движок идентичности собирает все доказательства

• Исправлено: движок идентичности перебирал только ПЕРВУЮ строку каждого feather при активном фильтре по времени (сравнение timezone-aware и naive datetime вызывало TypeError и прерывало цикл по строкам). Количество просмотренных записей выросло с 3 558 → 745 615 на проверочном деле.
• Исправлено: записи журналов схлопывали каждое событие в идентичность по его event PROVIDER (все 33 855 записей SecurityLogs имели одну идентичность). Сопоставление по артефактам теперь отдаёт приоритет реальным сущностям на уровне строк (User, ComputerName, NewProcessName, TargetUserName) до метаданных канала/провайдера.
• Исправлено: сопоставление полей с учётом артефакта никогда не срабатывало, потому что парсеры не проставляют колонку artifact в каждой строке. Движок теперь использует запасной вариант feather_metadata.artifact_type, поэтому SecurityLogs / SystemLogs / ApplicationLogs используют свою приоритетность идентичности для конкретного артефакта.
• Исправлено: строки-заглушки становились ложными идентичностями ('N/A', 'Unknown', '-', nil-GUID объединяли несвязанные записи). Валидатор теперь отклоняет 30+ вариантов заглушек.

Больше никакого «всё Low — что-то не так»

• Исправлено: совпадения в пределах одного feather помечались High. Совпадения с feather_count == 1 теперь получают confidence_category="Low - single feather", поэтому представление High фокусируется на реальной кросс-feather корреляции.
• Исправлено: составной ключ с учётом пути разделял одну идентичность между feathers (каждый feather хранит пути по-разному, поэтому chrome имел 10+ ключей и никогда не коррелировал). Ключ теперь состоит только из имени — кросс-feather корреляция снова работает.

Обнаружение имперсонации через классификацию путей — после формирования совпадения движок классифицирует путь каждой записи как TRUSTED (Program Files, System32, WinSxS, формы /device/harddiskvolumeN/... из BAM/SRUM и т. д.) или SUSPICIOUS (Temp, Downloads, Public, AppData\Local\Temp, корзина, съёмные корни, сетевые ресурсы). Совпадение, охватывающее обе классификации, поднимает impersonation_alert (≈0,05% случаев, каждый — реальный кандидат).

Честный учёт доказательств — подневной журнал отброшенных записей с именованными категориями (no_identity_field, normalize_failure, below_threshold_skipped, …) плюс сводка по каждому пайплайну (записей просмотрено, high/low выдано, без идентичности, категории отбрасывания, соединения timeless-feather). Каждая запись либо попадает в совпадение, либо в именованную категорию отбрасывания — «не осталось неучтённых доказательств» проверяемо по журналу. low_confidence_review_mode включён по умолчанию, поэтому группы ниже порога становятся Low-confidence совпадениями, а не исчезают молча.

Обогащение идентичности timeless-feather — feathers без посекундных меток времени в строках (AutoStartPrograms, MUICache, SystemServices, TypedPaths) больше не получают фиктивную метку времени генерации на каждой строке; вместо этого после формирования таймированных совпадений движок присоединяет по идентичности соответствующие записи из каждого timeless-feather как дополнительные доказательства.

Консолидированный реестр идентичностей — config/standard_fields/identities.json является единственным источником истины для каждой колонки, которую должны учитывать движки и Eye: 98 категорий, 1 146 синонимов колонок (приложение/процесс, файл, хэш, пользователь, хост/устройство, сеть, реестр, служба/задача, событие, email, браузер, облако, внутренности Windows, сертификат, контейнер, объекты ОС). Добавление нового синонима колонки — это правка JSON, а не изменение кода.

Исправления ложных срабатываний семантического сопоставления — проверка нескольких индикаторов теперь действительно применяется (data-exfiltration-pattern требует ≥2 индикаторов); невозможные правила AND (4625 AND 4624) переписаны как OR; правила wiper/remote-tool используют настоящие regex вместо срабатывания на каждой записи Prefetch; правила базовой активности понижены с high/critical до info/low (взвешенный скоринг wing повышает реальные угрозы).

✅ Статус производства

Correlation Engine готов к продакшену и активно используется в расследованиях (Correlation Engine v1.7.0):- ✅ Механизм сканирования по временному окну — готов к продакшену, рекомендуется для анализа по времени (O(N log N))

• ✅ Механизм на основе идентичности — готов к продакшену, рекомендуется для отслеживания идентичности (O(N log N))
• ✅ Feather Builder / FeatherWriter — импортирует CSV/JSON/SQLite из любого инструмента; транзакционная пакетная обработка + метаданные схемы
• ✅ Система Wings и оркестрация конвейеров — создание/управление правилами корреляции и автоматизация рабочих процессов
• ✅ Группировка идентичности — единая для движка, просмотрщиков и семантического этапа
• ✅ Реестр стандартных полей — централизованный источник истины для синонимов полей
• ✅ Развёртка множественных временных меток — коррелируется каждая временная метка из JSON-списка
• 🔄 Параллельная корреляция — фундамент заложен; далее профилирование + диспетчеризация через пул процессов
• 🔄 Семантическое сопоставление и оценка корреляции — активные улучшения

Ключевые возможности

• 🔄 Архитектура с двумя механизмами: Выбирайте между стратегиями корреляции на основе сканирования по временному окну (O(N log N)) и на основе идентичности (O(N log N)).
• 📊 Поддержка множества артефактов: Коррелируйте Prefetch, ShimCache, AmCache, журналы событий, LNK-файлы, Jumplists, MFT, USN, SRUM, реестр, RecycleBin и другие.
• 🔌 Универсальный импорт: Импортируйте выходные данные CSV/JSON/SQLite из любого форензического инструмента и конвертируйте в базы данных Feather.
• 🎯 Умная группировка идентичности: Варианты вроде Chrome.exe/chrome.dll/Chrome.EXE схлопываются в одну корзину; версии и архитектурные квалификаторы остаются различимыми.
• 🕒 Толерантные временные метки: FILETIME, ISO 8601, Unix epoch (s/ms/μs), YYYYMMDD, US-формат с косой чертой и строки с аннотациями — всё корректно разбирается с первого раза.
• 📈 Развёртка множественных временных меток: Списки временных меток JSON (Prefetch run_times) разворачиваются, чтобы каждое выполнение получало собственное событие корреляции.
• 🧰 Единый источник истины: Синонимы полей в config/standard_fields/*.json; метаданные для каждой таблицы в correlation_engine/config/feather_schemas.json — расширение редактированием JSON, а не кода.
• ⚡ Стриминг и потокобезопасность: O(1)-память query_time_range_iter; кэши feather под защитой блокировок; готовность к параллельной корреляции.

Архитектура системы

Механизм корреляции состоит из четырёх основных компонентов:

1. 🗄️ Feathers (нормализация данных)

Назначение: Преобразование сырых форензических артефактов в стандартизированный, пригодный для запросов формат.

• Базы данных SQLite, содержащие нормализованные данные форензических артефактов — по одному feather на тип артефакта (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"]
}

No input content was provided after "INPUT:" — there is no text to translate. Please supply chunk 18 of 25.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

The INPUT section is empty — no chunk content was provided to translate. Please supply the Markdown text for chunk 20 of 25.```
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. Анализ: используйте Results Viewer для изучения временных связей.

📚 Документация механизма корреляции

• Обзор механизма корреляции — обзор системы с диаграммами архитектуры
• Документация по механизму — архитектура с двумя механизмами, выбор механизма, оптимизация производительности
• Архитектура — интеграция компонентов и потоки данных
• Документация по Feather — система нормализации данных
• Документация по Wings — правила корреляции
• Документация по Pipeline — оркестрация рабочих процессов
• Добавление артефакта — порядок действий по подключению нового парсера к механизму
• Реестр стандартных полей — канонические синонимы имён столбцов, загружаемые обоими механизмами и Eye
• Руководство по участию — как внести вклад в разработку механизма
• Быстрые ссылки: Выбор механизма · Поиск и устранение неисправностей · Оптимизация производительности

👁️ Eye — ИИ-ассистент для криминалистики

Мощный ассистент, а не замена. Eye автоматизирует и проверяет гипотезы исследователя — окончательное решение он никогда не принимает за вас.

Eye — это встроенный ИИ-ассистент для криминалистики в Crow-Eye: опытный криминалистический исследователь, опирающийся на реальную базу знаний об артефактах Windows. Он предоставляет интерфейс на естественном языке для запросов, корреляции и документирования всего в рамках дела — Prefetch, MFT, реестр, журналы событий, AmCache, ShimCache, SRUM и многое другое — сохраняя при этом аудируемый, защищённый от вмешательства журнал того, что именно он сделал. Eye может работать полностью на вашем собственном оборудовании (включая полностью изолированную от внешних сетей среду), в соответствии с позицией Crow-Eye по конфиденциальности: «0 мс данных, отправляемых за пределы устройства». Полная архитектура: eye/README.md.

Eye превращает разговорные вопросы («покажи, что запускалось из C:\Temp после 22:00») в реальную криминалистическую работу: он планирует подход, извлекает релевантные знания об артефактах, выполняет SQL-запросы и межартефактный поиск по базам данных дела и синтезирует проверенный ответ. Каждый ответ создаётся сразу в двух местах — ответ в чате для вас и структурированный блок, записываемый в рабочее пространство живого отчёта, так что досье собирается само по мере хода расследования.

Протокол Гассана Элсмана (GEP)

Всё, что делает Eye, опирается на протокол Гассана Элсмана (GEP) — не зависящий от вендора и инструментов стандарт того, как любой ИИ должен использоваться в цифровой криминалистике. Это 10 принципов, которым должна следовать соответствующая система, чтобы результаты, полученные с помощью ИИ, оставались достоверными, прослеживаемыми до исходных записей и подкреплёнными аудируемой цепочкой с защитой от вмешательства, при этом человек-исследователь сохраняет контроль:

Eye из Crow-Eye — это эталонная реализация GEP; поведение внутри продукта, обеспечивающее его соблюдение, — это рабочие правила. 📜 Прочтите стандарт: eye/docs/GEP_standard.md.

Режимы развёртывания

Eye адаптируется к вашей модели угроз с помощью трёх режимов развёртывания:

В режиме CLI-агента Crow-Eye использует существующий ИИ-агент терминала/командной строки в качестве модели — вместо облачного API или локального автономного сервера, — так что вы можете вести расследование с агентом, которым уже пользуетесь.

Цикл расследования:

1. Откройте или создайте дело — Eye ограничивает свою работу базами данных артефактов и историей этого дела.
2. Задайте вопрос на естественном языке или запустите комплексный триаж в один клик.
3. Eye выполняет свой pipeline — определение намерения → извлечение знаний → выполнение инструментов → синтез.
4. Вы получаете двойной результат — прямой ответ в чате и новый блок в живом отчёте.
5. Одобряйте контролируемые действия — экспорт и другие критически важные шаги ждут вашего подтверждения.

Вы можете менять модель во время работы с помощью инструмента switch_model. Переключение ограничено тем же бэкендом, поэтому улики никогда незаметно не отправляются иному провайдеру, кроме выбранного вами.

Отслеживание процесса мышления LLM

Eye устроен так, чтобы вы могли видеть — и впоследствии доказать — как он пришёл к выводу. Пока Eye работает, он в реальном времени передаёт в интерфейс структурированные обновления ThinkingStep; каждый шаг содержит step_id, type, читаемую человеком label, status (active → done или error) и опциональные tool/params/detail.

Типичный запрос разворачивается как thinking → rag → thinking → tool_call → synthesis, и по каждому делу на диске сохраняются trace-артефакты, которые можно изучить впоследствии:

Выполнение инструментов

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 и локальных серверов или XML-обёртка <tool_call> для CLI-агентов.

Создание корреляционных Wings и семантических сопоставлений

Eye не просто выполняет запросы к механизму корреляции — он может помочь расширить его. Когда Eye замечает повторяющийся межартефактный шаблон, он может предложить новые Wings (правила корреляции) и семантические сопоставления (перевод с технического языка на человеческий). Это управляемое авторство: Eye предлагает, аналитик проверяет сохранённый артефакт, и каждое изменение обосновано и подкреплено уликами.

Wing связывает feathers друг с другом в пределах временного окна и порога минимального совпадения, чтобы подтвердить утверждение:

Семантическое сопоставление переводит сырое техническое значение в понятный человеку смысл (например, EventID 4624 → «Успешный вход»). Оно бывает двух видов: простое mapping (одно значение/regex → семантическое значение) или многокомпонентное 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 токенов, но никогда не более половины). Если это всё равно не помещается, он восстанавливается двумя последовательными проходами, никогда не затрагивая защищённые сообщения (закреплённые, автоматически обнаруженные улики или результат инструмента):

1. Проход суммирования (один раз) — незащищённая история сжимается в одно резюме, фиксируется как SUMMARIZED.
2. Проход удаления — самое старое незащищённое сообщение удаляется по одному, пока всё не поместится, фиксируется как TRUNCATED.

Если неприводимое ядро улик (закреплённые + результаты инструментов + текущий вопрос) всё равно переполняется, Eye отказывается продолжать, а не усекает улики (REFUSED_OVERFLOW) и просит вас сузить запрос или использовать analyze_large_dataset. То, что в итоге отправляется модели, — это точная полезная нагрузка, которая запечатывается для цепочки хранения улик.

🗺️ Narrative Map — постоянная память Eye о деле

Eye не сохраняет состояние между ходами — поэтому Narrative Map — это место, где для дела хранится «что мы знаем и к каким выводам пришли». Это постоянная, аудируемая, защищённая от вмешательства рабочая память Eye, и её содержимое внедряется в промпт Eye на каждом ходу (карта буквально и есть память).

• 🧭 Вердикт → Нарратив → Улики. Строгая иерархия: один Вердикт по делу, под ним Нарративы (утверждения, каждое со своим состоянием — proven · open · negative · needs · absolute), а под ними — подкреплённые артефактами Улики.
• 🪟 Собственное окно. Открывается по кнопке «Narrative Map» в окне чата Eye, так что вы можете наблюдать чат, живой отчёт и память дела бок о бок; оно обновляется в реальном времени по мере изменений.
• ↔️ Двунаправленная — память, которой вы управляете. И правки Eye, и ваши собственные заметки проходят через единый коммит, проверенный по GEP, и запечатываются в аудит-журнал со сцеплением хешей (narrative_map_audit.jsonl). Вы можете добавлять, изменять и удалять его утверждения и улики, напрямую формируя то, как Eye понимает и интерпретирует дело.
• 🚫 Никогда не утверждает неподтверждённое. Нарратив Eye может оставаться в состоянии open без улик, пока идёт расследование, но без улик он никогда не может стать proven; тема, проверенная Eye и оказавшаяся пустой, автоматически переводится в negative — потому что документально зафиксированное отсутствие само по себе является находкой.

Как обеспечивается соответствие требованиям

Соответствие требованиям — это не прикрученная сверху функция: оно обеспечивается в самом конвейере.

• 🔗 Цепочка хранения улик (Evidence Seal). Каждая полезная нагрузка, которую Eye отправляет LLM, запечатывается: SHA-256 точных байтов, количество токенов, модель + её лимит контекста и происхождение каждой строки улик (database:table:rowid, а также вычисленные смещения для записей MFT). Печати записываются в <case>/EYE_Logs/eye_payload_seal.jsonl в режиме append-only и со сцеплением хешей — одна изменённая или удалённая запись разрывает цепочку, поэтому журнал математически доказывает, какие байты анализировала модель.
• 🚫 Без молчаливого усечения. Когда контекст становится тесным, Eye самовосстанавливается и перераспределяет бюджеты в строгом порядке: Приоритет 1 (Неприкосновенно): сырые улики + системный промпт › Приоритет 2 (Жертвенно): непринуждённый разговор › Приоритет 3 (Гибко): RAG-контекст. Если ядро улик всё равно не помещается, Eye отказывается, а не молча отбрасывает улики.
• 🧾 Аудит-журнал усечения. Каждое решение о контексте записывается в <case>/EYE_Logs/truncation_audit.log (SUMMARIZED, TRUNCATED, PRESERVED, PINNED, UNPINNED, BUDGET_REDUCED), каждое со своим хешем. Обнаруженные улики автоматически закрепляются выше порога уверенности; вы также можете закреплять сообщения вручную.

📖 Полная архитектура Eye: eye/README.md.

📖 Eye-Describe — база знаний об артефактах на уровне байтов

🔗 Изучить Eye-Describe → crow-eye.com/eye-describe

Исторически исследователи попадали в ловушку, доверяя своим криминалистическим инструментам, не понимая, как ведут себя базовые артефакты или как инструмент их разобрал. Сегодняшний риск — это простая замена «инструмента» на «ИИ». ИИ может разобрать запись с идеальной технической точностью и всё равно поместить её в неправильный контекст — изменив весь смысл улики.

Eye-Describe существует, чтобы ни человеку, ни модели не приходилось гадать. Это интерактивный справочник по сырым двоичным структурам артефактов Windows на уровне байтов, и он выполняет сразу две роли:

Привязывая ИИ-слой к задокументированному поведению артефактов, Crow-Eye не просит вас доверять модели — он ограничивает модель, заставляя её уважать сырую криминалистику.

Не заменяйте доверие к инструменту доверием к ИИ. Понимайте данные.

🧪 Качество и валидация

Криминалистический инструментарий полезен только тогда, когда его результаты можно защитить. Работа Crow-Eye над корректностью намеренно открыта:

• Наборы регрессионных тестов. Механизм корреляции зафиксирован pytest-набором, покрывающим разбор временных меток, нормализацию идентичности, разветвление по нескольким временным меткам, контракт записи, авторство Eye (управление GEP на стороне записи) и реестр стандартных полей. Механизм UBA поставляется со своим набором, включая сквозной прогон на реальном деле.
• Валидационный стенд. Целостный стенд прогоняет все 7 стандартных wings на обоих механизмах на реальном деле Windows объёмом ~700 тыс. записей.
• Опубликованная история дефектов. Регрессии точности и их измеренное влияние открыто документируются в RELEASE_NOTES.md — включая случаи, когда исправление меняло число учтённых записей на порядки. Знание того, что и когда было неправильно, — часть того, что делает результат защищаемым.
• Проверяемый учёт улик. Каждая запись попадает либо в совпадение, либо в именованный drop bucket, а пооконный журнал отбрасывания делает «отсутствие оставшихся улик» тем, что можно проверить по журналу, а не принимать на веру.
• Журналы с защитой от вмешательства. verify_chain() заново проходит по аудит-журналу Narrative Map и цепочке Evidence Seal, чтобы обнаружить изменения — в том числе в читаемых человеком полях.

🔬 Исследовательская платформа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, укрепление управления делами, …).
• Документация Correlation Engine — обзор, движок, feathers, wings, pipelines.
• Архитектура Timeline — внутреннее устройство модуля Timeline.
• Архитектура Eye и стандарт GEP — ИИ-ассистент и его регламентирующий протокол.

🤝 Участие

Crow-Eye создан как открытая исследовательская платформа, и вклад приветствуется — новые парсеры, правила корреляции, документация и исследование артефактов.

• Общие вклады: CONTRIBUTING.md
• Correlation Engine (приоритетное направление): correlation_engine/CONTRIBUTING.md
• Контакт: [email protected] · или откройте issue / pull request.

🌐 Веб-сайт и сообщество

• 🌍 Официальный сайт: crow-eye.com — ресурсы, документация и загрузки.
• 💬 Discord: Присоединяйтесь к Discord Crow-Eye — прямая помощь, исследование артефактов и анонсы релизов.

📄 Лицензия

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: механизм криминалистического анализа 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**.