Crow-Eye — Windows-Forensik-Engine

Eine forensische Zeitmaschine für Windows.
Crow-Eye erkennt nicht nur – es rekonstruiert, was tatsächlich passiert ist auf der Zeitleiste, von der Erfassung bis zu einem Urteil, das bis zu seinen Quellaufzeichnungen zurückverfolgbar ist.

Inhaltsverzeichnis

• Überblick
• ✨ Highlights
• 👥 Für wen Crow-Eye gedacht ist
• 🧭 Subsysteme auf einen Blick
• 🏗️ Architektur
• 📥 Download & Installation
• 🚀 Schnellstart
• 📂 Unterstützte Artefakte
• 🔧 Analysemodi
  • 📎 Beweismittel importieren (Drittanbieterdaten)
• 🧠 Benutzerverhaltensanalyse (UBA)
• 🧩 Korrelations-Engine
• 👁️ Eye – Der Forensik-KI-Assistent
• 📖 Eye-Describe – Byte-Level-Wissensdatenbank für Artefakte
• 🧪 Qualität & Validierung
• 🔬 Forschungsplattform
• 🛠️ Technische Hinweise
• 📸 Screenshots
• 🚧 Roadmap
• 📚 Dokumentation
• 🤝 Mitwirken
• 🌐 Website & Community
• 📄 Lizenz
• 📝 Crow-Eye zitieren
• 💖 Unterstützung
• Credits

Überblick

Crow-Eye ist eine Open-Source-Engine (GPL-3.0) für Windows-Forensik, die Erfassung, Analyse, Verifizierung, Intelligence und KI vereint. Die meisten Sicherheitstools fragen „ist das böse?“ und stufen alles als unbedenklich ein, was legitim aussieht. Crow-Eye stellt eine andere Frage: „Was ist passiert?“ Es korreliert alle Aktivitäten – verdächtige oder nicht – und rekonstruiert die tatsächliche Ereignisabfolge auf einem System, sodass die Wahrheit einer Untersuchung aus Beweisen rekonstruiert statt aus Warnmeldungen erraten wird.

Genau dieses rekonstruktionsorientierte Design ist es, was für die Jagd auf APT- und staatlich geförderte Bedrohungen erforderlich ist: Raffinierte Angreifer leben in legitimen Tools (powershell.exe, PsExec, certutil) und in der Reihenfolge der Aktionen – unsichtbar für Tools, die alles als normal einstufen. Da Crow-Eye nie etwas verwirft und über Ausführungs-Artefakte argumentiert (die Log-Manipulation und Anti-Forensik überstehen), kann sich der Angriff nicht verstecken. Dieselbe Engine bleibt für die alltägliche DFIR-Arbeit und für Nicht-Experten zugänglich, die einfach wissen möchten, was auf einem Computer passiert ist.

• 🕰️ Rekonstruieren, nicht nur erkennen – die Zeitleiste des tatsächlich Geschehenen wiederherstellen.
• 🖥️ Plattformübergreifend – vollständige Live- und Offline-Analyse unter Windows; Offline-Analyse und Forensik-Image-Parsing unter Linux (Live-Parser sind nur für Windows verfügbar).
• 🔒 Von Natur aus privat – 0 ms Daten verlassen das Gerät; der Eye-KI-Assistent kann vollständig ohne Netzwerkverbindung betrieben werden.
• 🧾 Gerichtsfest – Beweismittel werden kryptografisch versiegelt und jeder Schritt ist nachvollziehbar.
• 📦 Aktuelle Version: 0.12.6 · Korrelations-Engine: 1.7.0 · Lizenz: GPL-3.0.

✨ Highlights

• Rekonstruktion statt Erkennung. Korreliert jedes Artefakt zu einer navigierbaren, entitätsbezogenen Geschichte statt zu einem Haufen von Warnmeldungen.
• Durchgängig integriert – Erfassung → Korrelation → Zeitleiste → Verhaltensanalyse → KI → versiegelter Fall-Speicher: eine vollständige Pipeline, die kein einziges etabliertes Tool abdeckt.
• Artefakt-tief, nicht log-flach. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists und mehr überstehen das Löschen von Logs und „Living-off-the-Land“-Tricks, die reine Log-Tools blind machen.
• Der Eye-KI-Assistent – forensische Untersuchung in natürlicher Sprache mit einer nachvollziehbaren, manipulationssicheren Beweismittelkette, einsetzbar in der Cloud, auf einem privaten Server oder vollständig offline.
• Benutzerverhaltensanalyse (UBA) – verwandelt rohe Artefakte in eine verständlich formulierte, für HR/Prüfer lesbare Aktivitätsgeschichte.
• Kostenlos & Open Source (GPL-3.0) – für jeden prüfbar, mit aktiver Forschungs- und Dokumentationsarbeit.

👥 Für wen Crow-Eye gedacht ist

Crow-Eye wird in sehr unterschiedlichen Arbeitsabläufen eingesetzt. Jeder Zugang führt durch eine andere Tür in die Engine:

Jeder Collector funktioniert. Crow-Eye benötigt kein eigenes Erfassungstool. Richten Sie den Offline Importer auf einen Ordner mit rohen Artefakten, die von Velociraptor, KAPE, einem EDR-Sammelpaket oder einem anderen Collector erzeugt wurden – er indiziert die unterstützten Artefakte und führt die Offline-Parser darüber aus. Zusätzlich können Ausgaben von Plaso, Autopsy, Volatility oder jedem anderen Tool als CSV, JSON oder SQLite über Import Evidence eingebracht und neben nativen Artefakten korreliert werden.

🧭 Subsysteme auf einen Blick

Crow-Eye ist als integrierter Kreislauf aufgebaut – jede Stufe speist die nächste, von der rohen Festplatte bis zu einem vertretbaren Urteil.

🏗️ Architektur

