Crow-Eye — Механизм криминалистики Windows

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

Содержание

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

Обзор

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

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

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

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

• Реконструкция вместо обнаружения. Коррелирует все артефакты в одну навигационную историю по каждой сущности, а не в кучу оповещений.
• Полная интеграция — сбор → корреляция → временная шкала → поведенческая аналитика → ИИ → опечатанная память дела: полный конвейер, который не охватывает ни один существующий инструмент.
• Глубина артефактов, а не поверхностность журналов. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists и другие переживают очистку журналов и трюки «жизни на чужой территории», которые ослепляют инструменты, работающие только с журналами.
• ИИ-ассистент Eye — расследование на естественном языке с поддающейся аудиту и защищённой от подделок цепочкой хранения улик, работающее в облаке, на частном сервере или полностью автономно.
• Аналитика поведения пользователей (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

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


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

| Этап | Что важно |
|---|---|
| ① → ② | **Четыре независимых входа в дело.** Вам никогда не понадобится собственный сборщик 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 выполняет и записывает в журнал. |
| ⑤ → Отчёт | **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 (он применяет собственную облегчённую временную группировку). Корреляция — это дополнительный слой анализа, результаты которого 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/main/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 **как можно скорее** — в готовой сборке исправления появляются в первую очередь.
- 🔄 **Встроенное автообновление.** В установленном приложении откройте **Settings → Updates**, чтобы **проверить наличие обновлений и установить их автоматически** — без ручной переустановки.
- 📦 **Ноль настройки.** Не требуется установка Python, Node или зависимостей.

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

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

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

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

> Для контрибьюторов и продвинутых пользователей. Этот путь **не включает автообновление** — используйте 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 в базе данных для всестороннего анализа.
• Глубина реестра (0.13.0) — парсер читает файл куста, а также живой реестр, поэтому он достигает того, что winreg запрещает даже администратору (каждый подключ Properties устройства, а вместе с ним и время подключения USB), проходит по аллокатору куста для восстановления удалённых ключей и значений, а также читает имена классов и дескрипторы безопасности ключей. Девятнадцать ключей, содержавших реальные данные и не читавшихся ничем, теперь анализируются — включая StartupApproved в Explorer, который показывает, действительно ли каждой записи автозапуска разрешено запускаться.
• ShellBags — раскрывает историю доступа к папкам и шаблоны навигации пользователя.
• Корзина — анализирует $RECYCLE.BIN для восстановления имён удалённых файлов, исходных путей, времени удаления и размеров (живые системы и образы дисков).
• MFT — анализирует Master File Table для получения метаданных файлов, атрибутов, временных меток и информации об удалённых файлах (NTFS, Windows 7/10/11).
• USN Journal — отслеживает события создания/изменения/удаления/переименования файлов с временными метками и полной историей имён для реконструкции таймлайна.
• SRUM — визуализирует использование ресурсов приложениями (полосы длительности для времени на переднем/заднем плане) и сетевую активность по каждому приложению.
• Анализатор криминалистики хранилищ — полное дерево каждого физического диска и его разделов; цветовая кодировка типов разделов (EFI, Linux, Recovery, скрытые/swap, …); предупреждения о загрузочных USB, скрытых корнях Linux и Intel Rapid Start; резервный механизм магического сканирования сырых секторов.

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

🦅 Сбор 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 и таймлайном без необходимости предварительного запуска корреляции.

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

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

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

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

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

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

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

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

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

Таймлайн читает проанализированные базы данных артефактов дела напрямую и не зависит от механизма корреляции — вам не нужно создавать 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+ программ) · диапазон дат и времени с быстрыми пресетами (всё время / первый день / последний день / последний час активности).

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

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

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

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, проверенный сквозным образом на реальном деле Windows с ~700K записей и наложенный на более раннюю работу по надёжности. Каждое исправление ниже зафиксировано набором регрессионных тестов pytest и проверено целостным валидационным стендом; он задействовал семь стандартных wings, поставлявшихся на тот момент, — сегодня поставляется одиннадцать. Приведённые ниже числа совпадений были измерены по правилам того выпуска: 0.13.0 изменил то, что считается совпадением (совпадение теперь должно охватывать более одного feather) и что означает оценка уверенности, поэтому относитесь к ним как к записи того прохода, а не как к текущим цифрам.

