Crow-Eye — Moteur d'analyse forensique Windows

Une machine à remonter le temps forensique pour Windows.
Crow-Eye ne se contente pas de détecter — il reconstitue ce qui s'est réellement passé sur la chronologie, de l'acquisition jusqu'à un verdict traçable jusqu'à ses enregistrements sources.

Table des matières

• Aperçu
• ✨ Points forts
• 👥 À qui s'adresse Crow-Eye
• 🧭 Sous-systèmes en un coup d'œil
• 🏗️ Architecture
• 📥 Téléchargement et installation
• 🚀 Démarrage rapide
• 📂 Artefacts pris en charge
• 🔧 Modes d'analyse
  • 📎 Importer des preuves (données tierces)
• 🧠 Analyse du comportement utilisateur (UBA)
• 🧩 Moteur de corrélation
• 👁️ Eye — L'assistant IA forensique
• 📖 Eye-Describe — Base de connaissances sur les artefacts au niveau octet
• 🧪 Qualité et validation
• 🔬 Plateforme de recherche
• 🛠️ Notes techniques
• 📸 Captures d'écran
• 🚧 Feuille de route
• 📚 Documentation
• 🤝 Contribution
• 🌐 Site web et communauté
• 📄 Licence
• 📝 Citation de Crow-Eye
• 💖 Soutien
• Crédits

Aperçu

Crow-Eye est un moteur de forensique Windows open source (GPL-3.0) qui unifie l'acquisition, l'analyse, la vérification, le renseignement et l'IA. La plupart des outils de sécurité se demandent « est-ce malveillant ? » et écartent tout ce qui semble légitime. Crow-Eye pose une question différente : « que s'est-il passé ? » Il corrèle toute l'activité — suspecte ou non — et reconstitue la séquence réelle des événements sur un système, de sorte que la vérité d'une enquête est reconstruite à partir des preuves plutôt que devinée à partir des alertes.

Cette conception qui privilégie la reconstruction est exactement ce qu'il faut pour traquer les APT et les menaces étatiques : les adversaires sophistiqués vivent à l'intérieur d'outils légitimes (powershell.exe, PsExec, certutil) et dans la séquence des actions — invisibles pour les outils qui écartent tout ce qui paraît normal. Parce que Crow-Eye n'écarte jamais rien et raisonne sur les artefacts d'exécution (qui survivent à la falsification des journaux et à l'anti-forensique), l'attaque ne peut pas se cacher. Le même moteur reste accessible pour le travail DFIR quotidien et pour les non-experts qui veulent simplement savoir ce qui s'est passé sur un ordinateur.

• 🕰️ Reconstruire, pas seulement détecter — reconstruire la chronologie de ce qui s'est réellement passé.
• 🖥️ Multi-plateforme — analyse complète en direct + hors ligne sur Windows ; analyse hors ligne et analyse d'images forensiques sur Linux (les analyseurs en direct sont réservés à Windows).
• 🔒 Privé par conception — 0 ms de données envoyées hors de l'appareil ; l'assistant IA Eye peut fonctionner de manière entièrement air-gapped.
• 🧾 Qualité tribunal — les preuves sont scellées cryptographiquement et chaque étape est auditable.
• 📦 Version actuelle : 0.12.6 · Moteur de corrélation : 1.7.0 · Licence : GPL-3.0.

✨ Points forts

• La reconstruction avant la détection. Corrèle chaque artefact en une histoire navigable par entité, plutôt qu'en un tas d'alertes.
• Intégré de bout en bout — acquisition → corrélation → chronologie → analyse comportementale → IA → mémoire de dossier scellée : un pipeline complet qu'aucun outil existant unique ne couvre.
• Profond dans les artefacts, pas superficiel dans les journaux. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists et bien d'autres survivent à l'effacement des journaux et aux astuces « living-off-the-land » qui aveuglent les outils basés uniquement sur les logs.
• L'assistant IA Eye — investigation forensique en langage naturel avec une chaîne de traçabilité auditable et inviolable, exécutable dans le cloud, sur un serveur privé, ou entièrement hors ligne.
• Analyse du comportement utilisateur (UBA) — transforme les artefacts bruts en un récit d'activité en langage clair, lisible par les RH et les examinateurs.
• Gratuit et open source (GPL-3.0) — auditable par tous, avec un effort actif de recherche et de documentation.

👥 À qui s'adresse Crow-Eye

Crow-Eye est utilisé dans des flux de travail très différents. Chacun entre dans le moteur par une porte différente :

N'importe quel collecteur fonctionne. Crow-Eye n'exige pas son propre outil d'acquisition. Pointez l'Importateur hors ligne vers un dossier d'artefacts bruts produits par Velociraptor, KAPE, un paquet de collecte EDR ou tout autre collecteur — il indexe les artefacts pris en charge et exécute les analyseurs hors ligne dessus. Par ailleurs, la sortie de Plaso, Autopsy, Volatility ou de tout autre outil peut être importée en CSV, JSON ou SQLite via Importer des preuves et corrélée avec les artefacts natifs.

🧭 Sous-systèmes en un coup d'œil

Crow-Eye est conçu comme une boucle intégrée — chaque étape alimente la suivante, du disque brut à un verdict défendable.

🏗️ Architecture