Crow-Eye ist eine integrierte Pipeline, kein Sack voller Parser. Beweismittel fließen in eine Richtung, und jede Stufe behält ihre Verbindung zum Quell-Datensatz.```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

*Beweisquelle → Erfassung → Fall-Datenbanken → Analyse → KI-Ebene → Bericht*


**So ist es zu lesen:**

| Stufe | Das ist wichtig |
|---|---|
| ① → ② | **Vier unabhängige Türen in einen Fall.** Sie benötigen niemals Crow-Eyes eigenen Collector – ein Ordner von Velociraptor, KAPE oder ein EDR-Paket läuft durch den Offline-Importer, und CSV/JSON/SQLite von Drittanbietern läuft über Import Evidence. |
| ② → ③ | Alles läuft an einem Ort zusammen: **die Fall-Datenbanken**. Geparste Artefakte landen in `Target_Artifacts/`; importierte Drittanbieter-Beweise landen in `Imported_Evidence/` und werden automatisch erkannt. |
| ③ → ④ | **Die drei Analysepfade sind voneinander unabhängig.** Timeline und UBA lesen die Fall-Datenbanken direkt – keiner erfordert einen Korrelationslauf. Die Correlation Engine ist eine *zusätzliche* Ebene, keine Voraussetzung. |
| ③ → ④ | **Dynamic Linking sitzt neben der Timeline und UBA** – ein vierter, unabhängiger Leser der Fall-Datenbanken (es hat nichts mit der Timeline-Visualisierung zu tun). Es sammelt Identitätszuordnungen (SID → Benutzername, MAC → Netzwerk, Hash/GUID → App) in eine fallbezogene `Crow_Intelligence.db` und blendet diesen Kontext dann **inline in den Artefakt-Datentabellen** über nicht-destruktive `ATTACH`- + `LEFT JOIN`-Abfragen ein. Es verändert, wie Datensätze *gelesen* werden, niemals die Beweise. |
| ④ → ⑤ | Das Auge fragt die Fall-Datenbanken direkt ab und kann Korrelationsergebnisse **bei Bedarf** abrufen. Es fasst Beweise selbst nie an – es erzeugt Tool-Aufrufe, die Crow-Eye ausführt und protokolliert. |
| ⑤ → Report | Der **Living Report wird allein vom Auge erstellt**, über seine `report_*`-Tools. Timeline und UBA sind Analyse-Oberflächen – sie schreiben nicht in den Bericht. Fallbezogene Erkenntnisse können dennoch separat über [Search & Export](#-search--export) exportiert werden. |
| ⑤ ↔ | Die **Narrative Map ist bidirektional**: Das Auge schreibt hinein, Sie schreiben hinein, und ihre Inhalte werden bei jeder Runde in den Prompt des Auges eingespeist. Sie ist das Gedächtnis, und Sie können sie steuern. |
| ⑤ ⟳ | Die **Compliance-Seite prüft das Auge.** Jeder Tool-Aufruf des Auges ist an die **EvidenceSeal**-Hash-Kette gebunden; die Seite zeigt live den **GEP**-Status pro Regel (10 Prinzipien), der anhand dieser Kette und `EYE_Logs/` verifiziert wird, exportierbar als `audit_trail.json`. |

**Unabhängige Stufen.** Die Timeline und die UBA lesen die Fall-Artefakt-Datenbanken **direkt** – keine der beiden erfordert einen Korrelationslauf, und die Timeline ist nicht von der Correlation Engine abhängig (sie wendet ihre eigene leichtgewichtige zeitliche Gruppierung an). Korrelation ist eine zusätzliche Analyseebene, deren Ergebnisse das Auge abfragen kann.

**Prinzipiell schreibgeschützt.** Das Parsing schreibt in die Fall-Datenbank; jede nachgelagerte Stufe (UBA, Timeline, Korrelations-Viewer, das Auge) öffnet diese Datenbanken **schreibgeschützt**. Die ursprünglichen Beweise werden niemals verändert – [Dynamic Linking](#-analysis-modes) liest die Fall-Datenbanken, um eine fallbezogene `Crow_Intelligence.db` mit Identitätszuordnungen aufzubauen, und reichert die Artefakt-Datentabellen inline über nicht-destruktive `ATTACH`- + `LEFT JOIN`-Abfragen an, anstatt Zeilen neu zu schreiben.

**Von Grund auf kontrolliert.** Jede Aktion des Auges ist an die manipulationssichere **EvidenceSeal**-Hash-Kette gebunden, und die **Compliance**-Seite verifiziert das Auge kontinuierlich anhand des [Ghassan-Elsman-Protokolls (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) – Live-Status pro Regel, exportierbar nach `EYE_Logs/audit_trail.json`.

## 📥 Download & Installation

> **Empfohlen:** Laden Sie den gepackten Windows-Build (**MSI-Installer / EXE**) von der offiziellen Website herunter – keine Python-Einrichtung, läuft sofort einsatzbereit.

### ▶️ [Crow-Eye für Windows herunterladen → crow-eye.com/download](https://crow-eye.com/download)

Der **installierte MSI/EXE-Build ist die empfohlene Möglichkeit, Crow-Eye auszuführen**, und er ist **unsere oberste Priorität bei Updates**:

- 🛡️ **Schnellste Korrekturen.** Wenn ein Problem gefunden oder ein Fehler gemeldet wird, veröffentlichen wir **so schnell wie möglich** eine aktualisierte EXE – im gepackten Build landen Korrekturen zuerst.
- 🔄 **Integrierte automatische Updates.** Öffnen Sie in der installierten App **Einstellungen → Updates**, um **nach Updates zu suchen und diese automatisch zu installieren** – keine manuelle Neuinstallation.
- 📦 **Keine Einrichtung.** Keine Installation von Python, Node oder Abhängigkeiten erforderlich.

> Sie möchten lieber aus dem Quellcode ausführen? Siehe **[Quick Start](#-quick-start)** unten. Der From-Source-Build ist für Mitwirkende gedacht und **enthält keinen Auto-Updater** – verwenden Sie für automatische Updates die MSI/EXE.

## 🚀 Quick Start

### Option A — Installierter Build (empfohlen)

Laden Sie die **MSI/EXE** von [crow-eye.com/download](https://crow-eye.com/download) herunter, installieren Sie sie und starten Sie **Crow-Eye** als Administrator. Erstellen Sie einen Fall und beginnen Sie mit der Analyse.

### Option B — Aus dem Quellcode ausführen (Entwickler)

> Für Mitwirkende und fortgeschrittene Benutzer. Dieser Pfad **enthält keinen Auto-Updater** – verwenden Sie für automatische Updates die MSI/EXE.

**Voraussetzungen** (beim ersten Start automatisch installiert):

- Python 3.12.4
- **Node.js & npm** – erforderlich für **Timeline-Visualisierung**
- Wichtige Pakete: PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**Empfohlene Hardware**

| | Minimum | Empfohlen für große Fälle |
|---|---|---|
| **RAM** | 8 GB | 16 GB+ (MFT/USN-Sätze mit Millionen von Datensätzen) |
| **Festplatte** | 5 GB frei | Freier Speicherplatz ≥ 2× der Größe des zu parsenden Beweismaterials |
| **CPU** | 4 Kerne | 8+ Kerne |
| **Betriebssystem** | Windows 10/11 (voll) · Linux (Offline- & Image-Analyse) | — |

> Die Korrelation streamt bei sehr großen Datensätzen in konstantem Speicher, daher ist der RAM selten die harte Grenze – üblicherweise sind es Datenträgerdurchsatz und freier Speicherplatz.

**Start** (als Administrator ausführen, damit Crow-Eye auf System-Artefakte zugreifen kann):```bash
python "Crow Eye.py"

