Crow-Eye — Motore forense per Windows

Una macchina del tempo forense per Windows.
Crow-Eye non si limita a rilevare — ricostruisce ciò che è realmente accaduto sulla timeline, dall'acquisizione fino a un verdetto riconducibile ai suoi record sorgente.

Table of Contents

• Panoramica
• ✨ Punti salienti
• 👥 A chi è rivolto Crow-Eye
• 🧭 Sottosistemi a colpo d'occhio
• 🏗️ Architettura
• 📥 Download e installazione
• 🚀 Avvio rapido
• 📂 Artefatti supportati
• 🔧 Modalità di analisi
  • 📎 Importa prove (dati di terze parti)
• 🧠 Analisi del comportamento utente (UBA)
• 🧩 Motore di correlazione
• 👁️ Eye — L'assistente AI forense
• 📖 Eye-Describe — Knowledge base degli artefatti a livello di byte
• 🧪 Qualità e validazione
• 🔬 Piattaforma di ricerca
• 🛠️ Note tecniche
• 📸 Screenshot
• 🚧 Roadmap
• 📚 Documentazione
• 🤝 Contribuire
• 🌐 Sito web e community
• 📄 Licenza
• 📝 Citare Crow-Eye
• 💖 Supporto
• Crediti

Panoramica

Crow-Eye è un motore forense open-source (GPL-3.0) per Windows che unifica acquisizione, analisi, verifica, intelligence e AI. La maggior parte degli strumenti di sicurezza chiede "questo è dannoso?" e considera innocuo tutto ciò che sembra legittimo. Crow-Eye pone una domanda diversa: "cosa è successo?" Correla tutta l'attività — sospetta o meno — e ricostruisce l'effettiva sequenza degli eventi su un sistema, così la verità di un'indagine viene ricostruita dalle prove piuttosto che ipotizzata dagli alert.