Crow-Eye est un pipeline intégré, pas un ensemble d'analyseurs. Les preuves circulent dans un seul sens, et chaque étape conserve son lien vers l'enregistrement source.```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

*Source de preuves → Ingestion → Bases de données de l'affaire → Analyse → Couche IA → Rapport*


**Comment le lire :**

| Étape | Point clé |
|---|---|
| ① → ② | **Quatre portes d'entrée indépendantes vers une affaire.** Vous n'avez jamais besoin du collecteur propre à Crow-Eye — un dossier provenant de Velociraptor, KAPE ou d'un paquet EDR passe par l'Offline Importer, et les CSV/JSON/SQLite tiers passent par Import Evidence. |
| ② → ③ | Tout converge vers un seul endroit : **les bases de données de l'affaire**. Les artefacts analysés arrivent dans `Target_Artifacts/` ; les preuves tierces importées arrivent dans `Imported_Evidence/` et sont automatiquement découvertes. |
| ③ → ④ | **Les trois chemins d'analyse sont indépendants les uns des autres.** La Timeline et l'UBA lisent directement les bases de données de l'affaire — aucune ne nécessite une exécution de corrélation. Le moteur de corrélation (Correlation Engine) est une couche *supplémentaire*, pas un prérequis. |
| ③ → ④ | **Le Dynamic Linking se place aux côtés de la Timeline et de l'UBA** — un quatrième lecteur indépendant des bases de données de l'affaire (il n'a rien à voir avec la visualisation de la Timeline). Il rassemble les correspondances d'identité (SID → nom d'utilisateur, MAC → réseau, hash/GUID → application) dans un `Crow_Intelligence.db` par affaire, puis superpose ce contexte **directement dans les tables de données d'artefacts** via des `ATTACH` + `LEFT JOIN` non destructifs. Il change la façon dont les enregistrements sont *lus*, jamais la preuve. |
| ④ → ⑤ | L'Eye interroge directement les bases de données de l'affaire et peut récupérer les résultats de corrélation **à la demande**. Il ne touche jamais aux preuves elles-mêmes — il émet des appels d'outils que Crow-Eye exécute et journalise. |
| ⑤ → Report | Le **Living Report est construit par l'Eye seul**, via ses outils `report_*`. La Timeline et l'UBA sont des surfaces d'analyse — elles n'écrivent pas dans le rapport. Les conclusions au niveau de l'affaire peuvent néanmoins être exportées séparément via [Search & Export](#-search--export). |
| ⑤ ↔ | La **Narrative Map est bidirectionnelle** : l'Eye y écrit, vous y écrivez, et son contenu est injecté dans le prompt de l'Eye à chaque tour. C'est la mémoire, et vous pouvez la commander. |
| ⑤ ⟳ | La **page Compliance audite l'Eye.** Chaque appel d'outil effectué par l'Eye est ancré à la chaîne de hachage **EvidenceSeal** ; la page affiche en direct l'état **GEP** par règle (10 principes), vérifié à partir de cette chaîne et de `EYE_Logs/`, exportable sous forme de `audit_trail.json`. |

**Étapes indépendantes.** La Timeline et l'UBA lisent **directement** les bases de données d'artefacts de l'affaire — aucune ne nécessite une exécution de corrélation, et la Timeline ne dépend pas du moteur de corrélation (elle applique son propre regroupement temporel léger). La corrélation est une couche d'analyse supplémentaire dont l'Eye peut interroger les résultats.

**Lecture seule par conception.** Le parsing écrit dans la base de données de l'affaire ; chaque étape en aval (UBA, Timeline, visualiseurs de corrélation, Eye) ouvre ces bases de données en **lecture seule**. La preuve d'origine n'est jamais modifiée — [Dynamic Linking](#-analysis-modes) lit les bases de données de l'affaire pour construire un `Crow_Intelligence.db` par affaire des correspondances d'identité et enrichit les tables de données d'artefacts en ligne via des requêtes `ATTACH` + `LEFT JOIN` non destructives plutôt que de réécrire les lignes.

**Gouverné par conception.** Chaque action de l'Eye est ancrée à la chaîne de hachage inviolable **EvidenceSeal**, et la page **Compliance** vérifie en continu l'Eye par rapport au [protocole Ghassan Elsman (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) — état en direct par règle, exportable vers `EYE_Logs/audit_trail.json`.

## 📥 Téléchargement et installation

> **Recommandé :** obtenez la version Windows packagée (**installateur MSI / EXE**) depuis le site officiel — aucune configuration Python nécessaire, fonctionne immédiatement.

### ▶️ [Télécharger Crow-Eye pour Windows → crow-eye.com/download](https://crow-eye.com/download)

La **version installée MSI/EXE est le moyen recommandé d'utiliser Crow-Eye**, et c'est notre **priorité absolue pour les mises à jour** :

- 🛡️ **Correctifs les plus rapides.** Lorsqu'un problème est détecté ou qu'un bug est signalé, nous publions un EXE mis à jour **dès que possible** — la version packagée est celle qui reçoit les correctifs en premier.
- 🔄 **Mise à jour automatique intégrée.** Dans l'application installée, ouvrez **Settings → Updates** pour **vérifier les mises à jour et les installer automatiquement** — aucune réinstallation manuelle.
- 📦 **Aucune configuration.** Aucune installation de Python, Node ou dépendance requise.

> Vous préférez exécuter à partir des sources ? Voir **[Quick Start](#-quick-start)** ci-dessous. La version depuis les sources est destinée aux contributeurs et **n'inclut pas la mise à jour automatique** — utilisez le MSI/EXE pour les mises à jour automatiques.

## 🚀 Quick Start

### Option A — Version installée (recommandée)
Téléchargez le **MSI/EXE** depuis [crow-eye.com/download](https://crow-eye.com/download), installez-le, puis lancez **Crow-Eye** en tant qu'administrateur. Créez une affaire et commencez l'analyse.

### Option B — Exécution depuis les sources (développeurs)

> Pour les contributeurs et les utilisateurs avancés. Ce chemin **n'inclut pas la mise à jour automatique** — utilisez le MSI/EXE pour les mises à jour automatiques.

**Prérequis** (installés automatiquement au premier lancement) :
- Python 3.12.4
- **Node.js & npm** — requis pour la **visualisation de la Timeline**
- Paquets clés : PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**Matériel recommandé**

| | Minimum | Recommandé pour les grandes affaires |
|---|---|---|
| **RAM** | 8 Go | 16 Go+ (ensembles MFT/USN de millions d'enregistrements) |
| **Disque** | 5 Go libres | Espace libre ≥ 2× la taille des preuves analysées |
| **CPU** | 4 cœurs | 8+ cœurs |
| **OS** | Windows 10/11 (complet) · Linux (analyse hors ligne et d'images) | — |

> La corrélation diffuse en mémoire constante pour les très grands ensembles de données, donc la RAM est rarement la limite stricte — le débit disque et l'espace libre le sont généralement.

**Lancement** (exécutez en tant qu'administrateur afin que Crow-Eye puisse accéder aux artefacts système) :```bash
python "Crow Eye.py"

L'interface principale s'ouvre, vous créez un dossier d'enquête (case), et toute la sortie d'analyse est organisée sous ce dossier pour un examen et un rapport ultérieurs.

🖥️ Note multiplateforme : sur Linux, les analyseurs en direct sont désactivés automatiquement et Crow-Eye fonctionne en mode hors ligne / image forensique. L'acquisition en direct complète est réservée à Windows.

📂 Artefacts pris en charge

Crow-Eye analyse un large ensemble d'artefacts Windows liés à l'exécution, au système de fichiers et à l'activité utilisateur, à la fois depuis un système en direct et depuis des sources hors ligne (dossiers collectés ou images forensiques).

Jump Lists et LNK sont analysés par le parseur LNK / Jump List dédié de Crow-Eye — et non par un module tiers.

Registre personnalisé / fichiers verrouillés : Windows verrouille les ruches de registre en direct (NTUSER.DAT, SOFTWARE, SYSTEM) pendant son fonctionnement. Pour une analyse personnalisée d'un système en direct, démarrez à partir d'un support externe (WinPE/Live CD), utilisez des outils d'acquisition forensique ou analysez une image disque.

Détails par artefact