Механизм идентичности захватывает все доказательства

• Исправлено: механизм идентичности перебирал только ПЕРВУЮ строку каждого feather, когда был активен фильтр времени (сравнение datetime с учётом часового пояса и без него вызывало TypeError и прерывало цикл по строкам). Количество просмотренных записей выросло с 3 558 → 745 615 на валидационном деле.
• Исправлено: записи журналов схлопывали каждое событие до его ПОСТАВЩИКА событий как идентичности (все 33 855 записей SecurityLogs разделяли одну идентичность). Поартефактное сопоставление теперь отдаёт приоритет реальным сущностям на уровне строк (User, ComputerName, NewProcessName, TargetUserName) перед метаданными канала/поставщика.
• Исправлено: сопоставление полей с учётом артефакта никогда не срабатывало, потому что парсеры не проставляют столбец artifact в каждой строке. Механизм теперь возвращается к feather_metadata.artifact_type, поэтому SecurityLogs / SystemLogs / ApplicationLogs используют свой приоритет идентичности, специфичный для артефакта.
• Исправлено: строки-заглушки становились ложными идентичностями ('N/A', 'Unknown', '-', nil-GUID объединяли несвязанные записи вместе). Валидатор теперь отклоняет 30+ вариантов заглушек.
• Чистый результат на одном окне полного диапазона, измеренный тогда: wing Execution Proof выявил 2 856 кросс-feather (High) совпадений в механизме идентичности и 643 кросс-feather совпадения в механизме времени, с 24–118 кросс-feather совпадениями на wing среди остальных шести wings того выпуска.

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

• Исправлено: совпадения по одному feather помечались как High. Совпадения с feather_count == 1 теперь получают confidence_category="Low - single feather", поэтому представление High фокусируется на реальной кросс-feather корреляции.
• Исправлено: составной ключ с учётом пути разделял одну и ту же идентичность между feathers (каждый 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, …) плюс сводка по каждому конвейеру (записей обработано, high/low отправлено, без идентичности, категории отбрасывания, timeless-feather соединения). Каждая запись либо попадает в совпадение, либо в именованную категорию отбрасывания — «никаких доказательств не осталось» проверяемо по журналу. low_confidence_review_mode включён по умолчанию, поэтому группы ниже порога становятся совпадениями с низкой уверенностью, а не исчезают молча.

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

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

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

✅ Статус продакшена

Correlation Engine готов к продакшену и активно используется в расследованиях (Correlation Engine v1.7.0):

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

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