Questo approccio incentrato sulla ricostruzione è esattamente ciò che serve per cacciare minacce APT e di livello statale: gli avversari sofisticati vivono dentro strumenti legittimi (powershell.exe, PsExec, certutil) e nella sequenza delle azioni — invisibile agli strumenti che considerano innocuo tutto ciò che sembra normale. Poiché Crow-Eye non considera mai nulla innocuo e ragiona sugli artefatti di esecuzione (che sopravvivono alla manomissione dei log e all'anti-forensics), l'attacco non può nascondersi. Lo stesso motore rimane accessibile per il lavoro DFIR quotidiano e per i non esperti che vogliono semplicemente sapere cosa è successo su un computer.

• 🕰️ Ricostruisci, non limitarti a rilevare — ricostruisci la timeline di ciò che è realmente accaduto.
• 🖥️ Multipiattaforma — analisi completa live + offline su Windows; analisi offline e parsing di immagini forensi su Linux (i parser live sono solo per Windows).
• 🔒 Privato per progettazione — 0 ms di dati inviati fuori dal dispositivo; l'assistente AI Eye può funzionare completamente air-gapped.
• 🧾 Grado giudiziario — le prove sono sigillate crittograficamente e ogni passaggio è verificabile.
• 📦 Versione attuale: 0.12.6 · Motore di correlazione: 1.7.0 · Licenza: GPL-3.0.

✨ Punti salienti

• Ricostruzione invece di rilevamento. Correla ogni artefatto in un'unica storia navigabile per entità, invece di un cumulo di alert.
• Integrato end-to-end — acquisizione → correlazione → timeline → analisi comportamentale → AI → memoria del caso sigillata: un'intera pipeline che nessun singolo strumento esistente copre.
• Profondo negli artefatti, non superficiale nei log. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists e altri sopravvivono alla cancellazione dei log e ai trucchi "living-off-the-land" che accecano gli strumenti basati solo sui log.
• L'assistente AI Eye — indagine forense in linguaggio naturale con una catena di custodia verificabile e a prova di manomissione, eseguibile nel cloud, su un server privato o completamente offline.
• Analisi del comportamento utente (UBA) — trasforma gli artefatti grezzi in una storia dell'attività in linguaggio semplice, leggibile da HR ed esaminatori.
• Libero e open-source (GPL-3.0) — verificabile da chiunque, con un attivo sforzo di ricerca e documentazione.

👥 A chi è rivolto Crow-Eye

Crow-Eye viene utilizzato in flussi di lavoro molto diversi. Ognuno entra nel motore attraverso una porta diversa:

Qualsiasi collector funziona. Crow-Eye non richiede un proprio strumento di acquisizione. Indirizza l'Importazione offline verso una cartella di artefatti grezzi prodotti da Velociraptor, KAPE, un pacchetto di raccolta EDR o qualsiasi altro collector: indicizza gli artefatti supportati ed esegue su di essi i parser offline. Inoltre, l'output di Plaso, Autopsy, Volatility o qualsiasi altro strumento può essere importato come CSV, JSON o SQLite tramite Importa prove e correlato insieme agli artefatti nativi.

🧭 Sottosistemi a colpo d'occhio

Crow-Eye è costruito come un loop integrato: ogni fase alimenta la successiva, dal disco grezzo a un verdetto difendibile.

🏗️ Architettura

Crow-Eye è una pipeline integrata, non un insieme di parser. Le prove fluiscono in una sola direzione e ogni fase mantiene il collegamento al record sorgente.```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

*Sorgente di prove → Ingestione → Database del caso → Analisi → Strato IA → Report*


**Come leggerlo:**

| Fase | Cosa conta |
|---|---|
| ① → ② | **Quattro porte indipendenti verso un caso.** Non hai mai bisogno del collector di Crow-Eye: una cartella da Velociraptor, KAPE o un pacchetto EDR passa attraverso l'Offline Importer, e CSV/JSON/SQLite di terze parti passa attraverso Import Evidence. |
| ② → ③ | Tutto converge in un unico luogo: **i database del caso**. Gli artefatti analizzati finiscono in `Target_Artifacts/`; le evidenze di terze parti importate finiscono in `Imported_Evidence/` e vengono rilevate automaticamente. |
| ③ → ④ | **I tre percorsi di analisi sono indipendenti tra loro.** La Timeline e la UBA leggono direttamente i database del caso — nessuna delle due richiede un'esecuzione di correlazione. Il Correlation Engine è un livello *aggiuntivo*, non un prerequisito. |
| ③ → ④ | **Il Dynamic Linking si affianca alla Timeline e alla UBA** — un quarto lettore indipendente dei database del caso (non ha nulla a che fare con la visualizzazione della Timeline). Raccoglie i mapping delle identità (SID → username, MAC → rete, hash/GUID → app) in un `Crow_Intelligence.db` per caso, quindi sovrappone quel contesto **in linea nelle tabelle dei dati degli artefatti** tramite `ATTACH` + `LEFT JOIN` non distruttivi. Cambia il modo in cui i record *si leggono*, mai l'evidenza. |
| ④ → ⑤ | L'Eye interroga direttamente i database del caso e può recuperare i risultati della correlazione **on demand**. Non tocca mai l'evidenza stessa — emette chiamate ai tool che Crow-Eye esegue e registra. |
| ⑤ → Report | Il **Living Report è creato solo dall'Eye**, tramite i suoi strumenti `report_*`. La Timeline e la UBA sono superfici di analisi — non scrivono nel report. I risultati a livello di caso possono essere comunque esportati separatamente tramite [Search & Export](#-search--export). |
| ⑤ ↔ | La **Narrative Map è bidirezionale**: l'Eye ci scrive, tu ci scrivi, e i suoi contenuti vengono iniettati nel prompt dell'Eye a ogni turno. È la memoria, e puoi comandarla. |
| ⑤ ⟳ | La **pagina Compliance verifica l'Eye.** Ogni chiamata ai tool che l'Eye effettua è ancorata alla catena di hash **EvidenceSeal**; la pagina mostra lo stato **GEP** in tempo reale per ogni regola (10 principi), verificato da quella catena e da `EYE_Logs/`, esportabile come `audit_trail.json`. |

**Fasi indipendenti.** La Timeline e la UBA leggono **direttamente** i database degli artefatti del caso — nessuna delle due richiede un'esecuzione di correlazione, e la Timeline non dipende dal Correlation Engine (applica un proprio leggero raggruppamento temporale). La correlazione è un livello di analisi aggiuntivo i cui risultati l'Eye può interrogare.

**Sola lettura per progettazione.** Il parsing scrive nel database del caso; ogni fase successiva (UBA, la Timeline, visualizzatori di correlazione, l'Eye) apre quei database **in sola lettura**. L'evidenza originale non viene mai modificata — [Dynamic Linking](#-analysis-modes) legge i database del caso per costruire un `Crow_Intelligence.db` per caso dei mapping delle identità e arricchisce le tabelle dei dati degli artefatti in linea tramite query `ATTACH` + `LEFT JOIN` non distruttive, invece di riscrivere le righe.

**Regolato per progettazione.** Ogni azione che l'Eye compie è ancorata alla catena di hash **EvidenceSeal** a prova di manomissione, e la pagina **Compliance** verifica continuamente l'Eye rispetto al [Ghassan Elsman Protocol (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) — stato in tempo reale per ogni regola, esportabile in `EYE_Logs/audit_trail.json`.

## 📥 Download e Installazione

> **Consigliato:** ottieni la build Windows confezionata (**installer MSI / EXE**) dal sito ufficiale — nessuna configurazione Python, funziona immediatamente.

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

La **build MSI/EXE installata è il modo consigliato per eseguire Crow-Eye**, ed è la nostra **massima priorità per gli aggiornamenti**:

- 🛡️ **Correzioni più rapide.** Quando viene trovato un problema o viene segnalato un bug, pubblichiamo un EXE aggiornato **il prima possibile** — la build confezionata è dove le correzioni arrivano prima.
- 🔄 **Aggiornamento automatico integrato.** Nell'app installata, apri **Impostazioni → Aggiornamenti** per **cercare aggiornamenti e installarli automaticamente** — nessuna reinstallazione manuale.
- 📦 **Zero configurazione.** Nessuna installazione di Python, Node o dipendenze richiesta.

> Preferisci eseguire dal sorgente? Vedi **[Avvio rapido](#-quick-start)** qui sotto. La build da sorgente è pensata per i contributori e **non include l'auto-updater** — usa il MSI/EXE per gli aggiornamenti automatici.

## 🚀 Avvio rapido

### Opzione A — Build installata (consigliata)
Scarica il **MSI/EXE** da [crow-eye.com/download](https://crow-eye.com/download), installalo e avvia **Crow-Eye** come Amministratore. Crea un caso e inizia l'analisi.

### Opzione B — Esecuzione dal sorgente (sviluppatori)

> Per contributori e utenti avanzati. Questo percorso **non include l'auto-updater** — usa il MSI/EXE per gli aggiornamenti automatici.

**Requisiti** (installati automaticamente al primo avvio):
- Python 3.12.4
- **Node.js & npm** — richiesti per la **Timeline Visualization**
- Pacchetti principali: PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**Hardware consigliato**

| | Minimo | Consigliato per casi di grandi dimensioni |
|---|---|---|
| **RAM** | 8 GB | 16 GB+ (insiemi MFT/USN di milioni di record) |
| **Disco** | 5 GB liberi | Spazio libero ≥ 2× la dimensione dell'evidenza da analizzare |
| **CPU** | 4 core | 8+ core |
| **SO** | Windows 10/11 (completo) · Linux (analisi offline e delle immagini) | — |

> La correlazione scorre in memoria costante per set di dati molto grandi, quindi la RAM raramente è il limite rigido — di solito lo sono la velocità del disco e lo spazio libero.

**Avvio** (esegui come Amministratore così Crow-Eye può accedere agli artefatti di sistema):```bash
python "Crow Eye.py"

Si apre l'interfaccia principale, si crea un caso e tutto l'output dell'analisi viene organizzato nella directory del caso per revisioni e report successivi.

🖥️ Nota multipiattaforma: su Linux, i parser live vengono disabilitati automaticamente e Crow-Eye funziona in modalità offline / immagine forense. L'acquisizione live completa è disponibile solo su Windows.

📂 Artefatti supportati

Crow-Eye analizza un'ampia gamma di artefatti Windows relativi a esecuzione, file system e attività dell'utente, sia da un sistema live sia da fonti offline (cartelle raccolte o immagini forensi).

Jump Lists e LNK vengono analizzati dal parser LNK / Jump List dedicato di Crow-Eye — non da un modulo di terze parti.

Registro personalizzato / file bloccati: Windows blocca gli hive del registro live (NTUSER.DAT, SOFTWARE, SYSTEM) durante il funzionamento. Per un'analisi personalizzata di un sistema live, avviare da supporti esterni (WinPE/Live CD), utilizzare strumenti di acquisizione forense o analizzare un'immagine disco.

Dettagli per artefatto

• Jump Lists e LNK — analizzati automaticamente dalle posizioni standard di sistema dal parser dedicato di Crow-Eye (accesso ai file, percorsi di destinazione, timestamp e metadati).
• Registro — analizza automaticamente gli hive di sistema. Per un'analisi personalizzata del registro, copiare i file degli hive in CrowEye/Artifacts Collectors/Target Artifacts (o nella cartella registry/ del caso):
  • NTUSER.DAT da C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE da C:\Windows\System32\config\SOFTWARE
  • SYSTEM da C:\Windows\System32\config\SYSTEM
  • Windows blocca questi file durante il funzionamento — per un sistema live, avviare da supporti esterni (WinPE/Live CD), utilizzare strumenti di acquisizione forense o analizzare un'immagine disco.
• Prefetch — analizza C:\Windows\Prefetch, estraendo cronologia di esecuzione e metadati forensi (inclusi i timestamp per esecuzione).
• Log di evento — analisi automatica dei log Sistema/Sicurezza/Applicazioni in un database per un'analisi completa.
• — rivela la cronologia di accesso alle cartelle e i modelli di navigazione dell'utente.

🔧 Modalità di analisi

🦅 Acquisizione Crow-Claw

Crow-Claw è il motore di acquisizione specializzato di Crow-Eye per raccogliere e preservare gli artefatti da sistemi live o immagini montate.

• Raccolta selettiva — scegliere categorie di artefatti specifiche (Registro, Log di evento, File System) o raccogliere tutto.
• Scansione profonda — attraversa directory e sottodirectory per trovare tracce forensi.
• Preservazione sicura — gli artefatti vengono collocati in una directory di caso strutturata che mantiene l'integrità forense.

🔍 Analisi offline (Offline Importer)

Analizzare gli artefatti raccolti da qualsiasi fonte senza una connessione live al target — tre operazioni chiare:

• SCAN (scoperta) — attraversa la sorgente e indicizza ogni artefatto supportato in base a nome file e pattern di estensione (veloce, in sola lettura; in questa fase non vengono letti i contenuti dei file e non viene eseguito alcun controllo dei magic byte). Non viene spostato nulla.
• COLLECT (acquisizione) — copia fisicamente i file identificati nella cartella live_acquisition del caso, organizzati per tipo.
• PARSE (granulare) — rivede gli elementi identificati per tipo (AMCACHE, EVTX, PREFETCH, …) e analizza i file selezionati (o tutti) nel database forense.

L'analisi è gestita dai parser offline dedicati di Crow-Eye — la stessa logica degli artefatti della modalità live, applicata ai file raccolti: Prefetch, Registro, MFT, USN (più il correlatore MFT/USN), AmCache, ShimCache, SRUM, Log di evento, LNK/JumpLists e Cestino.

📎 Importazione prove (dati di terze parti)

Oltre agli artefatti grezzi, Crow-Eye può portare l'output forense di terze parti direttamente in un caso — Plaso, Autopsy, Volatility o qualsiasi esportazione personalizzata — e renderlo utilizzabile dall'Eye e dalla Timeline senza richiedere prima un'esecuzione della correlazione.

Poiché il gestore del database del caso rileva automaticamente qualsiasi .db sotto l'albero del caso, le prove importate diventano immediatamente disponibili a:

• The Eye — interrogabile in linguaggio naturale insieme agli artefatti nativi (il manifest dello schema viene aggiornato all'importazione).
• The Interactive Timeline — fornita come tipo di artefatto imported, con filtro per finestra temporale e limiti temporali funzionanti.
• The Correlation Engine — utilizzabile come Feather per la correlazione tra strumenti con gli artefatti nativi.

L'importatore utilizza solo la libreria standard (sqlite3 / csv / json) e viene eseguito su un worker in background, quindi le importazioni di grandi dimensioni non bloccano l'interfaccia.

⚡ Analisi live

Analizza gli artefatti direttamente dal sistema Windows in esecuzione, estraendoli automaticamente dalle posizioni standard per un'analisi forense in tempo reale.

🗂️ Gestione dei casi

Ogni indagine è un caso: una directory autonoma che organizza i database degli artefatti e l'output dell'analisi. Crow-Eye tiene traccia dei casi recenti (con preferiti, tag e stato), valida un caso all'apertura, scrive la configurazione in modo atomico (a prova di crash) e supporta l'importazione/esportazione della configurazione dei casi e modelli con mapping semantici già pronti.

🕰️ Visualizzazione interattiva della timeline

Correla gli eventi tra gli artefatti su una griglia temporale unificata, con viste Heat Map, Settimana e Giorno — una narrazione intrecciata per identità e verificabile in tribunale, piuttosto che una super-timeline piatta.

La Timeline legge direttamente i database degli artefatti analizzati del caso ed è indipendente dal Correlation Engine — non è necessario creare feather, scrivere wing o eseguire una pipeline per usarla. Applica un proprio raggruppamento temporale leggero (correlazione per timestamp esatto e per finestra temporale, raggruppamento per applicazione, percorso o utente) per mettere in relazione gli eventi sulla griglia. Le prove importate tramite Importazione prove appaiono anche nella timeline come tipo di artefatto imported, con filtro per finestra temporale e limiti temporali funzionanti.

🔎 Ricerca ed esportazione

Ricerca full-text nel database del caso, oltre all'esportazione in CSV (fogli di calcolo), JSON (integrazione con altri strumenti) e report HTML dettagliati (dossier completi che consolidano ogni artefatto collegato a un termine di ricerca).

🔗 Linking dinamico

Traduce gli identificatori tecnici grezzi — SID, indirizzi MAC, hash — in un contesto leggibile dall'uomo al volo. Il Linking dinamico arricchisce la vista utilizzando query SQL ATTACH non distruttive, quindi la prova originale non viene mai modificata, e può acquisire feed di minaccia IOC in blocco per segnalare inline gli indicatori noti come dannosi.

🧠 User Behavior Analytics (UBA)

Trasforma gli artefatti grezzi in una storia di attività in linguaggio semplice — un resoconto leggibile da manager/HR di ciò che un utente e le sue applicazioni hanno effettivamente fatto, con ogni affermazione rintracciabile fino alla prova di origine esatta.

User Behavior Analytics (UBA) legge i database degli artefatti analizzati nella cartella Target_Artifacts/ del caso (rigorosamente in sola lettura) e li riprocessa attraverso un insieme di regole dichiarative per produrre una chiara Activity Story cronologica. Apri l'UBA dal pulsante "User Behavior" della barra degli strumenti o con Ctrl+Shift+B (deve essere caricato un caso).

• 🧩 40 rilevamenti comportamentali dichiarativi (uba/config/behavior_rules.json) — regolabili senza codice — ciascuno classificato per gravità: routine · notevole · sospetto · critico.
• 🕵️ Rileva i comportamenti che contano: accesso / disconnessione / sblocco, avvio · esecuzione · installazione di programmi, apertura / eliminazione / copia dedotta di file, connessione di dispositivi USB, accesso alle condivisioni di rete, persistenza e avvio automatico, uso di credenziali esplicite (runas), modifiche ad account e gruppi, modifiche ai servizi, manomissione dell'orologio di sistema (sospetto) e cancellazione dei log di evento (critico).
• 🗺️ Tre viste — un feed Activity Story, una mappa di calore Activity Map (giorno × ora) e un report di trasparenza "What we can see" che etichetta ogni rilevamento come Working / Limited / No data / By design per questo caso.
• 🔗 Ogni attività è supportata da prove. Fai clic su qualsiasi elemento per aprire il record di supporto esatto (database : table : rowid) — nulla viene affermato senza una fonte.
• 👤 Attribuzione onesta. Gli attori vengono risolti come Utente / Applicazione / Sistema (o lasciati vuoti) — UBA non indovina mai chi ha fatto cosa.

Copertura dei rilevamenti

I 40 rilevamenti coprono quattro classi di gravità e l'intera ampiezza dell'insieme di artefatti analizzati:

Filtri: ricerca a testo libero · utente/attore (inclusi "Unattributed" e un'opzione per la sessione con accesso effettuato) · classe di comportamento (utente / applicazione / sistema) · gravità · applicazione (multi-selezione ricercabile su oltre 200 programmi) · intervallo data/ora con preset rapidi (tutto il periodo / primo giorno / ultimo giorno / ultima ora di attività).

Fonti dati: Log di evento Sicurezza, Sistema e Applicazioni · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · Cestino · SRUM (applicazione, rete, connettività) · hive del registro.

Garanzie forensi

• Sola lettura. I database di origine vengono aperti in sola lettura; l'analisi non tocca mai la prova.
• Provenienza completa. Ogni evento porta database → table → rowid e apre le righe di origine reali su richiesta.
• L'attribuzione non indovina mai. Un evento viene attribuito a un Utente, a un'Applicazione, al Sistema — o lasciato vuoto. Le sessioni di accesso interattive vengono usate solo come etichette di contesto ("durante la sessione di <user>"), mai per attribuire un'azione.
• Formulazione onesta. La scelta delle parole distingue l'interazione deliberata (UserAssist, SRUM in primo piano) dagli artefatti che un'applicazione può generare anche da sola (ShellBags, LNK, JumpLists), con avvertenze esplicite mostrate sulla scheda.
• L'assenza viene dichiarata, non implicata. Il report What we can see etichetta ogni rilevamento per questo specifico caso, così i dati mancanti non vengono mai interpretati silenziosamente come "non è successo nulla".

UBA è correlazione e classificazione comportamentale basata su regole, non punteggio di anomalie statistico/ML — ogni risultato è mappato a una regola esplicita e verificabile. Vedere RELEASE_NOTES.md per il catalogo completo dei rilevamenti.

🧩 Correlation Engine

Correlation Engine v1.7.0 — il nucleo di ricostruzione. Vedere RELEASE_NOTES.md per la cronologia delle release.

Il Crow-Eye Correlation Engine è un sistema di correlazione forense di livello produttivo. Acquisisce artefatti Windows da qualsiasi fonte, li normalizza e porta in superficie le relazioni temporali e di identità che trasformano i record isolati in una narrazione coerente di ciò che è successo su un sistema, quando e chi era coinvolto. Funziona subito con regole di correlazione integrate (Wings) per le domande di indagine più comuni, consente agli analisti di creare regole personalizzate senza toccare il codice e rimanda il significato a regole definibili dall'utente e all'investigatore — mai a un punteggio a scatola chiusa.

🎥 Guida utente

Importazione dati universale: Il Correlation Engine può prendere l'output di qualsiasi strumento forense in formato CSV, JSON o SQLite e convertirlo in un database Feather. Questo significa che puoi correlare i dati di strumenti di terze parti (Plaso, Autopsy, Volatility, ecc.) con gli artefatti nativi di Crow-Eye, creando un'analisi di correlazione unificata su tutte le tue fonti di dati forensi.

🎯 Precisione e completezza delle prove

Una passata di precisione mirata, validata end-to-end su un caso Windows reale di ~700K record, costruita sopra i precedenti lavori sull'affidabilità. Ogni correzione di seguito è vincolata dalla suite di regressione pytest e verificata da un harness di validazione olistico che esercita tutte le 7 wing predefinite su entrambi i motori.

Il motore di identità cattura tutte le prove

• Corretto: il motore di identità iterava solo la PRIMA riga di ogni feather quando era attivo un filtro temporale (un confronto tra datetime con e senza fuso orario sollevava un TypeError e interrompeva il ciclo per riga). I record osservati sono passati da 3.558 → 745.615 nel caso di validazione.
• Corretto: i record dei log appiattivano ogni evento sul PROVIDER dell'evento come identità (tutti i 33.855 record di SecurityLogs condividevano un'unica identità). Il mapping per artefatto ora dà priorità alle entità reali per riga (User, ComputerName, NewProcessName, TargetUserName) prima dei metadati di canale/provider.
• Corretto: il mapping dei campi specifico per artefatto non scattava mai perché i parser non stampano una colonna artifact su ogni riga. Il motore ora ripiega su feather_metadata.artifact_type, così SecurityLogs / SystemLogs / ApplicationLogs usano la loro priorità di identità specifica per artefatto.
• Corretto: le stringhe segnaposto diventavano false identità ('N/A', 'Unknown', '-', i GUID nulli raggruppavano record non correlati). Il validatore ora rifiuta oltre 30 varianti di segnaposto.

Basta con "tutto è Low — qualcosa non va"

• Corretto: le corrispondenze con feather singola venivano etichettate High. Le corrispondenze con feather_count == 1 ora ricevono confidence_category="Low - single feather", quindi la vista High si concentra sulla correlazione cross-feather reale.
• Corretto: una chiave composita basata sul percorso spezzava la stessa identità tra le feather (ogni feather memorizza i percorsi in modo diverso, quindi chrome aveva 10+ chiavi e non correlava mai). La chiave ora è basata solo sul nome — la correlazione cross-feather funziona di nuovo.

Rilevamento dell'impersonificazione tramite classificazione dei percorsi — dopo la formazione di una corrispondenza, il motore classifica il percorso di ogni record come AFFIDABILE (Program Files, System32, WinSxS, le forme BAM/SRUM /device/harddiskvolumeN/..., …) o SOSPETTO (Temp, Downloads, Public, AppData\Local\Temp, Cestino, root rimovibili, condivisioni di rete). Una corrispondenza che attraversa entrambe le classificazioni solleva impersonation_alert (tasso ≈0.05%, ciascuna un candidato reale).

Contabilità onesta delle prove — un registro degli scarti per finestra con bucket denominati (no_identity_field, normalize_failure, below_threshold_skipped, …) più un riepilogo per pipeline (record osservati, high/low emessi, nessuna identità, bucket di scarto, join di feather senza tempo). Ogni record finisce in una corrispondenza o in un bucket di scarto denominato — "nessuna prova rimasta" è verificabile dal log. low_confidence_review_mode è ON per impostazione predefinita, quindi i gruppi sotto soglia diventano corrispondenze a bassa confidenza invece di sparire silenziosamente.

Arricchimento dell'identità per feather senza tempo — le feather senza timestamp per riga (AutoStartPrograms, MUICache, SystemServices, TypedPaths) non ricevono più un falso tempo di generazione stampato su ogni riga; invece, dopo la formazione delle corrispondenze temporizzate, il motore unisce per identità i record corrispondenti di ogni feather senza tempo come prova supplementare.

Registro di identità consolidato — config/standard_fields/identities.json è l'unica fonte di verità per ogni colonna che i motori + Eye devono consultare: 98 categorie, 1.146 sinonimi di colonna (app/processo, file, hash, utente, host/dispositivo, rete, registro, servizio/attività, evento, email, browser, cloud, internals di Windows, certificato, container, oggetti del sistema operativo). Aggiungere un nuovo sinonimo di colonna è una modifica JSON, non una modifica al codice.

Correzioni dei falsi positivi nel mapping semantico — il gating multi-indicatore ora è effettivamente applicato (data-exfiltration-pattern richiede ≥2 indicatori); le regole AND impossibili (4625 AND 4624) riscritte come OR; le regole per wiper/strumenti remoti usano regex reali invece di attivarsi su ogni voce Prefetch; le regole per le attività di base declassate da high/critical a info/low (il punteggio pesato della wing fa salire le minacce reali).

✅ Stato di produzione

Il Correlation Engine è pronto per la produzione e utilizzato attivamente nelle indagini (Correlation Engine v1.7.0):- ✅ Motore Time-Window Scanning — pronto per la produzione, consigliato per l'analisi basata sul tempo (O(N log N))

• ✅ Motore Identity-Based — pronto per la produzione, consigliato per il tracciamento delle identità (O(N log N))
• ✅ Feather Builder / FeatherWriter — importa CSV/JSON/SQLite da qualsiasi strumento; batch transazionali + metadati di schema
• ✅ Sistema Wings e Orchestrazione della Pipeline — crea/gestisce regole di correlazione e automatizza i flussi di lavoro
• ✅ Raggruppamento delle Identità — unificato tra motore, visualizzatori e fase semantica
• ✅ Registro dei Campi Standard — fonte di verità centralizzata per i sinonimi dei campi
• ✅ Fan-Out Multi-Timestamp — ogni timestamp delle liste JSON viene correlato
• 🔄 Correlazione Parallela — fondamenta pronte; profilazione e dispatch del process-pool come prossimo passo
• 🔄 Mapping Semantico e Scoring di Correlazione — miglioramenti in corso

Caratteristiche Principali

• 🔄 Architettura a Doppio Motore: Scegli tra le strategie di correlazione Time-Window Scanning (O(N log N)) e Identity-Based (O(N log N)).
• 📊 Supporto Multi-Artefatto: Correla Prefetch, ShimCache, AmCache, Event Logs, file LNK, Jumplists, MFT, USN, SRUM, Registry, RecycleBin e altro.
• 🔌 Import Universale: Importa l'output CSV/JSON/SQLite da qualsiasi strumento forense e convertilo in database Feather.
• 🎯 Raggruppamento Intelligente delle Identità: Varianti come Chrome.exe/chrome.dll/Chrome.EXE collassano in un unico bucket; versioni e qualificatori architetturali restano distinti.
• 🕒 Timestamp Tolleranti: FILETIME, ISO 8601, epoch Unix (s/ms/μs), YYYYMMDD, notazione US con barre e stringhe annotate vengono analizzati correttamente al primo tentativo.
• 📈 Fan-Out Multi-Timestamp: Le liste di timestamp JSON (Prefetch run_times) vengono espanse, così ogni esecuzione ottiene il proprio evento di correlazione.
• 🧰 Un'unica Fonte di Verità: Sinonimi dei campi in config/standard_fields/*.json; metadati per tabella in correlation_engine/config/feather_schemas.json — estendibile modificando il JSON, non il codice.
• ⚡ Streaming + Thread-Safe: query_time_range_iter con memoria O(1); cache feather protette da lock; pronto per la correlazione parallela.

Architettura di Sistema

Il Correlation Engine è composto da quattro componenti principali:

1. 🗄️ Feathers (Normalizzazione dei Dati)

Scopo: Trasformare gli artefatti forensi grezzi in un formato standardizzato e interrogabile.

• Database SQLite contenenti dati forensi normalizzati degli artefatti — un feather per tipo di artefatto (Prefetch, ShimCache, Event Logs, …) con uno schema standardizzato e metadati per un'interrogazione efficiente.
• Un formato universale che accetta dati da qualsiasi strumento forense.``` 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

**Formati di importazione supportati:** CSV (qualsiasi file con intestazioni), JSON (piatto o annidato) e SQLite (importazione diretta). Mappatura automatica delle colonne, rilevamento del tipo di dati, normalizzazione dei timestamp in ISO, validazione e indici ottimizzati.```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Wings (Regole di correlazione)

Scopo: Definire quali artefatti correlare e come.

• Regole JSON/YAML che specificano una finestra temporale, corrispondenze minime, priorità dell'ancora e le feathers (con pesi) da correlare — riutilizzabili tra i casi. Ogni Wing è creabile e sigillato (registra chi lo ha creato, perché e le prove che lo hanno motivato).```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. ⚙️ Motori (Strategie di correlazione)

**Scopo**: eseguire la logica di correlazione per trovare relazioni tra gli artefatti. I collegamenti strutturali vengono **prima**; un punteggio ponderato per livelli viene sovrapposto come *interpretazione/classificazione*, non come base per una corrispondenza.

**Motore di scansione a finestra temporale** — ideale per analisi basate sul tempo e correlazione temporale sistematica. Scansiona il tempo a intervalli fissi, raccoglie record da tutte le feathers per finestra, applica il matching di campi semantici + punteggio ponderato e previene i duplicati tramite il tracciamento MatchSet. **O(N log N)** (query su timestamp indicizzati); elaborazione in batch (~2.567 finestre/secondo).

**Motore di correlazione basato su identità** — ideale per grandi set di dati (>1.000 record) e tracciamento delle identità. Estrae e normalizza le identità, raggruppa i record per identità, costruisce ancoraggi temporali all'interno di ciascun cluster, classifica le prove come primarie/secondarie/supportive e gestisce in streaming set molto grandi (>5.000 ancore) a memoria costante. **O(N log N)**; 40+ modelli di campi di identità per tipo.

**Selezione del motore:** utilizzare il motore a finestra temporale per analisi basate sul tempo e il motore basato su identità per il tracciamento delle identità — entrambi sono pronti per la produzione e ottimizzati per grandi set di dati con query indicizzate.

#### 4. 🔄 Pipeline (Orchestrazione dei flussi di lavoro)

**Scopo**: automatizzare flussi di lavoro analitici completi, dalla creazione delle feathers alla generazione dei risultati. Una pipeline legge la sua configurazione (tipo di motore, wings, feathers), istanzia il motore corretto tramite EngineSelector, esegue ogni wing, aggrega le corrispondenze, salva i risultati (DB + JSON) e li visualizza nella GUI con filtri e visualizzazioni.```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"
  }
}

Come Funziona Tutto Insieme```

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

### Esempio di caso d'uso: trovare la prova di esecuzione

**Scenario**: dimostrare che `malware.exe` è stato eseguito su un sistema.```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

I didn't receive any input content to translate. The message ends with "INPUT:" but no Markdown text follows. Please provide the chunk content so I can translate it.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

Il contenuto da tradurre non è presente nel messaggio. Il campo "INPUT:" è vuoto. Non è possibile effettuare la traduzione senza il testo sorgente.```
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

Performance Benchmarks

Per Iniziare con il Motore di Correlazione

1. Avvio: python -m correlation_engine.main
2. Crea Feathers: importa i tuoi artefatti forensi (Prefetch, ShimCache, …).
3. Crea Wings: definisci le regole di correlazione per la tua indagine.
4. Crea una Pipeline: configura quali Wings e Feathers utilizzare.
5. Esegui: esegui la pipeline e visualizza i risultati correlati.
6. Analizza: usa il Visualizzatore dei Risultati per esplorare le relazioni temporali.

📚 Documentazione del Motore di Correlazione

• Panoramica del Motore di Correlazione — panoramica del sistema con diagrammi architetturali
• Documentazione del Motore — architettura a doppio motore, selezione del motore, ottimizzazione delle prestazioni
• Architettura — integrazione dei componenti e flusso dei dati
• Documentazione sui Feather — il sistema di normalizzazione dei dati
• Documentazione sui Wings — regole di correlazione
• Documentazione sulla Pipeline — orchestrazione dei flussi di lavoro
• Aggiungere un Artefatto — il flusso di lavoro per collegare un nuovo parser al motore
• Registro dei Campi Standard — sinonimi canonici dei nomi di colonna caricati da entrambi i motori e dall'Eye
• Guida al Contributo — come contribuire al motore
• Collegamenti rapidi: Selezione del Motore · Risoluzione dei Problemi · Ottimizzazione delle Prestazioni

👁️ Eye — L'Assistente IA Forense

Un assistente potente, non un sostituto. Eye automatizza e verifica le ipotesi di un investigatore — non prende mai la decisione al posto tuo.

Eye è l'assistente IA forense integrato di Crow-Eye: un investigatore forense esperto supportato da una vera base di conoscenza degli artefatti Windows. Offre un'interfaccia in linguaggio naturale per interrogare, correlare e documentare tutto in un caso — Prefetch, MFT, Registry, Event Logs, AmCache, ShimCache, SRUM e altro — mantenendo al contempo una traccia verificabile e a prova di manomissione di ciò che ha fatto esattamente. Eye può essere eseguito interamente sul tuo hardware (incluso completamente air-gapped), in linea con la posizione sulla privacy di Crow-Eye "0 ms di dati inviati fuori dal dispositivo". Architettura completa: eye/README.md.

Eye trasforma le domande conversazionali ("mostrami cosa è stato eseguito da C:\Temp dopo le 22:00") in vero lavoro forense: pianifica un approccio, recupera la conoscenza rilevante sugli artefatti, esegue query SQL e ricerche cross-artefatto sui database del caso e sintetizza una risposta validata. Ogni risposta viene prodotta in due punti contemporaneamente — una risposta in chat per te e un blocco strutturato scritto in uno Spazio di lavoro del Report Vivente, così il dossier si costruisce da solo mentre l'indagine procede.

Il Protocollo Ghassan Elsman (GEP)

Tutto ciò che Eye fa è ancorato al Protocollo Ghassan Elsman (GEP) — uno standard neutrale rispetto al fornitore e indipendente dallo strumento su come qualsiasi IA dovrebbe essere utilizzata nell'informatica forense. Si tratta di 10 principi che un sistema conforme deve rispettare affinché i risultati assistiti dall'IA rimangano veritieri, tracciabili rispetto ai record di origine e supportati da una catena verificabile e a prova di manomissione, con l'investigatore umano al controllo:

L'Eye di Crow-Eye è l'implementazione di riferimento del GEP; i comportamenti in-product che lo sostengono sono le Regole Operative. 📜 Leggi lo standard: eye/docs/GEP_standard.md.

Modalità di Distribuzione

Eye si adatta al tuo modello di minaccia attraverso tre modalità di distribuzione:

In modalità CLI-agent, Crow-Eye guida un agente terminale/da riga di comando IA esistente come modello — invece di un'API cloud o di un server offline locale — così puoi indagare con l'agente che già usi.

Il ciclo dell'indagine:

1. Apri o crea un caso — Eye si limita ai database degli artefatti e alla cronologia di quel caso.
2. Fai una domanda in linguaggio naturale oppure avvia un triage completo in un clic.
3. Eye esegue la sua pipeline — rileva l'intento → recupera la conoscenza → esegue gli strumenti → sintetizza.
4. Ottieni un output doppio — una risposta diretta in chat e un nuovo blocco nel Report Vivente.
5. Approva le azioni bloccate — le esportazioni e le altre fasi critiche attendono la tua autorizzazione.

Puoi cambiare modello in fase di esecuzione con lo strumento switch_model. Il cambio è limitato allo stesso backend, quindi le prove non vengono mai inviate silenziosamente a un fornitore diverso da quello scelto.

Tracciare il Processo di Pensiero dell'LLM

Eye è progettato in modo che tu possa vedere — e successivamente provare — come sia arrivato a una conclusione. Mentre Eye lavora, trasmette aggiornamenti strutturati ThinkingStep all'interfaccia in tempo reale; ognuno contiene un step_id, un type, una label leggibile dall'uomo, uno status (active → done, o error) e tool/params/detail opzionali.

Una query tipica si svolge come thinking → rag → thinking → tool_call → synthesis, e ogni caso conserva artefatti di traccia su disco che puoi ispezionare in seguito:

Esecuzione degli Strumenti

Eye è guidato dagli strumenti: il modello non tocca mai direttamente le prove. Emette chiamate agli strumenti e Eye le esegue sui database del caso e restituisce i risultati — così ogni azione è esplicita, registrata e riproducibile. Gli strumenti sono definiti in configs/llm_config.json e distribuiti tramite eye/services/context_manager.py.

Strumenti investigativi — leggono e analizzano le prove:

Strumenti di reporting costruiscono lo Spazio di lavoro del Report Vivente: 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 ed export_report (l'esportazione richiede l'approvazione umana).

Strumenti di authoring (governati — vedi Costruire Wings di Correlazione e Mappature Semantiche): correlation_create_wing, correlation_edit_wing, correlation_create_semantic_mapping, correlation_edit_semantic_mapping. Le chiamate agli strumenti vengono tradotte in ciò che il backend attivo si aspetta — native function-calling per API cloud e server locali, o un wrapper XML <tool_call> per gli agenti CLI.

Costruire Wings di Correlazione e Mappature Semantiche

Eye non si limita a interrogare il Motore di Correlazione — può aiutare a estenderlo. Quando Eye individua un pattern cross-artefatto ricorrente, può proporre nuovi Wings (regole di correlazione) e Semantic Mappings (traduzioni tecnico-umane). Questa è authoring governato: Eye propone, l'analista esamina l'artefatto salvato e ogni modifica è giustificata e supportata da prove.

Un Wing collega i feather all'interno di una finestra temporale e di una soglia minima di corrispondenza per dimostrare un'affermazione:

Un Semantic Mapping traduce un valore tecnico grezzo in un significato leggibile (es. EventID 4624 → "Accesso riuscito"). È disponibile in due varianti: un semplice mapping (valore singolo/regex → valore semantico) o una rule multi-condizione (condizioni unite da AND/OR). Entrambi supportano category, severity, confidence e scope, ed entrambi richiedono reason + related_evidence.

Governance — regole lato scrittura che sostengono il GEP:

• Reason-Required (sostiene GEP-9 + GEP-2): ogni creazione e modifica deve includere un reason forense.
• Evidence-Link (sostiene GEP-2): ogni creazione deve citare almeno un riferimento database:table:rowid.
• Eye-Stamped / sola lettura per gli altri (sostiene GEP-7 + GEP-9): Eye appone la propria paternità + reason + cronologia modifiche e può modificare solo ciò che Eye ha creato — le regole integrate e create dall'uomo rimangono di sola lettura.

Contesto Auto-Riparante

Le indagini lunghe possono superare la finestra di contesto di un modello — soprattutto i modelli offline più piccoli. Invece di bloccarsi o eliminare silenziosamente le prove, Eye compatte automaticamente il proprio contesto prima di ogni chiamata al modello (all'interno del suo percorso di generazione protetto, completamente verificato).

Prima di ogni chiamata, Eye misura l'intero payload e riserva spazio per la risposta (10% della finestra, minimo 512 token, mai più della metà). Se ancora non ci sta, si ripara in due passaggi ordinati, senza mai toccare i messaggi protetti (fissati, prove rilevate automaticamente o risultato di uno strumento):

1. Passaggio di riepilogo (una volta) — la cronologia non protetta si compatta in un unico riepilogo, registrato come SUMMARIZED.
2. Passaggio di eliminazione — il messaggio non protetto più vecchio viene rimosso uno alla volta finché non ci sta, registrato come TRUNCATED.

Se il nucleo di prove irriducibile (messaggi fissati + risultati degli strumenti + la domanda corrente) ancora va in overflow, Eye rifiuta di procedere piuttosto che troncare le prove (REFUSED_OVERFLOW) e ti chiede di restringere la query o di usare analyze_large_dataset. Qualunque cosa vada infine al modello è l'esatto payload che viene sigillato per la catena di custodia.

🗺️ Narrative Map — La memoria persistente del caso di Eye

L'Eye è senza stato tra un turno e l'altro — quindi la Narrative Map è il luogo in cui vivono "ciò che sappiamo e ciò che abbiamo concluso" per un caso. È la memoria di lavoro persistente, verificabile e a prova di manomissione di Eye, e i suoi contenuti vengono iniettati nel prompt di Eye a ogni turno (la mappa letteralmente è la memoria).

• 🧭 Verdetto → Narrativa → Evidenze. Una gerarchia rigorosa: un Verdetto per caso, le Narrative al di sotto (affermazioni, ciascuna con uno stato — proven · open · negative · needs · absolute), e le Evidenze supportate da artefatti al di sotto.
• 🪟 La sua finestra. Si apre dal pulsante "Narrative Map" nella finestra della chat di Eye, così puoi osservare la chat, il report vivente e la memoria del caso fianco a fianco; si aggiorna in tempo reale man mano che le cose cambiano.
• ↔️ Bidirezionale — una memoria che comandi. Sia le modifiche di Eye che le tue note passano attraverso un singolo commit validato GEP e vengono sigillate in un log di audit incatenato tramite hash (narrative_map_audit.jsonl). Puoi aggiungere, modificare e rimuovere le sue affermazioni ed evidenze, dando forma direttamente al modo in cui Eye comprende e interpreta il caso.
• 🚫 Non afferma mai ciò che non è supportato. Una narrativa di Eye può rimanere open senza evidenze mentre indaga, ma non potrà mai essere proven senza evidenze; un tema che Eye ha verificato ma trovato vuoto si converte automaticamente in negative — perché un'assenza documentata è di per sé un risultato.

Come Funziona la Conformità

La conformità non è una funzionalità aggiunta sopra — è applicata nella pipeline.

• 🔗 Catena di custodia (Sigillo delle Prove). Ogni payload che Eye invia a un LLM viene sigillato: il SHA-256 dei byte esatti, il conteggio dei token, il modello + il suo limite di contesto e la provenienza di ogni riga di evidenza (database:table:rowid, più offset calcolati per i record MFT). I sigilli sono append-only e incatenati tramite hash su <case>/EYE_Logs/eye_payload_seal.jsonl — un singolo record alterato o rimosso spezza la catena, quindi il log dimostra matematicamente quali byte il modello ha analizzato.
• 🚫 Nessuna troncatura silenziosa. Quando il contesto si fa stretto, Eye si auto-ripara e rialloca i budget in un ordine rigoroso: Priorità 1 (Immovibile): Evidenze Grezze + Il Prompt di Sistema › Priorità 2 (Sacrificabile): Conversazione Informale › Priorità 3 (Flessibile): Contesto RAG. Se il nucleo di prove non ci sta ancora, Eye rifiuta piuttosto che eliminare silenziosamente le prove.
• 🧾 Traccia di audit della troncatura. Ogni decisione sul contesto viene registrata su <case>/EYE_Logs/truncation_audit.log (SUMMARIZED, TRUNCATED, PRESERVED, PINNED, UNPINNED, BUDGET_REDUCED), ciascuna con un hash. Le prove rilevate vengono automaticamente fissate oltre una soglia di confidenza; puoi anche fissare manualmente i messaggi.

📖 Architettura completa di Eye: eye/README.md.

📖 Eye-Describe — Base di Conoscenza degli Artefatti a Livello di Byte

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

Storicamente, gli investigatori cadevano nella trappola di fidarsi dei propri strumenti forensi senza capire come si comportano gli artefatti sottostanti o come lo strumento li ha analizzati. Il rischio oggi è semplicemente sostituire "lo strumento" con "l'IA". Un'IA può analizzare un record con perfetta accuratezza tecnica e collocarlo comunque nel contesto sbagliato — cambiando l'intero significato della prova.

Eye-Describe esiste affinché né l'umano né il modello debbano tirare a indovinare. È un riferimento interattivo a livello di byte per le strutture binarie grezze degli artefatti Windows e svolge due ruoli contemporaneamente:

Ancorando il livello IA al comportamento documentato degli artefatti, Crow-Eye non ti chiede di fidarti di un modello — sta vincolando il modello a rispettare la forensica grezza.

Non sostituire la fiducia nello strumento con la fiducia nell'IA. Comprendi i dati.

🧪 Qualità e Validazione

Gli strumenti forensi sono utili solo se il loro output può essere difeso. Il lavoro di correttezza di Crow-Eye è volutamente visibile:

• Suite di regressione. Il Motore di Correlazione è bloccato da una suite pytest che copre l'analisi dei timestamp, la normalizzazione delle identità, il fan-out multi-timestamp, il contratto dello scrittore, l'authoring di Eye (governance GEP lato scrittura) e il registro dei campi standard. Il motore UBA include una propria suite, inclusa un'esecuzione end-to-end su un caso reale.
• Harness di validazione. Un harness olistico esercita tutte e 7 le wing predefinite contro entrambi i motori su un caso Windows reale di ~700K record.
• Storia dei difetti pubblicata. Le regressioni di accuratezza e il loro impatto misurato sono documentate apertamente in RELEASE_NOTES.md — inclusi casi in cui una correzione ha cambiato i record visti di ordini di grandezza. Sapere cosa era sbagliato e quando fa parte di ciò che rende un risultato difendibile.
• Contabilità verificabile delle prove. Ogni record finisce o in una corrispondenza o in un bucket di scarto denominato, e il registro degli scarti per finestra rende "nessuna prova rimasta" qualcosa che puoi verificare dal log piuttosto che prendere per fede.
• Log a prova di manomissione. verify_chain() ripercorre il log di audit della Narrative Map e la catena del Sigillo delle Prove per rilevare modifiche — inclusi i campi leggibili dall'uomo.

🔬 Piattaforma di RicercaCrow-Eye è più di un software: è una piattaforma di ricerca aperta che accelera l'intero campo dell'analisi forense di Windows. Il progetto si concentra su:

• Pubblicazione di documentazione dettagliata sulle strutture interne degli artefatti.
• Condivisione di logiche di correlazione e metodologie.
• Abilitazione della revisione tra pari, trasparenza e collaborazione accademica.
• Contributo alla conoscenza collettiva della comunità forense.

🛠️ Note tecniche

• L'analisi del registro di sistema richiede file hive completi.
• Alcuni artefatti richiedono una gestione speciale a causa dei meccanismi di blocco dei file di Windows (vedi Registry personalizzato / file bloccati).
• Il parsing di LNK e Jump List è gestito dal parser dedicato di Crow-Eye.

📸 Schermate

Una selezione dell'interfaccia e delle viste di analisi di Crow-Eye.

🎥 Video demo:

🚧 Roadmap

Lavoro pianificato e in corso (vedi RELEASE_NOTES.md per le modifiche già rilasciate):

• 📊 Viste e report GUI avanzati — visualizzazione e reporting più ricchi.
• 🔄 Dialogo di ricerca potenziato — filtri avanzati con supporto al linguaggio naturale.
• 🎯 Mappatura semantica potenziata — mappatura completa dei campi su tutti i tipi di artefatti.
• 📈 Punteggio di correlazione avanzato — punteggio di confidenza raffinato e spiegabile.
• ⚡ Correlazione parallela — distribuzione tramite pool di processi, abilitata per impostazione predefinita per carichi di lavoro elevati.

Hai un'idea o vuoi aggiungere un artefatto? Apri una issue o consulta Contribuire.

📚 Documentazione

• TECHNICAL_DOCUMENTATION.md — architettura, componenti e guida allo sviluppo.
• RELEASE_NOTES.md — le novità di ogni release (UBA, Narrative Map, backend cloud Eye, hardening della gestione dei casi, …).
• Correlation Engine docs — panoramica, motore, piume, ali, pipeline.
• Timeline architecture — interni del modulo timeline.
• Eye architecture e GEP standard — l'assistente AI e il protocollo che lo governa.

🤝 Contribuire

Crow-Eye è costruito come piattaforma di ricerca aperta e i contributi sono benvenuti: nuovi parser, regole di correlazione, documentazione e ricerca sugli artefatti.

• Contributi generali: CONTRIBUTING.md
• Correlation Engine (area prioritaria): correlation_engine/CONTRIBUTING.md
• Contatto: [email protected] · oppure apri una issue / pull request.

🌐 Sito web e community

• 🌍 Sito web ufficiale: crow-eye.com — risorse, documentazione e download.
• 💬 Discord: Unisciti al Discord di Crow-Eye — assistenza diretta, ricerca sugli artefatti e annunci delle release.

📄 Licenza

Crow-Eye è distribuito sotto la GNU General Public License v3.0 (GPL-3.0). È possibile utilizzarlo, studiarlo, condividerlo e modificarlo liberamente secondo i termini di tale licenza.

📝 Come citare Crow-Eye

Se utilizzi Crow-Eye in lavori accademici, ricerche pubblicate o report di casi, ti preghiamo di citarlo:```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} }

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

Per le citazioni metodologiche, il Ghassan Elsman Protocol è documentato separatamente in [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md).

## 💖 Supporto

Crow-Eye è gratuito e open-source, creato e mantenuto da una sola persona. Se ti è utile per il tuo lavoro, valuta di sponsorizzarlo — finanzia direttamente nuovi parser e ricerca: **[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**.

## Crediti

Creato e mantenuto da **Ghassan Elsman**.