• Jump Lists et LNK — analysés automatiquement depuis les emplacements système standard par le parseur dédié de Crow-Eye (accès aux fichiers, chemins cibles, horodatages et métadonnées).
• Registre — analyse automatiquement les ruches système. Pour une analyse de registre personnalisée, copiez les fichiers de ruche vers CrowEye/Artifacts Collectors/Target Artifacts (ou le dossier registry/ de votre dossier d'enquête) :
  • NTUSER.DAT depuis C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE depuis C:\Windows\System32\config\SOFTWARE
  • SYSTEM depuis C:\Windows\System32\config\SYSTEM
  • Windows les verrouille pendant son fonctionnement — pour un système en direct, démarrez à partir d'un support externe (WinPE/Live CD), utilisez des outils d'acquisition forensique ou analysez une image disque.
• Prefetch — analyse C:\Windows\Prefetch, extrayant l'historique d'exécution et les métadonnées forensiques (y compris les horodatages par exécution).
• Journaux d'événements — analyse automatique des journaux Système/Sécurité/Application dans une base de données pour une analyse complète.
• ShellBags — révèle l'historique d'accès aux dossiers et les schémas de navigation des utilisateurs.
• Corbeille — analyse $RECYCLE.BIN pour récupérer les noms de fichiers supprimés, les chemins d'origine, les heures de suppression et les tailles (systèmes en direct et images disque).
• MFT — analyse la Master File Table pour les métadonnées de fichiers, les attributs, les horodatages et les informations sur les fichiers supprimés (NTFS, Windows 7/10/11).
• USN Journal — suit les événements de création/modification/suppression/renommage de fichiers avec horodatages et historique complet des noms, pour la reconstruction de chronologie.
• SRUM — visualise l'utilisation des ressources applicatives (barres de durée pour le temps avant-plan/arrière-plan) et l'activité réseau par application.
• Analyseur de forensique de stockage — vue arborescente complète de chaque disque physique et de ses partitions ; types de partitions codés par couleur (EFI, Linux, Récupération, Cachées/swap, …) ; avertissements pour les clés USB bootables, les racines Linux cachées et Intel Rapid Start ; repli par analyse magique des secteurs bruts.

🔧 Modes d'analyse

🦅 Acquisition Crow-Claw

Crow-Claw est le moteur d'acquisition spécialisé de Crow-Eye pour collecter et préserver les artefacts des systèmes en direct ou des images montées.

• Collecte sélective — choisissez des catégories d'artefacts spécifiques (Registre, Journaux d'événements, Système de fichiers) ou tout collecter.
• Analyse approfondie — parcourt les dossiers et sous-dossiers pour trouver les traces forensiques.
• Préservation sécurisée — les artefacts atterrissent dans un dossier d'enquête structuré qui maintient l'intégrité forensique.

🔍 Analyse hors ligne (importateur hors ligne)

Analysez les artefacts collectés depuis n'importe quelle source sans connexion en direct à la cible — trois opérations claires :

• SCAN (découverte) — parcourt la source et indexe chaque artefact pris en charge par modèle de nom de fichier et d'extension (rapide, en lecture seule ; aucun contenu de fichier n'est lu et aucune vérification d'octets magiques n'est effectuée à cette étape). Rien n'est déplacé.
• COLLECT (acquisition) — copie physiquement les fichiers identifiés dans le dossier live_acquisition du dossier d'enquête, organisés par type.
• PARSE (granulaire) — examine les éléments identifiés par type (AMCACHE, EVTX, PREFETCH, …) et analyse les fichiers sélectionnés (ou tous) dans la base de données forensique.

L'analyse est gérée par les analyseurs hors ligne dédiés de Crow-Eye — la même logique d'artefacts qu'en mode en direct, appliquée aux fichiers collectés : Prefetch, Registre, MFT, USN (plus le corrélateur MFT/USN), AmCache, ShimCache, SRUM, journaux d'événements, LNK/JumpLists et Corbeille.

📎 Importer des preuves (données tierces)

Au-delà des artefacts bruts, Crow-Eye peut intégrer directement la sortie forensique tierce dans un dossier d'enquête — Plaso, Autopsy, Volatility ou toute exportation personnalisée — et la rendre utilisable par l'Eye et la Chronologie sans nécessiter au préalable une exécution de corrélation.

Étant donné que le gestionnaire de base de données du dossier d'enquête découvre automatiquement tout .db sous l'arborescence du dossier, les preuves importées deviennent immédiatement disponibles pour :

• The Eye — interrogable en langage naturel aux côtés des artefacts natifs (le manifeste de schéma est actualisé à l'importation).
• La Chronologie interactive — servie comme type d'artefact imported, avec filtrage par fenêtre de temps et bornes temporelles fonctionnels.
• Le moteur de corrélation — utilisable comme Feather pour la corrélation inter-outils avec les artefacts natifs.

L'importateur ne dépend que de la bibliothèque standard (sqlite3 / csv / json) et s'exécute sur un travailleur en arrière-plan, de sorte que les importations volumineuses ne bloquent pas l'interface.

⚡ Analyse en direct

Analyse directement les artefacts du système Windows en cours d'exécution, avec extraction automatique depuis leurs emplacements standard pour une analyse forensique en temps réel.

🗂️ Gestion des dossiers d'enquête

Chaque investigation est un dossier d'enquête : un répertoire autonome qui organise les bases de données d'artefacts et la sortie d'analyse. Crow-Eye suit les dossiers récents (avec favoris, étiquettes et statut), valide un dossier à l'ouverture, écrit la configuration de manière atomique (résistante aux crashs) et prend en charge l'import/export de configuration et des modèles avec des mappages sémantiques prêts à l'emploi.

🕰️ Visualisation de chronologie interactive

Corrélez les événements entre artefacts sur une grille temporelle unifiée, avec les vues Heat Map, Semaine et Jour — une histoire reliée par identité et traçable en justice plutôt qu'une super-chronologie plate.

La Chronologie lit les bases de données d'artefacts analysées du dossier d'enquête directement et est indépendante du moteur de corrélation — vous n'avez pas besoin de construire des feathers, d'écrire des wings ni d'exécuter un pipeline pour l'utiliser. Elle applique son propre regroupement temporel léger (corrélation par horodatage exact et par fenêtre de temps, regroupement par application, chemin ou utilisateur) pour relier les événements sur la grille. Les preuves apportées via Import de preuves apparaissent également sur la chronologie comme type d'artefact imported, avec filtrage par fenêtre de temps et bornes temporelles fonctionnels.

🔎 Recherche et export

Recherche en texte intégral dans la base de données du dossier d'enquête, plus export en CSV (feuilles de calcul), JSON (intégration avec d'autres outils) et rapports HTML détaillés (dossiers complets regroupant chaque artefact lié à un terme de recherche).

🔗 Liaison dynamique

Traduisez les identifiants techniques bruts — SID, adresses MAC, hachages — en contexte lisible par l'humain à la volée. La liaison dynamique enrichit la vue via des requêtes SQL ATTACH non destructives, de sorte que la preuve d'origine n'est jamais modifiée, et elle peut ingérer des flux de renseignements IOC en masse pour signaler en ligne les indicateurs connus comme malveillants.

🧠 Analyse du comportement utilisateur (UBA)

Transformez les artefacts bruts en un récit d'activité en français courant — un compte rendu lisible par un manager/RH de ce qu'un utilisateur et ses applications ont réellement fait, chaque affirmation étant traçable jusqu'à la preuve source exacte.

L'analyse du comportement utilisateur (UBA) lit les bases de données d'artefacts analysées dans le dossier Target_Artifacts/ de votre dossier d'enquête (strictement en lecture seule) et les rejoue à travers un ensemble de règles déclaratives pour produire une Histoire d'activité claire et chronologique. Ouvrez-la depuis le bouton de la barre d'outils « User Behavior » ou avec Ctrl+Shift+B (un dossier d'enquête doit être chargé).