• 🔄 Архитектура с двумя движками: выбор между стратегиями сканирования временных окон (O(N log N)) и на основе идентичности (O(N log N)).
• 📊 Поддержка множества артефактов: корреляция Prefetch, ShimCache, AmCache, журналов событий, файлов LNK, Jumplists, MFT, USN, SRUM, реестра, корзины и многого другого.
• 🔌 Универсальный импорт: импорт вывода CSV/JSON/SQLite из любого криминалистического инструмента и преобразование в базы данных Feather.
• 🎯 Умная группировка идентичности: варианты вроде Chrome.exe/chrome.dll/Chrome.EXE сводятся в одну категорию; версии и архитектурные квалификаторы остаются различимыми.
• 🕒 Устойчивые временные метки: FILETIME, ISO 8601, Unix epoch (с/мс/мкс), YYYYMMDD, американский формат со слешами и аннотированные строки корректно разбираются с первой попытки.
• 📈 Развёртывание по нескольким временным меткам: списки временных меток в JSON (Prefetch run_times) раскрываются, чтобы каждое выполнение получало собственное событие корреляции.
• 🧰 Единый источник истины: синонимы полей в config/standard_fields/*.json; метаданные по таблицам в correlation_engine/config/feather_schemas.json — расширение путём правки JSON, а не кода.
• ⚡ Потоковая передача + потокобезопасность: итератор query_time_range_iter с памятью O(1); кэши feather под защитой блокировок; готовность к параллельной корреляции.
• 🔍 Гибкие правила: определение пользовательских правил корреляции (крыльев) с настраиваемыми параметрами.
• 📋 Честная диагностика: строка статистики по окну (records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted), чтобы вы всегда знали, были ли отброшены доказательства.
• 🧪 Закреплённое качество: набор регрессионных тестов pytest, охватывающий разбор временных меток, нормализацию идентичности, развёртывание, контракт писателя, создание Eye (governance GEP на стороне записи) и реестр стандартных полей.

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

Correlation Engine состоит из четырёх основных компонентов:

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

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

• Базы данных 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 3.8+
• pip

Установка из PyPI

pip install pycryptodome

Установка из исходного кода

git clone https://github.com/example/repository.git
cd repository
pip install -r requirements.txt

Использование

Базовое использование

from crypto_tool import encrypt_file, decrypt_file

# Шифрование файла
encrypt_file("input.txt", "output.enc", "ваш-пароль")

# Расшифровка файла
decrypt_file("output.enc", "decrypted.txt", "ваш-пароль")

Расширенное использование

from crypto_tool import CryptoManager

manager = CryptoManager(algorithm="AES-256-GCM")
manager.generate_key()
manager.save_key("ключ.key")

# Шифрование с пользовательскими параметрами
manager.encrypt_data(data, output_format="base64")

Конфигурация

Инструмент поддерживает файлы конфигурации в формате YAML:

# config.yaml
algorithm: AES-256-GCM
key_size: 256
iterations: 100000
output_format: base64

API

Класс CryptoManager

Основной класс для операций шифрования.

Методы

• generate_key() — генерирует новый ключ шифрования
• save_key(path) — сохраняет ключ в файл
• load_key(path) — загружает ключ из файла
• encrypt_data(data, output_format="base64") — шифрует данные
• decrypt_data(data) — расшифровывает данные

Функции

• encrypt_file(input_path, output_path, password) — шифрует файл
• decrypt_file(input_path, output_path, password) — расшифровывает файл

Примеры

Пример 1: Шифрование строки

from crypto_tool import CryptoManager

manager = CryptoManager()
manager.generate_key()

secret_message = "Секретное сообщение"
encrypted = manager.encrypt_data(secret_message.encode())
print(f"Зашифровано: {encrypted}")

decrypted = manager.decrypt_data(encrypted)
print(f"Расшифровано: {decrypted.decode()}")

Пример 2: Пакетное шифрование файлов

import os
from crypto_tool import encrypt_file

directory = "документы"
password = "безопасный-пароль"

for filename in os.listdir(directory):
    if filename.endswith(".txt"):
        input_path = os.path.join(directory, filename)
        output_path = input_path + ".enc"
        encrypt_file(input_path, output_path, password)
        print(f"Зашифрован: {filename}")

Устранение неполадок

Ошибка: "Неверный ключ"

Убедитесь, что вы используете тот же ключ или пароль, который использовали при шифровании.

Ошибка: "Файл не найден"

Проверьте, что путь к файлу указан правильно и файл существует.

Ошибка: "Недостаточно памяти"

Для больших файлов используйте потоковое шифрование:

from crypto_tool import CryptoManager

manager = CryptoManager()
manager.encrypt_stream("большой_файл.bin", "большой_файл.enc")

Лицензия

Этот проект лицензирован под лицензией MIT — подробности см. в файле LICENSE.

Вклад

Мы приветствуем вклад! Пожалуйста, ознакомьтесь с CONTRIBUTING.md для получения подробной информации о том, как начать работу.

Благодарности

• PyCryptodome — за базовые криптографические примитивы
• Всем участникам, которые помогли улучшить этот проект```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 want translated.```
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. Создание конвейера: настройте, какие wings и feathers использовать.
5. Выполнение: запустите конвейер и просмотрите скоррелированные результаты.
6. Анализ: используйте средство просмотра результатов для изучения временных взаимосвязей.

📚 Документация движка корреляции

• Обзор движка корреляции — обзор системы с диаграммами архитектуры
• Документация движка — архитектура с двумя движками, выбор движка, оптимизация производительности
• Архитектура — интеграция компонентов и поток данных
• Документация Feather — система нормализации данных
• Документация Wings — правила корреляции
• Документация конвейера — оркестрация рабочих процессов
• Добавление артефакта — рабочий процесс подключения нового парсера к движку
• Реестр стандартных полей — канонические синонимы имён столбцов, загружаемые обоими движками и 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 и межартефактные поиски по базам данных вашего дела и синтезирует проверенный ответ. Каждый ответ создаётся сразу в двух местах — ответ в чате для вас и структурированный блок, записываемый в рабочее пространство живого отчёта, чтобы досье формировалось само по мере хода расследования.

Протокол Ghassan Elsman (GEP)

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

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

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

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

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

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

1. Откройте или создайте дело — Eye ограничивает себя базами данных артефактов и историей этого дела.
2. Задайте вопрос на естественном языке или запустите комплексную триажную проверку в один клик.
3. Eye выполняет свой конвейер — определяет намерение → извлекает знания → выполняет инструменты → синтезирует.
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, и по каждому делу сохраняются файлы трассировки на диске, которые вы можете изучить впоследствии:

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

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. Всё, что в конечном итоге отправляется модели, — это точная полезная нагрузка, которая запечатывается для цепочки хранения.

🗺️ Карта повествования — постоянная память 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 точных байтов, количество токенов, модель + её предел контекста и происхождение каждой строки доказательств (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 должен отвечать в чате и сохранять подтверждающие доказательства в отчёт; неспособность зафиксировать доказательства помечается как нарушение протокола.
• ⚖️ Регулирование корреляции. Любой Wing или сопоставление, созданное Eye, должно включать криминалистическое reason и related_evidence; правила, созданные вне Eye, доступны только для чтения и не могут быть молча переписаны.
• 🔐 Конфиденциальность и автономный режим. В офлайн-режимах Eye совершает ноль исходящих вызовов; ключи облачных API хранятся в системных связках ключей ОС — никогда не захардкожены, никогда не записываются в журналы.

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

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

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

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

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

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

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

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

Криминалистические инструменты полезны только в том случае, если их результат можно защитить. Работа Crow-Eye над корректностью намеренно прозрачна:- Регрессионные наборы тестов. Correlation Engine защищён набором тестов pytest, охватывающим разбор временных меток, нормализацию идентификаторов, разветвление по нескольким временным меткам, контракт писателя, создание Eye (управление GEP на стороне записи) и реестр стандартных полей. Движок UBA поставляется с собственным набором тестов, включая сквозной прогон на реальном деле.

• Валидационный стенд. Целостный стенд проверяет все 7 стандартных крыльев на обоих движках на реальном деле Windows с ~700K записей.
• Опубликованная история дефектов. Регрессии точности и их измеренное влияние открыто задокументированы в RELEASE_NOTES.md — включая случаи, когда исправление меняло количество видимых записей на порядки. Знание того, что было не так и когда, — часть того, что делает результат защитимым.
• Проверяемый учёт доказательств. Каждая запись либо попадает в совпадение, либо в именованный 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, конвейеры.
• Архитектура таймлайна — внутренности модуля таймлайна.
• Архитектура 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: 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**.