Die Hauptoberfläche öffnet sich, Sie erstellen einen Fall, und die gesamte Analyseausgabe wird unter diesem Fallverzeichnis zur späteren Überprüfung und Berichterstattung organisiert.

🖥️ Hinweis zur Plattformunabhängigkeit: Unter Linux werden die Live-Parser automatisch deaktiviert und Crow-Eye läuft im Offline-/Forensik-Image-Modus. Die vollständige Live-Erfassung ist nur unter Windows verfügbar.

📂 Unterstützte Artefakte

Crow-Eye analysiert eine breite Palette von Windows-Artefakten zu Ausführung, Dateisystem und Benutzeraktivität — sowohl von einem Live-System als auch aus Offline-Quellen (gesammelte Ordner oder forensische Images).

Jump Lists & LNK werden von Crow-Eyes eigenem speziell entwickelten LNK-/Jump-List-Parser analysiert — nicht von einem Drittanbieter-Modul.

Benutzerdefinierte Registry / gesperrte Dateien: Windows sperrt die Live-Registry-Hives (NTUSER.DAT, SOFTWARE, SYSTEM) während des Betriebs. Für eine benutzerdefinierte Analyse eines Live-Systems booten Sie von externen Medien (WinPE/Live-CD), verwenden Sie Forensik-Erfassungswerkzeuge oder analysieren Sie ein Datenträger-Image.

Details pro Artefakt

• Jump Lists & LNK — werden automatisch aus den Standard-Systempfaden von Crow-Eyes eigenem dediziertem Parser analysiert (Dateizugriff, Zielpfade, Zeitstempel und Metadaten).
• Registry — analysiert automatisch die System-Hives. Für eine benutzerdefinierte Registry-Analyse kopieren Sie die Hive-Dateien in CrowEye/Artifacts Collectors/Target Artifacts (oder in den Ordner registry/ Ihres Falls):
  • NTUSER.DAT aus C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE aus C:\Windows\System32\config\SOFTWARE
  • SYSTEM aus C:\Windows\System32\config\SYSTEM
  • Windows sperrt diese während des Betriebs — für ein Live-System booten Sie von externen Medien (WinPE/Live-CD), verwenden Sie Forensik-Erfassungswerkzeuge oder analysieren Sie ein Datenträger-Image.
• Prefetch — analysiert C:\Windows\Prefetch und extrahiert Ausführungshistorie und forensische Metadaten (einschließlich Zeitstempeln pro Ausführung).
• Ereignisprotokolle — automatische Analyse der System-/Sicherheits-/Anwendungsprotokolle in eine Datenbank für eine umfassende Analyse.

🔧 Analysemodi

🦅 Crow-Claw-Erfassung

Crow-Claw ist Crow-Eyes spezialisierte Erfassungs-Engine zum Sammeln und Sichern von Artefakten von Live-Systemen oder gemounteten Images.

• Selektive Sammlung — wählen Sie bestimmte Artefaktkategorien (Registry, Ereignisprotokolle, Dateisystem) oder sammeln Sie alles.
• Tiefenscan — durchläuft Verzeichnisse und Unterverzeichnisse, um forensische Spuren zu finden.
• Sichere Sicherung — Artefakte landen in einem strukturierten Fallverzeichnis, das die forensische Integrität bewahrt.

🔍 Offline-Analyse (Offline-Importeur)

Analysieren Sie Artefakte, die aus beliebiger Quelle gesammelt wurden, ohne eine Live-Verbindung zum Ziel — drei klare Operationen:

• SCAN (Erkennung) — durchläuft die Quelle und indexiert jedes unterstützte Artefakt anhand von Dateinamen- und Erweiterungsmuster (schnell, schreibgeschützt; es werden keine Dateiinhalte gelesen und in dieser Phase keine Magic-Byte-Prüfungen durchgeführt). Nichts wird verschoben.
• COLLECT (Erfassung) — kopiert die identifizierten Dateien physisch in den Ordner live_acquisition des Falls, organisiert nach Typ.
• PARSE (granular) — überprüft identifizierte Elemente pro Typ (AMCACHE, EVTX, PREFETCH, …) und analysiert ausgewählte Dateien (oder alle) in die forensische Datenbank.

Die Analyse wird von Crow-Eyes dedizierten Offline-Parsern übernommen — derselben Artefaktlogik wie im Live-Modus, die auf gesammelten Dateien arbeitet: Prefetch, Registry, MFT, USN (plus dem MFT/USN-Korrelator), AmCache, ShimCache, SRUM, Ereignisprotokolle, LNK/JumpLists und Papierkorb.

📎 Import Evidence (third-party data)

Über rohe Artefakte hinaus kann Crow-Eye forensische Ausgaben von Drittanbietern direkt in einen Fall aufnehmen — Plaso, Autopsy, Volatility oder beliebige benutzerdefinierte Exporte — und sie für das Eye und die Timeline nutzbar machen, ohne dass zuvor ein Korrelationslauf erforderlich ist.

Da der Fall-Datenbank-Manager automatisch jede .db unter dem Fallbaum erkennt, werden importierte Beweise sofort verfügbar für:

• Das Eye — neben nativen Artefakten in natürlicher Sprache abfragbar (das Schema-Manifest wird beim Import aktualisiert).
• Die interaktive Timeline — bereitgestellt als Artefakttyp imported, mit funktionierender Zeitfenster-Filterung und Zeitgrenzen.
• Die Correlation Engine — als Feather für die toolübergreifende Korrelation mit nativen Artefakten nutzbar.

Der Importeur verwendet ausschließlich die Standardbibliothek (sqlite3 / csv / json) und läuft in einem Hintergrund-Worker, sodass große Importe die Benutzeroberfläche nicht blockieren.

⚡ Live-Analyse

Analysiert Artefakte direkt vom laufenden Windows-System und extrahiert sie automatisch aus ihren Standardpfaden für die Echtzeit-Forensik-Analyse.

🗂️ Fallverwaltung