• 🧩 40 détections comportementales déclaratives (uba/config/behavior_rules.json) — ajustables sans code — chacune classée par sévérité : routine · notable · suspect · critique.
• 🕵️ Détecte les comportements qui comptent : connexion / déconnexion / déverrouillage, lancement · exécution · installation de programme, ouverture / suppression / copie inférée de fichier, connexion de périphérique USB, accès à un partage réseau, persistance et démarrage automatique, utilisation d'identifiants explicites (runas), modifications de comptes et de groupes, modifications de services, altération de l'horloge système (suspect) et effacement des journaux d'événements (critique).
• 🗺️ Trois vues — un flux Histoire d'activité, une carte de chaleur Activity Map (jour × heure) et un rapport d'honnêteté « Ce que nous pouvons voir » qui étiquette chaque détection Fonctionne / Limitée / Aucune donnée / Par conception pour ce dossier.
• 🔗 Chaque activité est adossée à une preuve. Cliquez sur n'importe quel élément pour ouvrir l'enregistrement source exact (database : table : rowid) — rien n'est affirmé sans source.
• 👤 Attribution honnête. Les acteurs se résolvent en Utilisateur / Application / Système (ou restent vides) — UBA ne devine jamais qui a fait quoi.

Couverture des détections

Les 40 détections couvrent quatre classes de sévérité et toute l'étendue de l'ensemble d'artefacts analysés :