Jede Untersuchung ist ein Fall: ein in sich geschlossenes Verzeichnis, das Artefaktdatenbanken und Analyseausgabe organisiert. Crow-Eye verfolgt zuletzt verwendete Fälle (mit Favoriten, Tags und Status), validiert einen Fall beim Öffnen, schreibt die Konfiguration atomar (absturzsicher) und unterstützt Fall-Konfigurations-Import/-Export und Vorlagen mit vorgefertigten semantischen Zuordnungen.

🕰️ Interaktive Timeline-Visualisierung

Korrelieren Sie Ereignisse über Artefakte hinweg auf einem einheitlichen Zeitraster, mit Heatmap-, Wochen- und Tages-Ansichten — eine identitätsverknüpfte, gerichtsfest nachvollziehbare Geschichte statt einer flachen Super-Timeline.

Die Timeline liest die analysierten Artefaktdatenbanken des Falls direkt und ist unabhängig von der Correlation Engine — Sie müssen keine Feather erstellen, keine Wings verfassen oder eine Pipeline ausführen, um sie zu nutzen. Sie wendet ihre eigene leichtgewichtige zeitliche Gruppierung an (Exakt-Zeitstempel- und Zeitfenster-Korrelation, Gruppierung nach Anwendung, Pfad oder Benutzer), um Ereignisse im Raster zueinander in Beziehung zu setzen. Beweise, die über Import Evidence eingebracht wurden, erscheinen ebenfalls in der Timeline als Artefakttyp imported, mit funktionierender Zeitfenster-Filterung und Zeitgrenzen.

🔎 Suche & Export

Volltextsuche über die Fall-Datenbank, plus Export als CSV (Tabellenkalkulationen), JSON (Integration mit anderen Tools) und detaillierte HTML-Berichte (vollständige Dossiers, die jedes mit einem Suchbegriff verknüpfte Artefakt konsolidieren).

🔗 Dynamic Linking

Übersetzt rohe technische Identifikatoren — SIDs, MAC-Adressen, Hashes — im laufenden Betrieb in einen menschenlesbaren Kontext. Dynamic Linking reichert die Ansicht mithilfe nicht-destruktiver SQL-ATTACH-Abfragen an, sodass die ursprünglichen Beweise nie verändert werden, und kann große Mengen an IOC-Bedrohungsfeeds aufnehmen, um bekannte schädliche Indikatoren inline zu kennzeichnen.

🧠 User Behavior Analytics (UBA)

Verwandeln Sie rohe Artefakte in eine in einfacher Sprache verfasste Aktivitätsgeschichte — einen für Manager/HR lesbaren Bericht darüber, was ein Benutzer und seine Anwendungen tatsächlich getan haben, wobei jede Aussage bis zum exakten Quellbeweis rückverfolgbar ist.

User Behavior Analytics (UBA) liest die analysierten Artefaktdatenbanken im Ordner Target_Artifacts/ Ihres Falls (strikt schreibgeschützt) und verarbeitet sie über einen deklarativen Regelsatz, um eine klare, chronologische Activity Story zu erzeugen. Öffnen Sie es über die Toolbar-Schaltfläche "User Behavior" oder mit Ctrl+Shift+B (ein Fall muss geladen sein).

• 🧩 40 deklarative Verhaltenserkennungen (uba/config/behavior_rules.json) — ohne Code anpassbar — jeweils nach Schweregrad klassifiziert: routine · notable · suspicious · critical.
• 🕵️ Erkennt relevantes Verhalten: An-/Abmeldung / Entsperren, Programmstart · -ausführung · -installation, Datei öffnen / löschen / mutmaßliches Kopieren, USB-Geräteverbindung, Zugriff auf Netzwerkfreigaben, Persistenz & Autostart, Verwendung expliziter Anmeldeinformationen (runas), Konto- & Gruppenänderungen, Dienständerungen, Manipulation der Systemuhr (verdächtig) und Löschen von Ereignisprotokollen (kritisch).
• 🗺️ Drei Ansichten — ein Activity Story-Feed, eine Activity Map-Heatmap (Tag × Stunde) und ein "What we can see"-Ehrlichkeitsbericht, der jede Erkennung für diesen Fall als Working / Limited / No data / By design kennzeichnet.
• 🔗 Jede Aktivität ist beleggestützt. Klicken Sie auf ein beliebiges Element, um den exakten zugrunde liegenden Datensatz zu öffnen (database : table : rowid) — nichts wird ohne Quelle behauptet.
• 👤 Ehrliche Zuordnung. Akteure werden als Benutzer / Anwendung / System identifiziert (oder bleiben leer) — UBA rät nie, wer was getan hat.

Erkennungsabdeckung

Die 40 Erkennungen umfassen vier Schweregradklassen und die gesamte Bandbreite des analysierten Artefaktsatzes:

• ✅ Identity-Based Engine — produktionsreif, empfohlen für Identitätsverfolgung (O(N log N))
• ✅ Feather Builder / FeatherWriter — importiert CSV/JSON/SQLite aus jedem Tool; transaktionales Batching + Schema-Metadaten
• ✅ Wings System & Pipeline-Orchestrierung — Korrelationsregeln erstellen/verwalten und Workflows automatisieren
• ✅ Identitätsgruppierung — einheitlich über Engine, Viewer und semantische Phase hinweg
• ✅ Standardfelder-Registrierung — zentrale maßgebliche Quelle für Feldsynonyme
• ✅ Multi-Zeitstempel-Fan-Out — jeder JSON-Listenzeitstempel wird korreliert
• 🔄 Parallele Korrelation — Grundlage vorhanden; Profiling + Prozesspool-Dispatch als Nächstes
• 🔄 Semantisches Mapping & Korrelations-Scoring — aktive Erweiterungen

Hauptfunktionen

• 🔄 Dual-Engine-Architektur: Wählen Sie zwischen Time-Window Scanning (O(N log N)) und identitätsbasierten (O(N log N)) Korrelationsstrategien.
• 📊 Multi-Artefakt-Unterstützung: Korrelieren Sie Prefetch, ShimCache, AmCache, Ereignisprotokolle, LNK-Dateien, Jumplists, MFT, USN, SRUM, Registrierung, Papierkorb und mehr.
• 🔌 Universeller Import: Importieren Sie CSV/JSON/SQLite-Ausgaben aus jedem forensischen Tool und konvertieren Sie sie in Feather-Datenbanken.
• 🎯 Intelligente Identitätsgruppierung: Varianten wie Chrome.exe/chrome.dll/Chrome.EXE werden zu einem Bucket zusammengefasst; Versionen und Architekturqualifikatoren bleiben getrennt.
• 🕒 Tolerante Zeitstempel: FILETIME, ISO 8601, Unix-Epoch (s/ms/μs), YYYYMMDD, US-Schrägstrich und annotierte Zeichenketten werden alle beim ersten Versuch korrekt geparst.
• 📈 Multi-Zeitstempel-Fan-Out: JSON-Zeitstempellisten (Prefetch run_times) werden erweitert, sodass jede Ausführung ihr eigenes Korrelationsereignis erhält.
• 🧰 Eine Quelle der Wahrheit: Feldsynonyme in config/standard_fields/*.json; Tabellenmetadaten in correlation_engine/config/feather_schemas.json — erweitern Sie per JSON-Editierung statt Code.
• ⚡ Streaming + Thread-sicher: query_time_range_iter mit O(1)-Speicher; lock-geschützte Feather-Caches; bereit für parallele Korrelation.

Systemarchitektur

Die Korrelations-Engine besteht aus vier Hauptkomponenten:

1. 🗄️ Feathers (Datennormalisierung)

Zweck: Transformieren Sie rohe forensische Artefakte in ein standardisiertes, abfragbares Format.

• SQLite-Datenbanken mit normalisierten forensischen Artefaktdaten — ein Feather pro Artefakttyp (Prefetch, ShimCache, Ereignisprotokolle, …) mit einem standardisierten Schema und Metadaten für effiziente Abfragen.
• Ein universelles Format, das Daten aus jedem forensischen Tool akzeptiert.``` 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

**Unterstützte Importformate:** CSV (jede Datei mit Kopfzeile), JSON (flach oder verschachtelt) und SQLite (direkter Import). Automatische Spaltenzuordnung, Datentyp-Erkennung, Zeitstempel-Normalisierung auf ISO, Validierung und optimierte Indizes.```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Wings (Korrelationsregeln)

Zweck: Definieren, welche Artefakte korreliert werden sollen und wie.

• JSON/YAML-Regeln, die ein Zeitfenster, Mindestübereinstimmungen, eine Ankerpriorität und die Feathers (mit Gewichten) zur Korrelation festlegen — fallübergreifend wiederverwendbar. Jeder Wing ist verfass- und versiegelbar (erfasst, wer ihn verfasst hat, warum und die Belege, die ihn motiviert haben).```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. ⚙️ Engines (Korrelationsstrategien)

**Zweck**: Korrelationslogik ausführen, um Beziehungen zwischen Artefakten zu finden. Strukturelle Verknüpfungen kommen **zuerst**; ein stufen-gewichteter Score wird als *Interpretation/Ranking* darübergelegt, nicht als Grundlage für einen Match.

**Time-Window Scanning Engine** — ideal für zeitbasierte Analyse und systematische zeitliche Korrelation. Scannt die Zeit in festen Intervallen, sammelt pro Fenster Datensätze aus allen Feathers, wendet semantisches Feld-Matching + gewichtete Bewertung an und verhindert Duplikate durch MatchSet-Tracking. **O(N log N)** (indizierte Zeitstempelabfragen); Stapelverarbeitung (~2.567 Fenster/Sekunde).

**Identity-Based Correlation Engine** — ideal für große Datensätze (>1.000 Datensätze) und Identitätsverfolgung. Extrahiert und normalisiert Identitäten, gruppiert Datensätze nach Identität, erstellt zeitliche Anker innerhalb jedes Clusters, stuft Beweise als primär/sekundär/unterstützend ein und streamt auch sehr große Mengen (>5.000 Anker) bei konstantem Speicherverbrauch. **O(N log N)**; 40+ Identitätsfeldmuster pro Typ.

**Engine-Auswahl:** Verwenden Sie die Time-Window engine für zeitbasierte Analysen und die Identity-Based engine für Identitätsverfolgung — beide sind produktionsreif und für große Datensätze mit indizierten Abfragen optimiert.

#### 4. 🔄 Pipelines (Workflow-Orchestrierung)

**Zweck**: Automatisierung vollständiger Analyse-Workflows von der Feather-Erstellung bis zur Ergebnisgenerierung. Eine Pipeline liest ihre Konfiguration (engine type, wings, feathers), instanziiert die richtige Engine über den EngineSelector, führt jeden Wing aus, aggregiert Matches, speichert Ergebnisse (DB + JSON) und zeigt sie in der GUI mit Filterung und Visualisierung an.```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"
  }
}

Wie alles zusammen funktioniert```

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

### Beispiel-Anwendungsfall: Ausführungsnachweis finden

**Szenario**: weisen Sie nach, dass `malware.exe` auf einem System ausgeführt wurde.```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

Ich habe keinen Eingabetext in deiner Nachricht erhalten – der Bereich nach „INPUT:“ ist leer. Bitte sende den tatsächlichen Chunk-Inhalt (Chunk 18 von 25), damit ich ihn ins Deutsche übersetzen kann.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

Please provide the Markdown content to translate.```
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

Leistungs-Benchmarks

Erste Schritte mit der Correlation Engine

1. Starten: python -m correlation_engine.main
2. Feathers erstellen: Importieren Sie Ihre forensischen Artefakte (Prefetch, ShimCache, …).
3. Wings erstellen: Definieren Sie Korrelationsregeln für Ihre Untersuchung.
4. Pipeline erstellen: Konfigurieren Sie, welche Wings und Feathers verwendet werden sollen.
5. Ausführen: Führen Sie die Pipeline aus und zeigen Sie korrelierte Ergebnisse an.
6. Analysieren: Nutzen Sie den Results Viewer, um zeitliche Beziehungen zu untersuchen.

📚 Dokumentation der Correlation Engine

• Übersicht über die Correlation Engine — Systemübersicht mit Architekturdiagrammen
• Engine-Dokumentation — Dual-Engine-Architektur, Engine-Auswahl, Leistungsoptimierung
• Architektur — Komponentenintegration und Datenfluss
• Feather-Dokumentation — das Datennormalisierungssystem
• Wings-Dokumentation — Korrelationsregeln
• Pipeline-Dokumentation — Workflow-Orchestrierung
• Hinzufügen eines Artefakts — der Workflow zum Einbinden eines neuen Parsers in die Engine
• Registry der Standardfelder — kanonische Synonyme für Spaltennamen, die von beiden Engines und dem Eye geladen werden
• Beitragsleitfaden — wie Sie zur Engine beitragen können
• Schnellzugriffe: Engine-Auswahl · Fehlerbehebung · Leistungsoptimierung

👁️ Eye — Der Forensik-KI-Assistent

Ein leistungsstarker Assistent, kein Ersatz. Eye automatisiert und verifiziert die Hypothesen eines Ermittlers — es trifft die Entscheidung nie für Sie.

Eye ist der integrierte Forensik-KI-Assistent von Crow-Eye: ein erfahrener forensischer Ermittler, gestützt auf eine echte Wissensbasis über Windows-Artefakte. Es bietet Ihnen eine natürlichsprachliche Schnittstelle, um alles in einem Fall abzufragen, zu korrelieren und zu dokumentieren — Prefetch, MFT, Registry, Ereignisprotokolle, AmCache, ShimCache, SRUM und mehr — und führt dabei eine prüfbare, manipulationssichere Aufzeichnung darüber, was genau es getan hat. Eye kann vollständig auf Ihrer eigenen Hardware laufen (inklusive vollständig air-gapped), entsprechend der Datenschutzhaltung von Crow-Eye: „0 ms Daten vom Gerät gesendet“. Vollständige Architektur: eye/README.md.

Eye verwandelt konversationelle Fragen („zeig mir, was nach 22:00 Uhr von C:\Temp ausgeführt wurde“) in echte forensische Arbeit: Es plant einen Ansatz, ruft relevantes Artefaktwissen ab, führt SQL- und artefaktübergreifende Suchen in Ihren Falldatenbanken aus und synthetisiert eine validierte Antwort. Jede Antwort entsteht gleichzeitig an zwei Orten — als Chat-Antwort für Sie und als strukturierter Block, der in einen Living Report Workspace geschrieben wird, sodass sich das Dossier während der Untersuchung von selbst aufbaut.

Das Ghassan-Elsman-Protokoll (GEP)

Alles, was Eye tut, ist im Ghassan-Elsman-Protokoll (GEP) verankert — einem herstellerneutralen, tool-agnostischen Standard dafür, wie jede KI in der digitalen Forensik eingesetzt werden sollte. Es umfasst 10 Prinzipien, die ein konformes System einhalten muss, damit KI-gestützte Ergebnisse wahrheitsgemäß, auf Quelldatensätze zurückführbar und durch eine prüfbare, manipulationssichere Kette abgesichert bleiben, wobei der menschliche Ermittler die Kontrolle behält:

Crow-Eyes Eye ist die Referenzimplementierung des GEP; die Produktverhaltensweisen, die es aufrechterhalten, sind Betriebsregeln. 📜 Lesen Sie den Standard: eye/docs/GEP_standard.md.

Bereitstellungsmodi

Eye passt sich Ihrem Bedrohungsmodell über drei Bereitstellungsmodi an:

Im CLI-Agenten-Modus nutzt Crow-Eye einen bestehenden KI-Terminal-/Befehlszeilen-Agenten als Modell — anstelle einer Cloud-API oder eines lokalen Offline-Servers —, sodass Sie mit dem Agenten untersuchen können, den Sie bereits verwenden.

Die Untersuchungsschleife:

1. Öffnen oder erstellen Sie einen Fall — Eye begrenzt sich auf die Artefaktdatenbanken und die Historie dieses Falls.
2. Stellen Sie eine Frage in natürlicher Sprache oder starten Sie eine umfassende Triage mit einem Klick.
3. Eye führt seine Pipeline aus — Absicht erkennen → Wissen abrufen → Werkzeuge ausführen → synthetisieren.
4. Sie erhalten eine doppelte Ausgabe — eine direkte Chat-Antwort und einen neuen Block im Living Report.
5. Genehmigen Sie gesperrte Aktionen — Exporte und andere kritische Schritte warten auf Ihre Freigabe.

Sie können Modelle zur Laufzeit mit dem Tool switch_model wechseln. Der Wechsel ist auf dasselbe Backend beschränkt, sodass Beweise niemals stillschweigend an einen anderen Anbieter gesendet werden als den von Ihnen gewählten.

Nachverfolgung des LLM-Denkprozesses

Eye ist so gebaut, dass Sie sehen — und später beweisen — können, wie es zu einer Schlussfolgerung gelangt. Während Eye arbeitet, streamt es in Echtzeit strukturierte ThinkingStep-Aktualisierungen an die Benutzeroberfläche; jede enthält eine step_id, type, ein menschenlesbares label, einen status (active → done, oder error) und optionale tool/params/detail.

Eine typische Abfrage verläuft als thinking → rag → thinking → tool_call → synthesis, und jeder Fall speichert On-Disk-Trace-Artefakte, die Sie danach untersuchen können:

Tool-Ausführung

Eye ist toolgesteuert: Das Modell berührt Beweise nie direkt. Es gibt Tool-Aufrufe aus, und Eye führt sie gegen die Datenbanken des Falls aus und gibt die Ergebnisse zurück — sodass jede Aktion explizit, protokolliert und reproduzierbar ist. Die Werkzeuge sind in configs/llm_config.json definiert und werden über eye/services/context_manager.py ausgeführt.

Ermittlungs-Tools — Beweise lesen und analysieren:

Berichts-Tools erstellen den Living Report Workspace: 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 und export_report (Export erfordert menschliche Genehmigung).

Authoring-Tools (kontrolliert — siehe Erstellen von Korrelations-Wings und semantischen Mappings): correlation_create_wing, correlation_edit_wing, correlation_create_semantic_mapping, correlation_edit_semantic_mapping. Tool-Aufrufe werden in das übersetzt, was das aktive Backend erwartet — natives Function-Calling für Cloud-APIs und lokale Server oder ein XML-<tool_call>-Wrapper für CLI-Agenten.

Erstellen von Korrelations-Wings und semantischen Mappings

Eye fragt die Correlation Engine nicht nur ab — es kann helfen, sie zu erweitern. Wenn Eye ein wiederkehrendes artefaktübergreifendes Muster erkennt, kann es neue Wings (Korrelationsregeln) und semantische Mappings (Übersetzungen von technisch zu menschlich) vorschlagen. Dies ist kontrollierte Autorenschaft: Eye schlägt vor, der Analyst überprüft das gespeicherte Artefakt, und jede Änderung ist begründet und evidenzgestützt.

Ein Wing verbindet Feathers innerhalb eines Zeitfensters und einer Mindestübereinstimmungsschwelle, um eine Behauptung zu belegen:

Ein semantisches Mapping übersetzt einen rohen technischen Wert in eine menschenlesbare Bedeutung (z. B. EventID 4624 → „Successful Logon“). Es gibt zwei Varianten: ein einfaches mapping (einzelner Wert/Regex → semantischer Wert) oder eine rule mit mehreren Bedingungen (Bedingungen verknüpft mit UND/ODER). Beide unterstützen category, severity, confidence und scope, und beide erfordern reason + related_evidence.

Governance — Regeln auf der Schreibseite, die das GEP stützen:

• Reason-Required (stützt GEP-9 + GEP-2): Jedes Erstellen und Bearbeiten muss eine forensische reason enthalten.
• Evidence-Link (stützt GEP-2): Jedes Erstellen muss mindestens eine database:table:rowid-Referenz anführen.
• Eye-Stempel / bei anderen schreibgeschützt (stützt GEP-7 + GEP-9): Eye stempelt seine Autorenschaft + Begründung + Bearbeitungshistorie und darf nur das bearbeiten, was Eye erstellt hat — integrierte und von Menschen erstellte Regeln bleiben schreibgeschützt.

Selbstheilender Kontext

Lange Untersuchungen können das Kontextfenster eines Modells übersteigen — insbesondere bei kleineren Offline-Modellen. Anstatt abzustürzen oder Beweise stillschweigend zu verwerfen, kompaktiert Eye seinen eigenen Kontext automatisch vor jedem Modellaufruf (innerhalb seines geschützten Generierungspfads, vollständig auditiert).

Vor jedem Aufruf misst Eye die gesamte Payload und reserviert Platz für die Antwort (10 % des Fensters, mindestens 512 Token, nie mehr als die Hälfte). Wenn es immer noch nicht passt, heilt es in zwei geordneten Durchläufen, ohne jemals geschützte Nachrichten anzufassen (angeheftet, automatisch erkannte Beweise oder ein Tool-Ergebnis):

1. Summarize-Durchlauf (einmal) — nicht geschützter Verlauf wird zu einer Zusammenfassung komprimiert, protokolliert als SUMMARIZED.
2. Drop-Durchlauf — die älteste nicht geschützte Nachricht wird nach und nach entfernt, bis es passt, protokolliert als TRUNCATED.

Wenn der nicht reduzierbare Beweiskern (angeheftete + Tool-Ergebnisse + die aktuelle Frage) immer noch überläuft, verweigert Eye die Fortsetzung, anstatt Beweise abzuschneiden (REFUSED_OVERFLOW) und bittet Sie, die Abfrage einzugrenzen oder analyze_large_dataset zu verwenden. Was schließlich an das Modell geht, ist exakt die Payload, die für die Chain of Custody versiegelt wird.

🗺️ Narrative Map — Das persistente Fallgedächtnis des Eye

Das Eye ist zustandslos zwischen den Turns — die Narrative Map ist also der Ort, an dem „was wir wissen und was wir geschlossen haben“ für einen Fall lebt. Sie ist das persistente, prüfbare, manipulationssichere Arbeitsgedächtnis des Eye, und ihre Inhalte werden bei jedem Turn in den Prompt des Eye injiziert (die Map ist buchstäblich das Gedächtnis).

• 🧭 Verdict → Narrative → Evidence. Eine strenge Hierarchie: ein Fall-Verdict, die Narratives darunter (Behauptungen, jeweils mit einem Status — proven · open · negative · needs · absolute), und die artefaktgestützten Evidence darunter.
• 🪟 Ein eigenes Fenster. Öffnet sich über die Schaltfläche „Narrative Map“ im Eye-Chatfenster, sodass Sie Chat, den Living Report und das Fallgedächtnis nebeneinander betrachten können; es aktualisiert sich live, wenn sich Dinge ändern.
• ↔️ Bidirektional — ein Gedächtnis, das Sie steuern. Sowohl die Bearbeitungen des Eye als auch Ihre eigenen Notizen fließen durch einen einzigen GEP-validierten Commit und werden in ein hash-verkettetes Audit-Log (narrative_map_audit.jsonl) versiegelt. Sie können dessen Behauptungen und Beweise hinzufügen, bearbeiten und entfernen und damit direkt prägen, wie das Eye den Fall versteht und interpretiert.
• 🚫 Behauptet nie Unbelegtes. Eine Eye-Narrative darf open ohne Beweise bleiben, während untersucht wird, aber sie kann ohne Beweise niemals proven sein; ein Thema, das Eye geprüft hat, aber leer vorfand, wird automatisch zu negative — denn eine dokumentierte Abwesenheit ist selbst ein Befund.

Wie Compliance funktioniert

Compliance ist kein oben aufgesetztes Feature — sie wird in der Pipeline erzwungen.

• 🔗 Chain of Custody (Evidence Seal). Jede Payload, die Eye an ein LLM sendet, wird versiegelt: der SHA-256 der exakten Bytes, die Tokenanzahl, das Modell + sein Kontextlimit und die Herkunft jeder Beweiszeile (database:table:rowid, plus berechnete Offsets für MFT-Datensätze). Siegel sind append-only und hash-verkettet mit <case>/EYE_Logs/eye_payload_seal.jsonl — ein einziger veränderter oder entfernter Datensatz bricht die Kette, sodass das Log mathematisch beweist, welche Bytes das Modell analysiert hat.
• 🚫 Kein stilles Abschneiden. Wenn der Kontext knapp wird, heilt sich Eye selbst und verteilt Budgets in strenger Reihenfolge neu: Priorität 1 (unbeweglich): Rohe Beweise + Systemprompt › Priorität 2 (opferbar): beiläufige Konversation › Priorität 3 (flexibel): RAG-Kontext. Wenn der Beweiskern immer noch nicht passt, verweigert Eye, anstatt Beweise stillschweigend zu verwerfen.
• 🧾 Prüfpfad für Abschneidungen. Jede Kontextentscheidung wird in <case>/EYE_Logs/truncation_audit.log protokolliert (SUMMARIZED, TRUNCATED, PRESERVED, PINNED, UNPINNED, BUDGET_REDUCED), jede mit einem Hash. Erkannte Beweise werden oberhalb einer Konfidenzschwelle automatisch angeheftet; Sie können Nachrichten auch manuell anheften.

📖 Vollständige Eye-Architektur: eye/README.md.

📖 Eye-Describe — Byte-Level-Wissensbasis für Artefakte

🔗 Erkunden Sie Eye-Describe → crow-eye.com/eye-describe

Historisch gesehen tappten Ermittler in die Falle, ihren forensischen Werkzeugen zu vertrauen, ohne zu verstehen, wie sich die zugrunde liegenden Artefakte verhalten oder wie das Werkzeug sie geparst hat. Das heutige Risiko besteht einfach darin, „das Werkzeug“ durch „die KI“ zu ersetzen. Eine KI kann einen Datensatz mit perfekter technischer Genauigkeit parsen und ihn dennoch in den falschen Kontext stellen — wodurch sich die gesamte Bedeutung des Beweismittels ändert.

Eye-Describe existiert, damit weder der Mensch noch das Modell raten müssen. Es ist eine interaktive Referenz auf Byte-Ebene für die rohen Binärstrukturen von Windows-Artefakten und erfüllt gleichzeitig zwei Rollen:

Indem Crow-Eye die KI-Schicht an dokumentiertem Artefaktverhalten verankert, bittet es Sie nicht, einem Modell zu vertrauen — es zwingt das Modell, die rohe Forensik zu respektieren.

Ersetzen Sie Werkzeugvertrauen nicht durch KI-Vertrauen. Verstehen Sie die Daten.

🧪 Qualität & Validierung

Forensische Werkzeuge sind nur nützlich, wenn ihre Ausgabe verteidigt werden kann. Die Korrektheitsarbeit von Crow-Eye ist bewusst sichtbar:

• Regressions-Suiten. Die Correlation Engine ist durch eine pytest-Suite abgesichert, die Zeitstempelparsing, Identitätsnormalisierung, Multi-Zeitstempel-Fan-out, den Writer-Vertrag, Eye-Authoring (schreibseitige GEP-Governance) und die Standardfelder-Registry abdeckt. Die UBA-Engine wird mit einer eigenen Suite ausgeliefert, einschließlich eines End-to-End-Laufs gegen einen echten Fall.
• Validierungs-Harness. Ein ganzheitlicher Harness testet alle 7 Standard-Wings gegen beide Engines an einem echten Windows-Fall mit ~700K-Datensätzen.
• Veröffentlichte Fehlerhistorie. Genauigkeitsregressionen und ihre gemessenen Auswirkungen sind offen in RELEASE_NOTES.md dokumentiert — einschließlich Fällen, in denen eine Korrektur die erfassten Datensätze um Größenordnungen verändert hat. Zu wissen, was und wann falsch war, ist Teil dessen, was ein Ergebnis verteidigbar macht.
• Überprüfbare Beweisbuchhaltung. Jeder Datensatz landet entweder in einem Treffer oder in einem benannten Drop-Bucket, und das Drop-Ledger pro Fenster macht „keine übrig gebliebenen Beweise“ zu etwas, das Sie aus dem Log prüfen können, statt es zu glauben.
• Manipulationssichere Logs. verify_chain() durchläuft erneut das Audit-Log der Narrative Map und die Evidence-Seal-Kette, um Modifikationen zu erkennen — auch an menschenlesbaren Feldern.

🔬 ForschungsplattformCrow-Eye ist mehr als nur Software – es ist eine offene Forschungsplattform, die das gesamte Gebiet der Windows-Forensik beschleunigt. Das Projekt konzentriert sich auf:

• Veröffentlichung detaillierter Dokumentation zu internen Artefaktstrukturen.
• Teilen von Korrelationslogik und Methoden.
• Ermöglichen von Peer-Review, Transparenz und akademischer Zusammenarbeit.
• Beitrag zum kollektiven Wissen der Forensik-Community.

🛠️ Technische Hinweise

• Für das Registry-Parsing sind vollständige Registry-Hive-Dateien erforderlich.
• Einige Artefakte erfordern eine spezielle Behandlung aufgrund der Windows-Dateisperrmechanismen (siehe Benutzerdefinierte Registry / gesperrte Dateien).
• Das Parsing von LNK- und Jump-Listen wird von Crow-Eyes eigenem dedizierten Parser übernommen.

📸 Screenshots

Eine Auswahl der Benutzeroberfläche und Analyseansichten von Crow-Eye.

🎥 Demo-Video:

🚧 Roadmap

Geplante und laufende Arbeiten (siehe RELEASE_NOTES.md für veröffentlichte Änderungen):

• 📊 Erweiterte GUI-Ansichten & Berichte – umfangreichere Visualisierung und Berichterstattung.
• 🔄 Erweiterter Suchdialog – erweiterte Filterung mit Unterstützung natürlicher Sprache.
• 🎯 Erweitertes semantisches Mapping – umfassende Feldzuordnung über alle Artefakttypen hinweg.
• 📈 Erweiterte Korrelationsbewertung – verfeinerte, erklärbare Konfidenzbewertung.
• ⚡ Parallele Korrelation – Prozesspool-Verteilung, standardmäßig aktiviert für große Arbeitslasten.

Hast du eine Idee oder möchtest ein Artefakt hinzufügen? Erstelle ein Issue oder siehe Mitwirken.

📚 Dokumentation

• TECHNICAL_DOCUMENTATION.md – Architektur, Komponenten und Entwicklungsleitfaden.
• RELEASE_NOTES.md – Neuerungen in jeder Version (UBA, Narrative Map, Cloud-Eye-Backends, Härtung des Fallmanagements, …).
• Correlation-Engine-Dokumentation – Überblick, Engine, Feathers, Wings, Pipelines.
• Timeline-Architektur – Interna des Timeline-Moduls.
• Eye-Architektur und GEP-Standard – der KI-Assistent und sein zugrunde liegendes Protokoll.

🤝 Mitwirken

Crow-Eye ist als offene Forschungsplattform aufgebaut, und Beiträge sind willkommen – neue Parser, Korrelationsregeln, Dokumentation und Artefaktforschung.

• Allgemeine Beiträge: CONTRIBUTING.md
• Correlation Engine (Schwerpunktbereich): correlation_engine/CONTRIBUTING.md
• Kontakt: [email protected] · oder erstelle ein Issue / einen Pull Request.

🌐 Website & Community

• 🌍 Offizielle Website: crow-eye.com – Ressourcen, Dokumentation und Downloads.
• 💬 Discord: Tritt dem Crow-Eye-Discord bei – direkte Hilfe, Artefaktforschung und Versionsankündigungen.

📄 Lizenz

Crow-Eye wird unter der GNU General Public License v3.0 (GPL-3.0) veröffentlicht. Es ist unter den Bedingungen dieser Lizenz frei nutzbar, studierbar, teilbar und modifizierbar.

📝 Zitieren von Crow-Eye

Wenn du Crow-Eye in akademischen Arbeiten, veröffentlichter Forschung oder einem Fallbericht verwendest, zitiere es bitte:```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} }

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

Für Zitate zur Methodik ist das Ghassan-Elsman-Protokoll separat in [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) dokumentiert.

## 💖 Support

Crow-Eye ist kostenlos und Open Source, entwickelt und gepflegt von einer Person. Wenn es deine Arbeit unterstützt, erwäge bitte ein Sponsoring — es finanziert direkt neue Parser und Forschung: **[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**.

## Credits

Erstellt und gepflegt von **Ghassan Elsman**.