Filtres : texte libre · utilisateur/acteur (y compris « Non attribué » et une bascule de session connectée) · classe de comportement (utilisateur / application / système) · sévérité · application (sélection multiple recherchable parmi 200+ programmes) · plage de date/heure avec préréglages rapides (tout le temps / premier jour / dernier jour / dernière heure d'activité).

Sources de données : journaux d'événements Sécurité, Système et Application · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · Corbeille · SRUM (application, réseau, connectivité) · ruches de registre.

Garanties forensiques

• Lecture seule. Les bases de données sources sont ouvertes en lecture seule ; l'analyse ne touche jamais à la preuve.
• Provenance complète. Chaque événement porte database → table → rowid et ouvre les lignes sources réelles à la demande.
• L'attribution ne devine jamais. Un événement est attribué à un Utilisateur, une Application, le Système — ou laissé vide. Les sessions d'ouverture de session interactives sont utilisées uniquement comme étiquettes contextuelles (« pendant la session de <user> »), jamais pour attribuer une action.
• Formulation honnête. Le libellé distingue l'interaction délibérée (UserAssist, SRUM avant-plan) des artefacts qu'une application peut également générer (ShellBags, LNK, JumpLists), avec des avertissements explicites affichés sur la carte.
• L'absence est déclarée, pas sous-entendue. Le rapport Ce que nous pouvons voir étiquette chaque détection pour ce dossier spécifique, de sorte que les données manquantes ne sont jamais silencieusement lues comme « rien ne s'est passé ».

L'UBA est une corrélation et classification comportementale pilotée par règles, et non une évaluation statistique/ML d'anomalies — chaque constat correspond à une règle explicite et auditables. Voir RELEASE_NOTES.md pour le catalogue complet des détections.

🧩 Moteur de corrélation

Moteur de corrélation v1.7.0 — le cœur de la reconstruction. Voir RELEASE_NOTES.md pour l'historique des versions.

Le moteur de corrélation Crow-Eye est un système de corrélation forensique de qualité production. Il ingère les artefacts Windows de n'importe quelle source, les normalise et fait ressortir les relations temporelles et d'identité qui transforment des enregistrements isolés en un récit cohérent de ce qui s'est passé sur un système, quand, et qui était impliqué. Il fonctionne immédiatement avec des règles de corrélation intégrées (Wings) pour les questions d'investigation les plus courantes, permet aux analystes de créer des règles personnalisées sans toucher au code, et délègue la signification à des règles rédigables et à l'enquêteur — jamais à un score de boîte noire.

🎥 Guide utilisateur

Import de données universel : le moteur de corrélation peut prendre la sortie de n'importe quel outil forensique au format CSV, JSON ou SQLite et la convertir en base de données Feather. Cela signifie que vous pouvez corréler les données d'outils tiers (Plaso, Autopsy, Volatility, etc.) avec les artefacts natifs de Crow-Eye, créant ainsi une analyse de corrélation unifiée sur toutes vos sources de données forensiques.

🎯 Précision et exhaustivité des preuves

Une passe de précision ciblée, validée de bout en bout sur un vrai dossier Windows d'environ 700 000 enregistrements, superposée à des travaux de fiabilité antérieurs. Chaque correctif ci-dessous est verrouillé par la suite de régression pytest et vérifié par un harnais de validation holistique qui exerce les 7 wings par défaut sur les deux moteurs.

Le moteur d'identité capture toutes les preuves

• Corrigé : le moteur d'identité ne parcourait que la PREMIÈRE ligne de chaque feather lorsqu'un filtre temporel était actif (une comparaison de datetime avec/sans fuseau horaire déclenchait TypeError et interrompait la boucle ligne par ligne). Les enregistrements vus sont passés de 3 558 → 745 615 sur le dossier de validation.
• Corrigé : les enregistrements de journal réduisaient chaque événement à son fournisseur d'événements comme identité (les 33 855 enregistrements SecurityLogs partageaient une seule identité). Le mappage par artefact privilégie désormais les entités réelles par ligne (User, ComputerName, NewProcessName, TargetUserName) avant les métadonnées de canal/fournisseur.
• Corrigé : le mappage de champs sensible à l'artefact ne se déclenchait jamais car les analyseurs n'apposent pas de colonne artifact sur chaque ligne. Le moteur retombe désormais sur feather_metadata.artifact_type, de sorte que SecurityLogs / SystemLogs / ApplicationLogs utilisent leur priorité d'identité spécifique à l'artefact.
• Corrigé : les chaînes d'espace réservé devenaient de fausses identités ('N/A', 'Unknown', '-', GUID nuls regroupaient des enregistrements sans rapport). Le validateur rejette désormais plus de 30 variantes d'espace réservé.
• Résultat net sur une fenêtre pleine portée : le wing Preuve d'exécution fait ressortir 2 856 correspondances inter-feather (High) dans le moteur d'identité et 643 correspondances inter-feather dans le moteur temporel, avec 24 à 118 correspondances inter-feather par wing sur les 6 autres wings.

Fini le « tout est Low — quelque chose cloche »

• Corrigé : les correspondances mono-feather étaient étiquetées High. Les correspondances avec feather_count == 1 reçoivent désormais confidence_category="Low - single feather", de sorte que la vue High se concentre sur la véritable corrélation inter-feather.
• Corrigé : une clé composite sensible au chemin scindait la même identité entre les feathers (chaque feather stocke les chemins différemment, donc chrome avait 10+ clés et ne se corrélait jamais). La clé est désormais basée uniquement sur le nom — la corrélation inter-feather fonctionne à nouveau.

Détection d'usurpation par classification de chemins — après la formation d'une correspondance, le moteur classe le chemin de chaque enregistrement comme FIABLE (Program Files, System32, WinSxS, les formes BAM/SRUM /device/harddiskvolumeN/..., …) ou SUSPECT (Temp, Downloads, Public, AppData\Local\Temp, Corbeille, racines amovibles, partages réseau). Une correspondance couvrant les deux classifications lève impersonation_alert (≈0,05 % de taux, chacun un vrai candidat).

Comptabilité honnête des preuves — un registre des abandons par fenêtre avec des catégories nommées (no_identity_field, normalize_failure, below_threshold_skipped, …) plus un résumé par pipeline (enregistrements vus, high/low émis, sans identité, catégories d'abandon, jointures de feathers sans temps). Chaque enregistrement atterrit soit dans une correspondance, soit dans une catégorie d'abandon nommée — « aucune preuve restante » est vérifiable depuis le journal. low_confidence_review_mode est activé par défaut, de sorte que les groupes sous le seuil deviennent des correspondances à faible confiance au lieu de disparaître silencieusement.

Enrichissement d'identité pour feathers sans temps — les feathers sans horodatage par ligne (AutoStartPrograms, MUICache, SystemServices, TypedPaths) ne reçoivent plus un faux horodatage de génération sur chaque ligne ; au lieu de cela, après la formation des correspondances temporelles, le moteur joint les enregistrements correspondants de chaque feather sans temps par identité comme preuve supplémentaire.

Registre d'identité consolidé — config/standard_fields/identities.json est la source unique de vérité pour chaque colonne que les moteurs et l'Eye doivent consulter : 98 catégories, 1 146 synonymes de colonnes (application/processus, fichier, hachage, utilisateur, hôte/périphérique, réseau, registre, service/tâche, événement, e-mail, navigateur, cloud, internes Windows, certificat, conteneur, objets OS). Ajouter un nouveau synonyme de colonne est une modification JSON, pas un changement de code.

Correctifs de faux positifs du mappage sémantique — le déclenchement multi-indicateurs est désormais réellement appliqué (data-exfiltration-pattern requiert ≥2 indicateurs) ; les règles AND impossibles (4625 AND 4624) réécrites en OR ; les règles wiper/outil distant utilisent de vraies expressions régulières au lieu de se déclencher sur chaque entrée Prefetch ; les règles d'activité de base déclassées de high/critical à info/low (la notation pondérée du wing fait monter les vraies menaces).

✅ Statut de production

Le moteur de corrélation est prêt pour la production et activement utilisé dans les investigations (moteur de corrélation v1.7.0) :- ✅ Moteur de balayage par fenêtre temporelle — prêt pour la production, recommandé pour l’analyse temporelle (O(N log N))

• ✅ Moteur basé sur l’identité — prêt pour la production, recommandé pour le suivi des identités (O(N log N))
• ✅ Feather Builder / FeatherWriter — importe du CSV/JSON/SQLite depuis n’importe quel outil ; traitement par lots transactionnel + métadonnées de schéma
• ✅ Système Wings & orchestration de pipeline — créer/gérer des règles de corrélation et automatiser des flux de travail
• ✅ Regroupement d’identités — unifié entre le moteur, les visualiseurs et la phase sémantique
• ✅ Registre des champs standard — source de vérité centralisée pour les synonymes de champs
• ✅ Fan-out multi-horodatage — chaque horodatage de liste JSON est corrélé
• 🔄 Corrélation parallèle — fondations en place ; profilage + répartition par pool de processus ensuite
• 🔄 Mappage sémantique & scoring de corrélation — améliorations en cours

Fonctionnalités clés

• 🔄 Architecture à double moteur: Choisissez entre les stratégies de corrélation par balayage par fenêtre temporelle (O(N log N)) et par identité (O(N log N)).
• 📊 Prise en charge multi-artefacts: Corrélez Prefetch, ShimCache, AmCache, journaux d’événements, fichiers LNK, listes de saut, MFT, USN, SRUM, Registre, RecycleBin et plus encore.
• 🔌 Import universel: Importez les sorties CSV/JSON/SQLite de n’importe quel outil forensique et convertissez-les en bases de données Feather.
• 🎯 Regroupement intelligent des identités: Les variantes comme Chrome.exe/chrome.dll/Chrome.EXE se regroupent dans un même compartiment ; les versions et les qualificatifs architecturaux restent distincts.
• 🕒 Horodatages tolérants: FILETIME, ISO 8601, époque Unix (s/ms/μs), YYYYMMDD, barre oblique américaine et chaînes annotées sont tous analysés correctement du premier coup.
• 📈 Fan-out multi-horodatage: Les listes d’horodatages JSON (Prefetch run_times) sont développées afin que chaque exécution obtienne son propre événement de corrélation.
• 🧰 Une seule source de vérité: Les synonymes de champs dans config/standard_fields/*.json ; les métadonnées par table dans correlation_engine/config/feather_schemas.json — étendez en modifiant le JSON, pas le code.
• ⚡ Flux continu + thread-safe: query_time_range_iter à mémoire O(1) ; caches Feather protégés par verrous ; prêt pour la corrélation parallèle.
• 🔍 Règles flexibles: Définissez des règles de corrélation personnalisées (Wings) avec des paramètres configurables.
• 📋 Diagnostics honnêtes: Ligne de statistiques par fenêtre (records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted) afin que vous sachiez toujours si des preuves ont été écartées.
• 🧪 Qualité verrouillée: Une suite de tests de régression pytest couvrant l’analyse des horodatages, la normalisation des identités, le fan-out, le contrat d’écriture, la création Eye (gouvernance GEP côté écriture) et le registre des champs standard.

Architecture système

Le moteur de corrélation se compose de quatre composants principaux:

1. 🗄️ Feathers (Normalisation des données)

Objectif: Transformer les artefacts forensiques bruts en un format standardisé et interrogeable.

• Bases de données SQLite contenant des données d’artefacts forensiques normalisées — un feather par type d’artefact (Prefetch, ShimCache, journaux d’événements, …) avec un schéma standardisé et des métadonnées pour une interrogation efficace.
• Un format universel qui accepte les données de n’importe quel outil forensique.``` 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

**Formats d'importation pris en charge :** CSV (tout fichier avec en-têtes), JSON (plat ou imbriqué), et SQLite (import direct). Mappage automatique des colonnes, détection du type de données, normalisation des horodatages en ISO, validation et index optimisés.```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Ailes (règles de corrélation)

Objectif: Définir quels artefacts corréler et comment.

• Des règles JSON/YAML spécifiant une fenêtre temporelle, un nombre minimal de correspondances, une priorité d'ancre, et les plumes (avec des poids) à corréler — réutilisables entre les cas. Chaque aile est créable et scellée (enregistre qui l'a créée, pourquoi, et les preuves qui l'ont motivée).```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. ⚙️ Moteurs (Stratégies de corrélation)

**Objectif**: Exécuter la logique de corrélation pour trouver des relations entre les artefacts. Les liens structurels viennent **en premier**; un score pondéré par niveau est superposé en tant qu'*interprétation/classement*, et non comme base de correspondance.

**Moteur d'analyse par fenêtre temporelle** — idéal pour l'analyse basée sur le temps et la corrélation temporelle systématique. Analyse le temps à intervalles fixes, collecte les enregistrements de toutes les plumes par fenêtre, applique la correspondance de champs sémantiques + un score pondéré, et évite les doublons grâce au suivi MatchSet. **O(N log N)** (requêtes horodatées indexées); traitement par lots (~2,567 fenêtres/seconde).

**Moteur de corrélation basé sur l'identité** — idéal pour les grands ensembles de données (>1,000 enregistrements) et le suivi d'identité. Extrait et normalise les identités, regroupe les enregistrements par identité, construit des ancres temporelles dans chaque cluster, classe les preuves en primaires/secondaires/complémentaires, et diffuse en continu pour les très grands ensembles (>5,000 ancres) avec une mémoire constante. **O(N log N)**; 40+ motifs de champs d'identité par type.

**Sélection du moteur:** utilisez le moteur d'analyse par fenêtre temporelle pour l'analyse basée sur le temps et le moteur de corrélation basé sur l'identité pour le suivi d'identité — les deux sont prêts pour la production et optimisés pour les grands ensembles de données avec des requêtes indexées.

#### 4. 🔄 Pipelines (Orchestration des workflows)

**Objectif**: Automatiser des workflows d'analyse complets, de la création de plumes à la génération des résultats. Un pipeline lit sa configuration (type de moteur, ailes, plumes), instancie le bon moteur via l'EngineSelector, exécute chaque aile, agrège les correspondances, enregistre les résultats (DB + JSON), et les affiche dans la GUI avec filtrage et visualisation.```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"
  }
}

Comment tout fonctionne ensemble```

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

### Exemple d'utilisation : Recherche de preuve d'exécution

**Scénario** : prouver que `malware.exe` a été exécuté sur un système.```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:". Please supply chunk 18 so I can translate it.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

No content was provided to translate. The input section is empty.```
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

Benchmarks de performance

Prise en main du moteur de corrélation

1. Lancer : python -m correlation_engine.main
2. Créer des Feathers : importez vos artefacts forensiques (Prefetch, ShimCache, …).
3. Créer des Wings : définissez des règles de corrélation pour votre enquête.
4. Créer un Pipeline : configurez les wings et feathers à utiliser.
5. Exécuter : lancez le pipeline et consultez les résultats corrélés.
6. Analyser : utilisez le visualiseur de résultats pour explorer les relations temporelles.

📚 Documentation du moteur de corrélation

• Vue d'ensemble du moteur de corrélation — vue d'ensemble du système avec schémas d'architecture
• Documentation du moteur — architecture double moteur, sélection du moteur, optimisation des performances
• Architecture — intégration des composants et flux de données
• Documentation des Feathers — le système de normalisation des données
• Documentation des Wings — règles de corrélation
• Documentation du Pipeline — orchestration des flux de travail
• Ajouter un artefact — le flux de travail pour brancher un nouveau parseur sur le moteur
• Registre des champs standard — synonymes canoniques des noms de colonnes chargés par les deux moteurs et par l'Eye
• Guide de contribution — comment contribuer au moteur
• Liens rapides : Sélection du moteur · Dépannage · Optimisation des performances

👁️ Eye — L'assistant IA forensique

Un assistant puissant, pas un substitut. Eye automatise et vérifie les hypothèses d'un enquêteur — il ne décide jamais à votre place.

Eye est l'assistant IA forensique intégré de Crow-Eye : un enquêteur forensique chevronné adossé à une véritable base de connaissances sur les artefacts Windows. Il offre une interface en langage naturel pour interroger, corréler et documenter tout ce qui concerne une affaire — Prefetch, MFT, Registre, journaux d'événements, AmCache, ShimCache, SRUM, et plus encore — tout en conservant une trace auditable et infalsifiable de ce qu'il a exactement fait. Eye peut fonctionner entièrement sur votre propre matériel (y compris en mode totalement déconnecté / air-gapped), conformément à la position de confidentialité « 0 ms de données envoyées hors de l'appareil » de Crow-Eye. Architecture complète : eye/README.md.

Eye transforme les questions conversationnelles (« montre-moi ce qui a été exécuté depuis C:\Temp après 22 h 00 ») en véritable travail forensique : il planifie une approche, récupère les connaissances pertinentes sur les artefacts, exécute des requêtes SQL et des recherches inter-artefacts sur les bases de données de l'affaire, puis synthétise une réponse validée. Chaque réponse est produite en deux endroits à la fois — une réponse de discussion pour vous, et un bloc structuré écrit dans un Espace de travail du Rapport vivant, si bien que le dossier se construit de lui-même au fil de l'enquête.

Le Protocole Ghassan Elsman (GEP)

Tout ce que fait Eye est ancré dans le Protocole Ghassan Elsman (GEP) — une norme indépendante du fournisseur et de l'outil définissant comment toute IA doit être utilisée en criminalistique numérique. Elle se compose de 10 principes qu'un système conforme doit respecter pour que les conclusions assistées par IA restent véridiques, traçables jusqu'aux enregistrements sources, et adossées à une chaîne auditable et infalsifiable, avec l'enquêteur humain aux commandes :

Eye de Crow-Eye est l'implémentation de référence du GEP ; les comportements intégrés au produit qui le font respecter sont les Règles opérationnelles. 📜 Lisez la norme : eye/docs/GEP_standard.md.

Modes de déploiement

Eye s'adapte à votre modèle de menace grâce à trois modes de déploiement :

En mode agent CLI, Crow-Eye pilote un agent IA de terminal/ligne de commande existant en tant que modèle — au lieu d'une API cloud ou d'un serveur local hors ligne — afin d'enquêter avec l'agent que vous utilisez déjà.

La boucle d'enquête :

1. Ouvrir ou créer une affaire — Eye se limite aux bases de données d'artefacts et à l'historique de cette affaire.
2. Poser une question en langage naturel, ou lancer un triage complet en un clic.
3. Eye exécute son pipeline — détection de l'intention → récupération des connaissances → exécution des outils → synthèse.
4. Vous obtenez une double sortie — une réponse directe dans la discussion et un nouveau bloc dans le Rapport vivant.
5. Approuver les actions bloquées — les exports et autres étapes critiques attendent votre accord.

Vous pouvez changer de modèle à l'exécution grâce à l'outil switch_model. Le changement est restreint au même backend, afin que les preuves ne soient jamais envoyées silencieusement à un fournisseur différent de celui que vous avez choisi.

Suivi du processus de réflexion du LLM

Eye est conçu pour que vous puissiez voir — et plus tard prouver — comment il est parvenu à une conclusion. Pendant qu'il travaille, Eye diffuse des mises à jour structurées ThinkingStep à l'interface en temps réel ; chacune porte un step_id, un type, un label lisible par l'humain, un status (active → done, ou error), et éventuellement tool/params/detail.

Une requête typique se déroule comme thinking → rag → thinking → tool_call → synthesis, et chaque affaire conserve des artefacts de trace sur disque que vous pouvez inspecter par la suite :

Exécution des outils

Eye est piloté par les outils : le modèle n'accède jamais directement aux preuves. Il émet des appels d'outils, et Eye les exécute sur les bases de données de l'affaire puis renvoie les résultats — de sorte que chaque action est explicite, journalisée et reproductible. Les outils sont définis dans configs/llm_config.json et distribués via eye/services/context_manager.py.

Outils d'investigation — lire et analyser les preuves :

Les outils de rapport construisent l'espace de travail du Rapport vivant : 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, et export_report (l'export exige l'approbation humaine).

Outils d'écriture (encadrés — voir Créer des Wings de corrélation et des mappages sémantiques) : correlation_create_wing, correlation_edit_wing, correlation_create_semantic_mapping, correlation_edit_semantic_mapping. Les appels d'outils sont traduits dans ce que le backend actif attend — appel de fonction natif pour les API cloud et serveurs locaux, ou enveloppe XML <tool_call> pour les agents CLI.

Créer des Wings de corrélation et des mappages sémantiques

Eye ne se contente pas de consulter le moteur de corrélation — il peut aider à l'étendre. Lorsqu'Eye repère un motif récurrent inter-artefacts, il peut proposer de nouvelles Wings (règles de corrélation) et de nouveaux mappages sémantiques (traductions technique-à-humain). C'est de l'écriture encadrée : Eye propose, l'analyste examine l'artefact enregistré, et chaque modification est justifiée et étayée par des preuves.

Une Wing relie des feathers dans une fenêtre temporelle et un seuil de correspondance minimal pour prouver une affirmation :

Un mappage sémantique traduit une valeur technique brute en signification lisible par l'humain (ex. EventID 4624 → « Connexion réussie »). Il existe en deux variantes : un mapping simple (valeur unique / regex → valeur sémantique) ou une rule multi-conditions (conditions reliées par AND/OR). Les deux prennent en charge category, severity, confidence et scope, et exigent tous deux reason + related_evidence.

Gouvernance — règles côté écriture qui font respecter le GEP :

• Raison obligatoire (fait respecter GEP-9 + GEP-2) : chaque création et modification doit inclure une reason forensique.
• Lien vers la preuve (fait respecter GEP-2) : chaque création doit citer au moins une référence database:table:rowid.
• Estampillé Eye / lecture seule pour les autres (fait respecter GEP-7 + GEP-9) : Eye appose sa signature d'auteur + sa raison + l'historique des modifications et ne peut modifier que ce qu'Eye a créé — les règles intégrées et celles créées par l'humain restent en lecture seule.

Contexte auto-réparateur

Les enquêtes longues peuvent dépasser la fenêtre de contexte d'un modèle — en particulier les modèles hors ligne plus petits. Plutôt que de planter ou de supprimer silencieusement des preuves, Eye compacte automatiquement son propre contexte avant chaque appel de modèle (dans son chemin de génération gardé, entièrement audité).

Avant chaque appel, Eye mesure la charge utile complète et réserve de la place pour la réponse (10 % de la fenêtre, minimum 512 jetons, jamais plus de la moitié). Si elle ne tient toujours pas, il se répare en deux passes ordonnées, sans jamais toucher aux messages protégés (épinglés, preuves détectées automatiquement, ou résultat d'un outil) :

1. Passe de résumé (une fois) — l'historique non protégé est condensé en un résumé, journalisé SUMMARIZED.
2. Passe de suppression — le message non protégé le plus ancien est retiré un par un jusqu'à ce que cela tienne, journalisé TRUNCATED.

Si le noyau de preuves irréductible (messages épinglés + résultats d'outils + la question courante) déborde encore, Eye refuse de continuer plutôt que de tronquer les preuves (REFUSED_OVERFLOW) et vous demande de réduire la requête ou d'utiliser analyze_large_dataset. Ce qui part finalement vers le modèle est la charge utile exacte qui est scellée pour la chaîne de traçabilité.

🗺️ Carte narrative — La mémoire persistante de l'affaire pour l'Eye

L'Eye est sans état entre les tours — c'est donc la Carte narrative qui abrite « ce que nous savons et ce que nous avons conclu » pour une affaire. C'est la mémoire de travail persistante, audible et infalsifiable de l'Eye, et son contenu est injecté dans le prompt de l'Eye à chaque tour (la carte est littéralement la mémoire).

• 🧭 Verdict → Récit → Preuve. Une hiérarchie stricte : un Verdict par affaire, les Récits en dessous (affirmations, chacune avec un état — proven · open · negative · needs · absolute), et les Preuves adossées aux artefacts en dessous.
• 🪟 Sa propre fenêtre. S'ouvre depuis le bouton « Carte narrative » de la fenêtre de discussion de l'Eye, afin de pouvoir regarder la discussion, le rapport vivant et la mémoire de l'affaire côte à côte ; elle se rafraîchit en direct au fil des changements.
• ↔️ Bidirectionnelle — une mémoire que vous contrôlez. Les modifications de l'Eye comme vos propres notes passent par un unique commit validé GEP et sont scellées dans un journal d'audit chaîné par hachage (narrative_map_audit.jsonl). Vous pouvez ajouter, modifier et supprimer ses affirmations et ses preuves, en façonnant directement la manière dont l'Eye comprend et interprète l'affaire.
• 🚫 N'affirme jamais ce qui n'est pas étayé. Un récit de l'Eye peut rester open sans preuve pendant qu'il enquête, mais il ne peut jamais être proven sans preuve ; un thème que l'Eye a vérifié mais trouvé vide se convertit automatiquement en negative — car une absence documentée est en soi un résultat.

Comment fonctionne la conformité

La conformité n'est pas une fonctionnalité ajoutée par-dessus — elle est appliquée dans le pipeline.

• 🔗 Chaîne de traçabilité (scellement des preuves). Chaque charge utile qu'Eye envoie à un LLM est scellée : le SHA-256 des octets exacts, le nombre de jetons, le modèle + sa limite de contexte, et la provenance de chaque ligne de preuve (database:table:rowid, plus des décalages calculés pour les enregistrements MFT). Les sceaux sont en ajout seul et chaînés par hachage dans <case>/EYE_Logs/eye_payload_seal.jsonl — un seul enregistrement modifié ou supprimé brise la chaîne, de sorte que le journal prouve mathématiquement quels octets le modèle a analysés.
• 🚫 Aucune troncature silencieuse. Lorsque le contexte se resserre, Eye s'auto-répare et réalloue les budgets dans un ordre strict : Priorité 1 (Immuable) : Preuves brutes + Prompt système › Priorité 2 (Sacrificielle) : Conversation informelle › Priorité 3 (Flexible) : Contexte RAG. Si le noyau de preuves ne tient toujours pas, Eye refuse plutôt que de laisser tomber discrètement des preuves.
• 🧾 Piste d'audit de troncature. Chaque décision de contexte est journalisée dans <case>/EYE_Logs/truncation_audit.log (SUMMARIZED, TRUNCATED, PRESERVED, PINNED, UNPINNED, BUDGET_REDUCED), chacune avec un hachage. Les preuves détectées sont automatiquement épinglées au-delà d'un seuil de confiance ; vous pouvez aussi épingler des messages manuellement.
• 📑 Mandat preuves-vers-rapport. Eye doit répondre dans la discussion et consigner les preuves à l'appui dans le rapport ; l'absence d'enregistrement des preuves est signalée comme une violation de protocole.
• ⚖️ Gouvernance de la corrélation. Toute Wing ou tout mappage créé par Eye doit inclure une reason forensique et des related_evidence ; les règles créées hors d'Eye sont en lecture seule et ne peuvent pas être réécrites silencieusement.
• 🔐 Confidentialité et air-gapping. En modes hors ligne, Eye n'effectue aucun appel sortant ; les clés API cloud vivent dans les trousseaux natifs du système d'exploitation — jamais codées en dur, jamais écrites dans les journaux.

📖 Architecture complète de l'Eye : eye/README.md.

📖 Eye-Describe — Base de connaissances des artefacts au niveau octet

🔗 Explorer Eye-Describe → crow-eye.com/eye-describe

Historiquement, les enquêteurs tombaient dans le piège de faire confiance à leurs outils forensiques sans comprendre comment les artefacts sous-jacents se comportent ni comment l'outil les a analysés. Le risque aujourd'hui est de simplement remplacer « l'outil » par « l'IA ». Une IA peut analyser un enregistrement avec une précision technique parfaite et pourtant le placer dans le mauvais contexte — changeant tout le sens de la preuve.

Eye-Describe existe pour que ni l'humain ni le modèle n'aient à deviner. C'est une référence interactive, au niveau octet, des structures binaires brutes des artefacts Windows, et elle remplit deux rôles à la fois :

En ancrant la couche IA dans le comportement documenté des artefacts, Crow-Eye ne vous demande pas de faire confiance à un modèle — il contraint le modèle à respecter la criminalistique brute.

Ne remplacez pas la confiance dans l'outil par une confiance dans l'IA. Comprenez les données.

🧪 Qualité et validation

Un outillage forensique n'est utile que si sa sortie peut être défendue. Le travail de justesse de Crow-Eye est délibérément visible :

• Suites de régression. Le moteur de corrélation est verrouillé par une suite pytest couvrant l'analyse des horodatages, la normalisation d'identité, le fan-out multi-horodatages, le contrat d'écriture, la création par Eye (gouvernance GEP côté écriture) et le registre des champs standard. Le moteur UBA embarque sa propre suite, y compris une exécution de bout en bout sur une affaire réelle.
• Harness de validation. Un harness holistique exerce les 7 wings par défaut sur les deux moteurs avec une affaire Windows réelle d'environ 700 000 enregistrements.
• Historique des défauts publié. Les régressions de précision et leur impact mesuré sont documentés ouvertement dans RELEASE_NOTES.md — y compris les cas où un correctif a modifié le nombre d'enregistrements vus de plusieurs ordres de grandeur. Savoir ce qui clochait, et quand, fait partie de ce qui rend un résultat défendable.
• Comptabilité des preuves vérifiable. Chaque enregistrement aboutit soit dans une correspondance, soit dans un compartiment d'abandon nommé, et le registre des abandons par fenêtre fait de « aucune preuve laissée de côté » quelque chose que vous pouvez vérifier dans le journal plutôt que prendre pour acquis.
• Journaux infalsifiables. verify_chain() re-parcourt le journal d'audit de la Carte narrative et la chaîne de scellement des preuves pour détecter toute modification — y compris des champs lisibles par l'humain.

🔬 Plateforme de rechercheCrow-Eye est plus qu'un logiciel — c'est une plateforme de recherche ouverte qui accélère l'ensemble du domaine de la forensique Windows. Le projet se concentre sur :

• La publication de documentation détaillée sur les structures internes des artefacts.
• Le partage de la logique de corrélation et des méthodologies.
• La possibilité de revue par les pairs, de transparence et de collaboration académique.
• La contribution à la connaissance collective de la communauté forensique.

🛠️ Notes techniques

• L'analyse du registre nécessite des fichiers de ruche (hive) complets.
• Certains artefacts nécessitent un traitement spécial en raison des mécanismes de verrouillage de fichiers de Windows (voir Registre personnalisé / fichiers verrouillés).
• L'analyse des LNK et des Jump Lists est gérée par le parseur dédié de Crow-Eye.

📸 Captures d'écran

Une sélection de vues de l'interface et des analyses de Crow-Eye.

🎥 Vidéo de démonstration :

🚧 Feuille de route

Travaux planifiés et en cours (voir RELEASE_NOTES.md pour les modifications publiées) :

• 📊 Vues GUI avancées et rapports — visualisation et reporting enrichis.
• 🔄 Boîte de dialogue de recherche améliorée — filtrage avancé avec prise en charge du langage naturel.
• 🎯 Mappage sémantique amélioré — mappage complet des champs sur tous les types d'artefacts.
• 📈 Score de corrélation avancé — score de confiance affiné et explicable.
• ⚡ Corrélation parallèle — répartition par pool de processus, activée par défaut pour les charges importantes.

Vous avez une idée ou vous souhaitez ajouter un artefact ? Ouvrez une issue ou consultez Contribuer.

📚 Documentation

• TECHNICAL_DOCUMENTATION.md — architecture, composants et guide de développement.
• RELEASE_NOTES.md — nouveautés de chaque version (UBA, Narrative Map, backends cloud Eye, durcissement de la gestion des cas, …).
• Documentation du moteur de corrélation — vue d'ensemble, moteur, feathers, wings, pipelines.
• Architecture de la timeline — détails internes du module timeline.
• Architecture d'Eye et Norme GEP — l'assistant IA et son protocole de gouvernance.

🤝 Contribuer

Crow-Eye est conçu comme une plateforme de recherche ouverte, et les contributions sont bienvenues — nouveaux parseurs, règles de corrélation, documentation et recherche sur les artefacts.

• Contributions générales : CONTRIBUTING.md
• Moteur de corrélation (domaine prioritaire) : correlation_engine/CONTRIBUTING.md
• Contact : [email protected] · ou ouvrez une issue / une pull request.

🌐 Site Web et communauté

• 🌍 Site web officiel : crow-eye.com — ressources, documentation et téléchargements.
• 💬 Discord : Rejoignez le Discord Crow-Eye — aide directe, recherche sur les artefacts et annonces de versions.

📄 Licence

Crow-Eye est publié sous la GNU General Public License v3.0 (GPL-3.0). Il est libre d'être utilisé, étudié, partagé et modifié selon les termes de cette licence.

📝 Citation de Crow-Eye

Si vous utilisez Crow-Eye dans un travail académique, une recherche publiée ou un rapport de cas, veuillez le citer :```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} }

Plain text: Elsman, G. *Crow-Eye: A Windows Forensics Engine* (GPL-3.0). https://github.com/Ghassan-elsman/Crow-Eye

Pour les citations de méthodologie, le protocole Ghassan Elsman est documenté séparément dans [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md).

## 💖 Soutien

Crow-Eye est gratuit et open-source, conçu et maintenu par une seule personne. S'il vous aide dans votre travail, envisagez de sponsoriser — cela finance directement de nouveaux parseurs et des recherches : **[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**.

## Crédits

Créé et maintenu par **Ghassan Elsman**.