Crow-Eye — Motor de análisis forense para Windows

Una máquina del tiempo forense para Windows.
Crow-Eye no solo detecta — reconstruye lo que realmente ocurrió en la línea temporal, desde la adquisición hasta un veredicto trazable hasta sus registros de origen.

Tabla de Contenidos

• Descripción general
• ✨ Aspectos destacados
• 👥 Para quién es Crow-Eye
• 🧭 Subsistemas de un vistazo
• 🏗️ Arquitectura
• 📥 Descarga e instalación
• 🚀 Inicio rápido
• 📂 Artefactos compatibles
• 🔧 Modos de análisis
  • 📎 Importar evidencia (datos de terceros)
• 🧠 Análisis de comportamiento de usuarios (UBA)
• 🧩 Motor de correlación
• 👁️ Eye — El asistente de IA forense
• 📖 Eye-Describe — Base de conocimiento de artefactos a nivel de bytes
• 🧪 Calidad y validación
• 🔬 Plataforma de investigación
• 🛠️ Notas técnicas
• 📸 Capturas de pantalla
• 🚧 Hoja de ruta
• 📚 Documentación
• 🤝 Contribuciones
• 🌐 Sitio web y comunidad
• 📄 Licencia
• 📝 Cómo citar Crow-Eye
• 💖 Soporte
• Créditos

Descripción general

Crow-Eye es un motor forense para Windows de código abierto (GPL-3.0) que unifica adquisición, análisis, verificación, inteligencia e IA. La mayoría de las herramientas de seguridad preguntan "¿es esto malo?" y descartan todo lo que parece legítimo. Crow-Eye plantea una pregunta distinta: "¿qué ocurrió?". Correlaciona toda la actividad —sospechosa o no— y reconstruye la secuencia real de eventos en un sistema, de modo que la verdad de una investigación se reconstruye a partir de la evidencia en lugar de adivinarse a partir de alertas.

Ese diseño centrado en la reconstrucción es exactamente lo que se necesita para cazar amenazas APT y de estados-nación: los adversarios sofisticados viven dentro de herramientas legítimas (powershell.exe, PsExec, certutil) y en la secuencia de acciones —invisibles para las herramientas que descartan todo lo que parece normal—. Como Crow-Eye nunca descarta nada y razona sobre artefactos de ejecución (que sobreviven a la manipulación de registros y a las técnicas anti-forenses), el ataque no puede ocultarse. El mismo motor sigue siendo accesible para el trabajo diario de DFIR y para no expertos que simplemente quieren saber qué ocurrió en un ordenador.

• 🕰️ Reconstruir, no solo detectar — reconstruye la línea temporal de lo que realmente ocurrió.
• 🖥️ Multiplataforma — análisis completo en vivo y sin conexión en Windows; análisis sin conexión y análisis de imágenes forenses en Linux (los analizadores en vivo son solo para Windows).
• 🔒 Privado por diseño — 0 ms de datos enviados fuera del dispositivo; el asistente de IA Eye puede funcionar completamente desconectado (air-gapped).
• 🧾 Apto para uso judicial — la evidencia se sella criptográficamente y cada paso es auditable.
• 📦 Versión actual: 0.12.6 · Motor de correlación: 1.7.0 · Licencia: GPL-3.0.

✨ Aspectos destacados

• Reconstrucción frente a detección. Correlaciona cada artefacto en una única historia navegable por entidad, en lugar de un montón de alertas.
• Integrado de principio a fin — adquisición → correlación → línea temporal → analítica de comportamiento → IA → memoria de caso sellada: un pipeline completo que ninguna herramienta actual cubre.
• Profundo en artefactos, no superficial en registros. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists y más sobreviven a la limpieza de registros y a los trucos de "living-off-the-land" que dejan ciegas a las herramientas basadas solo en registros.
• El asistente de IA Eye — investigación forense en lenguaje natural con una cadena de custodia auditable y a prueba de manipulaciones, ejecutable en la nube, en un servidor privado o totalmente sin conexión.
• Análisis de comportamiento de usuarios (UBA) — convierte los artefactos en crudo en una historia de actividad en lenguaje sencillo, legible para RR.HH. y examinadores.
• Gratuito y de código abierto (GPL-3.0) — auditable por cualquiera, con un esfuerzo activo de investigación y documentación.

👥 Para quién es Crow-Eye

Crow-Eye se utiliza en flujos de trabajo muy diferentes. Cada uno entra al motor por una puerta distinta:

Cualquier recopilador sirve. Crow-Eye no requiere su propia herramienta de adquisición. Apunte el Importador sin conexión a una carpeta de artefactos en crudo producidos por Velociraptor, KAPE, un paquete de recopilación de EDR o cualquier otro recopilador: indexa los artefactos compatibles y ejecuta los analizadores sin conexión sobre ellos. Por separado, la salida de Plaso, Autopsy, Volatility o cualquier otra herramienta puede importarse como CSV, JSON o SQLite mediante Importar evidencia y correlacionarse junto con los artefactos nativos.

🧭 Subsistemas de un vistazo

Crow-Eye está construido como un bucle integrado: cada etapa alimenta a la siguiente, desde el disco en bruto hasta un veredicto defendible.

🏗️ Arquitectura

Crow-Eye es un pipeline integrado, no una bolsa de analizadores. La evidencia fluye en una sola dirección y cada etapa mantiene su vínculo con el registro de origen.```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

*Fuente de evidencia → Ingesta → Bases de datos del caso → Análisis → Capa de IA → Informe*


**Cómo leerlo:**

| Etapa | Qué importa |
|---|---|
| ① → ② | **Cuatro puertas independientes hacia un caso.** Nunca necesitas el recolector propio de Crow-Eye — una carpeta de Velociraptor, KAPE o un paquete de EDR pasa por el Importador Offline, y CSV/JSON/SQLite de terceros pasa por Import Evidence. |
| ② → ③ | Todo converge en un solo lugar: **las bases de datos del caso**. Los artefactos parseados van a `Target_Artifacts/`; la evidencia importada de terceros va a `Imported_Evidence/` y se auto-descubre. |
| ③ → ④ | **Las tres rutas de análisis son independientes entre sí.** La Línea de Tiempo y la UBA leen las bases de datos del caso directamente — ninguna requiere una ejecución de correlación. El Motor de Correlación es una capa *adicional*, no un prerrequisito. |
| ③ → ④ | **El Enlace Dinámico se sitúa junto a la Línea de Tiempo y la UBA** — un cuarto lector independiente de las bases de datos del caso (no tiene nada que ver con la visualización de la Línea de Tiempo). Reúne asignaciones de identidad (SID → usuario, MAC → red, hash/GUID → aplicación) en una `Crow_Intelligence.db` por caso, y luego superpone ese contexto **en línea en las tablas de datos de artefactos** mediante `ATTACH` + `LEFT JOIN` no destructivos. Cambia cómo se *leen* los registros, nunca la evidencia. |
| ④ → ⑤ | The Eye consulta las bases de datos del caso directamente y puede obtener resultados de correlación **bajo demanda**. Nunca toca la evidencia en sí — emite llamadas a herramientas que Crow-Eye ejecuta y registra. |
| ⑤ → Informe | El **Informe Vivo lo construye exclusivamente The Eye**, a través de sus herramientas `report_*`. La Línea de Tiempo y la UBA son superficies de análisis — no escriben en el informe. Los hallazgos a nivel de caso pueden exportarse por separado mediante [Search & Export](#-search--export). |
| ⑤ ↔ | El **Mapa Narrativo es bidireccional**: The Eye escribe en él, tú escribes en él, y su contenido se inyecta en el prompt de The Eye en cada turno. Es la memoria, y puedes comandarlo. |
| ⑤ ⟳ | La página de **Cumplimiento audita a The Eye.** Cada llamada a herramienta que hace The Eye está anclada a la cadena de hash **EvidenceSeal**; la página muestra en vivo el estado **GEP** por regla (10 principios) verificado desde esa cadena y `EYE_Logs/`, exportable como `audit_trail.json`. |

**Etapas independientes.** La Línea de Tiempo y la UBA leen las bases de datos de artefactos del caso **directamente** — ninguna requiere una ejecución de correlación, y la Línea de Tiempo no depende del Motor de Correlación (aplica su propio agrupamiento temporal ligero). La correlación es una capa de análisis adicional cuyos resultados The Eye puede consultar.

**Solo lectura por diseño.** El parseo escribe en la base de datos del caso; cada etapa posterior (UBA, la Línea de Tiempo, los visores de correlación, The Eye) abre esas bases de datos **en modo solo lectura**. La evidencia original nunca se modifica — el [Enlace Dinámico](#-analysis-modes) lee las bases de datos del caso para construir una `Crow_Intelligence.db` por caso con asignaciones de identidad y enriquece las tablas de datos de artefactos en línea mediante consultas `ATTACH` + `LEFT JOIN` no destructivas en lugar de reescribir filas.

**Gobernado por diseño.** Cada acción que toma The Eye está anclada a la cadena de hash **EvidenceSeal** a prueba de manipulación, y la página de **Cumplimiento** verifica continuamente a The Eye contra el [Protocolo Ghassan Elsman (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) — estado en vivo por regla, exportable a `EYE_Logs/audit_trail.json`.

## 📥 Descarga e Instalación

> **Recomendado:** obtén la compilación empaquetada para Windows (**instalador MSI / EXE**) desde el sitio web oficial — sin configuración de Python, funciona de inmediato.

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

La **compilación MSI/EXE instalada es la forma recomendada de ejecutar Crow-Eye**, y es nuestra **máxima prioridad para actualizaciones**:

- 🛡️ **Correcciones más rápidas.** Cuando se encuentra un problema o se reporta un error, publicamos un EXE actualizado **lo antes posible** — la compilación empaquetada es donde las correcciones llegan primero.
- 🔄 **Actualización automática integrada.** En la aplicación instalada, abre **Settings → Updates** para **buscar actualizaciones e instalarlas automáticamente** — sin reinstalación manual.
- 📦 **Cero configuración.** No se requiere Python, Node ni instalación de dependencias.

> ¿Prefieres ejecutar desde el código fuente? Consulta **[Quick Start](#-quick-start)** a continuación. La compilación desde el código fuente está pensada para contribuidores y **no incluye el actualizador automático** — usa el MSI/EXE para actualizaciones automáticas.

## 🚀 Inicio Rápido

### Opción A — Compilación instalada (recomendada)
Descarga el **MSI/EXE** desde [crow-eye.com/download](https://crow-eye.com/download), instala y lanza **Crow-Eye** como Administrador. Crea un caso y comienza a analizar.

### Opción B — Ejecutar desde el código fuente (desarrolladores)

> Para contribuidores y usuarios avanzados. Esta vía **no incluye el actualizador automático** — usa el MSI/EXE para actualizaciones automáticas.

**Requisitos** (se instalan automáticamente en el primer arranque):
- Python 3.12.4
- **Node.js y npm** — necesarios para la **Visualización de Línea de Tiempo**
- Paquetes clave: PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**Hardware recomendado**

| | Mínimo | Recomendado para casos grandes |
|---|---|---|
| **RAM** | 8 GB | 16 GB+ (conjuntos MFT/USN de millones de registros) |
| **Disco** | 5 GB libres | Espacio libre ≥ 2× el tamaño de la evidencia a parsear |
| **CPU** | 4 núcleos | 8+ núcleos |
| **SO** | Windows 10/11 (completo) · Linux (análisis offline y de imágenes) | — |

> La correlación transmite en memoria constante para conjuntos de datos muy grandes, por lo que la RAM rara vez es el límite duro — el rendimiento del disco y el espacio libre suelen serlo.

**Lanzamiento** (ejecuta como Administrador para que Crow-Eye pueda acceder a los artefactos del sistema):```bash
python "Crow Eye.py"

Se abre la interfaz principal, se crea un caso y todo el resultado del análisis se organiza bajo el directorio de ese caso para su posterior revisión e informes.

🖥️ Nota multiplataforma: en Linux, los analizadores en vivo se desactivan automáticamente y Crow-Eye funciona en modo offline / imagen forense. La adquisición completa en vivo es solo para Windows.

📂 Artefactos admitidos

Crow-Eye analiza un amplio conjunto de artefactos de ejecución, sistema de archivos y actividad de usuario de Windows, tanto de un sistema en vivo como de fuentes offline (carpetas recopiladas o imágenes forenses).

Jump Lists y LNK son analizados por el analizador LNK / Jump List específicamente diseñado por Crow-Eye — no por un módulo de terceros.

Registro personalizado / archivos bloqueados: Windows bloquea las colmenas de registro en vivo (NTUSER.DAT, SOFTWARE, SYSTEM) durante su funcionamiento. Para un análisis personalizado de un sistema en vivo, arranque desde medios externos (WinPE/Live CD), use herramientas forenses de adquisición o analice una imagen de disco.

Detalles por artefacto

• Jump Lists y LNK — analizados automáticamente desde las ubicaciones estándar del sistema por el analizador dedicado de Crow-Eye (acceso a archivos, rutas de destino, marcas de tiempo y metadatos).
• Registro — analiza automáticamente las colmenas del sistema. Para un análisis personalizado del registro, copie los archivos de colmena a CrowEye/Artifacts Collectors/Target Artifacts (o a la carpeta registry/ de su caso):
  • NTUSER.DAT de C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE de C:\Windows\System32\config\SOFTWARE
  • SYSTEM de C:\Windows\System32\config\SYSTEM
  • Windows bloquea estos archivos durante su funcionamiento: para un sistema en vivo, arranque desde medios externos (WinPE/Live CD), use herramientas forenses de adquisición o analice una imagen de disco.
• Prefetch — analiza C:\Windows\Prefetch, extrayendo el historial de ejecución y los metadatos forenses (incluidas las marcas de tiempo por ejecución).
• Registros de eventos — análisis automático de los registros de Sistema/Seguridad/Aplicación en una base de datos para un análisis exhaustivo.
• ShellBags — revela el historial de acceso a carpetas y los patrones de navegación del usuario.
• Papelera de reciclaje — analiza $RECYCLE.BIN para recuperar nombres de archivos eliminados, rutas originales, horas de eliminación y tamaños (sistemas en vivo e imágenes de disco).
• MFT — analiza la Master File Table para obtener metadatos de archivos, atributos, marcas de tiempo e información de archivos eliminados (NTFS, Windows 7/10/11).
• USN Journal — realiza un seguimiento de los eventos de crear/modificar/eliminar/renombrar archivos con marcas de tiempo e historial completo de nombres, para la reconstrucción de líneas de tiempo.
• SRUM — visualiza el uso de recursos de las aplicaciones (barras de duración para el tiempo en primer/segundo plano) y la actividad de red por aplicación.
• Analizador de forensia de almacenamiento — vista de árbol completa de cada disco físico y sus particiones; tipos de partición codificados por colores (EFI, Linux, Recovery, Hidden/swap, …); advertencias para USB de arranque, raíces Linux ocultas e Intel Rapid Start; respaldo de escaneo mágico de sectores en bruto.

🔧 Modos de análisis

🦅 Adquisición con Crow-Claw

Crow-Claw es el motor de adquisición especializado de Crow-Eye para recopilar y preservar artefactos de sistemas en vivo o imágenes montadas.

• Recopilación selectiva — elija categorías de artefactos específicas (Registro, Registros de eventos, Sistema de archivos) o recopile todo.
• Escaneo profundo — recorre directorios y subdirectorios para encontrar rastros forenses.
• Preservación segura — los artefactos se depositan en un directorio de caso estructurado que mantiene la integridad forense.

🔍 Análisis offline (Importador offline)

Analice artefactos recopilados de cualquier fuente sin una conexión en vivo con el objetivo — tres operaciones claras:

• SCAN (detección) — recorre la fuente e indexa cada artefacto admitido por patrón de nombre de archivo y extensión (rápido, de solo lectura; no se lee el contenido de los archivos ni se realiza comprobación de magic bytes en esta etapa). No se mueve nada.
• COLLECT (adquisición) — copia físicamente los archivos identificados a la carpeta live_acquisition del caso, organizados por tipo.
• PARSE (granular) — revise los elementos identificados por tipo (AMCACHE, EVTX, PREFETCH, …) y analice los archivos seleccionados (o todos) en la base de datos forense.

El análisis es gestionado por los analizadores offline dedicados de Crow-Eye — la misma lógica de artefactos que en el modo en vivo, operando sobre archivos recopilados: Prefetch, Registro, MFT, USN (además del correlacionador MFT/USN), AmCache, ShimCache, SRUM, Registros de eventos, LNK/JumpLists y Papelera de reciclaje.

📎 Importar evidencia (datos de terceros)

Más allá de los artefactos sin procesar, Crow-Eye puede llevar resultados forenses de terceros directamente a un caso — Plaso, Autopsy, Volatility o cualquier exportación personalizada — y hacerlos utilizables por el Eye y la Timeline sin requerir antes una ejecución de correlación.

Dado que el gestor de la base de datos del caso auto-detecta cualquier .db bajo el árbol del caso, la evidencia importada queda inmediatamente disponible para:

• The Eye — consultable en lenguaje natural junto con los artefactos nativos (el manifiesto de esquema se actualiza al importar).
• The Interactive Timeline — se sirve como el tipo de artefacto imported, con filtrado funcional por ventanas de tiempo y límites temporales.
• The Correlation Engine — utilizable como Feather para la correlación entre herramientas contra artefactos nativos.

El importador usa solo la biblioteca estándar (sqlite3 / csv / json) y se ejecuta en un trabajador en segundo plano, por lo que las importaciones grandes no bloquean la interfaz.

⚡ Análisis en vivo

Analiza artefactos directamente desde el sistema Windows en ejecución, extrayéndolos automáticamente de sus ubicaciones estándar para un análisis forense en tiempo real.

🗂️ Gestión de casos

Toda investigación es un caso: un directorio autocontenido que organiza las bases de datos de artefactos y el resultado del análisis. Crow-Eye realiza un seguimiento de los casos recientes (con favoritos, etiquetas y estado), valida un caso al abrirlo, escribe la configuración de forma atómica (a prueba de fallos) y admite la importación/exportación de configuración de casos y plantillas con asignaciones semánticas ya preparadas.

🕰️ Visualización interactiva de Timeline

Correlacione eventos entre artefactos en una cuadrícula temporal unificada, con vistas de mapa de calor, semana y día: una historia hilada por identidades y trazable ante un tribunal, en lugar de una super-timeline plana.

La Timeline lee directamente las bases de datos de artefactos analizados del caso y es independiente del Motor de correlación — no necesita crear feathers, redactar wings ni ejecutar un pipeline para usarla. Aplica su propio agrupamiento temporal ligero (correlación por marca de tiempo exacta y por ventanas de tiempo, agrupación por aplicación, ruta o usuario) para relacionar eventos en la cuadrícula. La evidencia incorporada mediante Importar evidencia también aparece en la timeline como el tipo de artefacto imported, con filtrado funcional por ventanas de tiempo y límites temporales.

🔎 Búsqueda y exportación

Búsqueda de texto completo en la base de datos del caso, además de exportación a CSV (hojas de cálculo), JSON (integración con otras herramientas) y informes HTML detallados (expedientes completos que consolidan todos los artefactos vinculados a un término de búsqueda).

🔗 Vinculación dinámica

Traduzca identificadores técnicos en bruto — SIDs, direcciones MAC, hashes — a contexto legible sobre la marcha. La vinculación dinámica enriquece la vista mediante consultas SQL ATTACH no destructivas, por lo que la evidencia original nunca se modifica, y puede ingerir fuentes masivas de IOC de amenazas para marcar en línea los indicadores conocidos como maliciosos.

🧠 Análisis de comportamiento de usuario (UBA)

Convierta los artefactos en bruto en una historia de actividad en lenguaje sencillo — un relato legible por directivos/RR. HH. de lo que un usuario y sus aplicaciones hicieron realmente, con cada afirmación trazable hasta la evidencia fuente exacta.

User Behavior Analytics (UBA) lee las bases de datos de artefactos analizados en la carpeta Target_Artifacts/ de su caso (estrictamente de solo lectura) y las reproduce a través de un conjunto de reglas declarativas para producir una Activity Story clara y cronológica. Ábrala desde el botón de la barra de herramientas "User Behavior" o con Ctrl+Shift+B (debe haber un caso cargado).

• 🧩 40 detecciones de comportamiento declarativas (uba/config/behavior_rules.json) — ajustables sin código — cada una clasificada por severidad: rutinaria · notable · sospechosa · crítica.
• 🕵️ Detecta el comportamiento que importa: inicio/cierre de sesión / desbloqueo, lanzamiento · ejecución · instalación de programas, apertura / eliminación / copia inferida de archivos, conexión de dispositivos USB, acceso a recursos compartidos de red, persistencia e inicio automático, uso de credenciales explícitas (runas), cambios de cuentas y grupos, cambios de servicios, manipulación del reloj del sistema (sospechoso) y borrado de registros de eventos (crítico).
• 🗺️ Tres vistas — un feed de Activity Story, un mapa de calor Activity Map (día × hora) y un informe de transparencia "What we can see" que etiqueta cada detección como Working / Limited / No data / By design para este caso.
• 🔗 Toda actividad está respaldada por evidencia. Haga clic en cualquier elemento para abrir el registro de respaldo exacto (database : table : rowid) — nada se afirma sin una fuente.
• 👤 Atribución honesta. Los actores se resuelven como Usuario / Aplicación / Sistema (o se dejan vacíos) — UBA nunca adivina quién hizo qué.

Cobertura de detección

Las 40 detecciones abarcan cuatro clases de severidad y toda la amplitud del conjunto de artefactos analizados:

Filtros: búsqueda de texto libre · usuario/actor (incluidos "Unattributed" y un conmutador de sesión iniciada) · clase de comportamiento (usuario / aplicación / sistema) · severidad · aplicación (multiselección con búsqueda en más de 200 programas) · rango de fecha y hora con ajustes rápidos (todo el tiempo / primer día / último día / última hora de actividad).

Fuentes de datos: Security, System y Application Event Logs · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · Recycle Bin · SRUM (aplicación, red, conectividad) · colmenas del registro.

Garantías forenses

• Solo lectura. Las bases de datos fuente se abren en modo de solo lectura; el análisis nunca toca la evidencia.
• Procedencia completa. Cada evento lleva database → table → rowid y abre las filas fuente reales bajo demanda.
• La atribución nunca adivina. Un evento se atribuye a un Usuario, una Aplicación, el Sistema — o se deja vacío. Las sesiones de inicio de sesión interactivas se usan solo como etiquetas de contexto ("durante la sesión de <user>"), nunca para atribuir una acción.
• Redacción honesta. El redactado distingue la interacción deliberada (UserAssist, SRUM en primer plano) de los artefactos que una aplicación también puede generar (ShellBags, LNK, JumpLists), con advertencias explícitas mostradas en la tarjeta.
• La ausencia se declara, no se implica. El informe What we can see etiqueta cada detección de este caso específico, de modo que los datos faltantes nunca se interpretan en silencio como "no ocurrió nada".

UBA es correlación y clasificación de comportamiento basadas en reglas, no puntuación estadística/ML de anomalías — cada hallazgo se asigna a una regla explícita y auditable. Consulte RELEASE_NOTES.md para ver el catálogo completo de detecciones.

🧩 Motor de correlación

Correlation Engine v1.7.0 — el núcleo de reconstrucción. Consulte RELEASE_NOTES.md para ver el historial de versiones.

El Crow-Eye Correlation Engine es un sistema forense de correlación de grado de producción. Ingiere artefactos de Windows de cualquier fuente, los normaliza y saca a la luz las relaciones temporales y de identidad que convierten registros aislados en una narrativa coherente de qué ocurrió en un sistema, cuándo y quién estuvo implicado. Funciona de forma inmediata con reglas de correlación integradas (Wings) para las preguntas de investigación más comunes, permite a los analistas crear reglas personalizadas sin tocar código, y remite el significado a reglas redactables y al investigador — nunca a una puntuación de caja negra.

🎥 Guía de usuario

Importación universal de datos: El Correlation Engine puede tomar la salida de cualquier herramienta forense en formato CSV, JSON o SQLite y convertirla en una base de datos Feather. Esto significa que puede correlacionar datos de herramientas de terceros (Plaso, Autopsy, Volatility, etc.) con los artefactos nativos de Crow-Eye, creando un análisis de correlación unificado en todas sus fuentes de datos forenses.

🎯 Precisión e integridad de la evidencia

Una pasada de precisión enfocada, validada de extremo a extremo contra un caso real de Windows de ~700 000 registros, superpuesta a trabajos de fiabilidad anteriores. Cada corrección aquí está asegurada por la suite de regresión pytest y verificada por un banco de pruebas de validación holístico que ejercita las 7 wings predeterminadas contra ambos motores.

El motor de identidad captura toda la evidencia

• Corregido: el motor de identidad solo iteraba la PRIMERA fila de cada feather cuando había un filtro de tiempo activo (una comparación entre datetime con zona horaria y naive lanzaba TypeError y abortaba el bucle por fila). Los registros vistos pasaron de 3,558 → 745,615 en el caso de validación.
• Corregido: los registros de log colapsaban cada evento a su PROVEEDOR de evento como identidad (los 33,855 registros de SecurityLogs compartían una única identidad). El mapeo por artefacto ahora prioriza las entidades reales por fila (User, ComputerName, NewProcessName, TargetUserName) antes que los metadatos de canal/proveedor.
• Corregido: el mapeo de campos consciente del artefacto nunca se activaba porque los analizadores no estampan una columna artifact en cada fila. El motor ahora recurre a feather_metadata.artifact_type, de modo que SecurityLogs / SystemLogs / ApplicationLogs usan su prioridad de identidad específica del artefacto.
• Corregido: las cadenas de relleno se convertían en identidades falsas ('N/A', 'Unknown', '-', GUID nulos agrupaban registros no relacionados). El validador ahora rechaza más de 30 variantes de relleno.
• Resultado neto en una ventana de rango completo: el wing Execution Proof presenta 2,856 coincidencias entre feathers (High) en el motor de identidad y 643 coincidencias entre feathers en el motor de tiempo, con 24–118 coincidencias entre feathers por wing en las otras 6 wings.

Se acabó el "todo es Low — algo va mal"

• Corregido: las coincidencias de un solo feather se etiquetaban como High. Las coincidencias con feather_count == 1 ahora reciben confidence_category="Low - single feather", de modo que la vista High se centra en la correlación real entre feathers.
• Corregido: una clave compuesta basada en rutas dividía la misma identidad entre feathers (cada feather almacena las rutas de forma distinta, por lo que chrome tenía más de 10 claves y nunca se correlacionaba). La clave ahora es solo el nombre — la correlación entre feathers vuelve a funcionar.

Detección de suplantación mediante clasificación de rutas — tras formarse una coincidencia, el motor clasifica la ruta de cada registro como TRUSTED (Program Files, System32, WinSxS, las formas BAM/SRUM /device/harddiskvolumeN/..., …) o SUSPICIOUS (Temp, Downloads, Public, AppData\Local\Temp, Recycle Bin, raíces extraíbles, recursos compartidos de red). Una coincidencia que abarca ambas clasificaciones eleva impersonation_alert (≈0.05% de tasa, cada una un candidato real).

Contabilidad honesta de la evidencia — un registro de descartes por ventana con depósitos con nombre (no_identity_field, normalize_failure, below_threshold_skipped, …) más un resumen por pipeline (registros vistos, altos/bajos emitidos, sin identidad, depósitos de descarte, uniones de feathers atemporales). Cada registro o bien aterriza en una coincidencia o en un depósito de descarte con nombre — "no queda evidencia sin contabilizar" es verificable desde el log. low_confidence_review_mode está activado por defecto, por lo que los grupos por debajo del umbral se convierten en coincidencias de baja confianza en lugar de desaparecer en silencio.

Enriquecimiento de identidad de feathers atemporales — los feathers sin marcas de tiempo por fila (AutoStartPrograms, MUICache, SystemServices, TypedPaths) ya no reciben una hora de generación falsa estampada en cada fila; en su lugar, después de formarse las coincidencias temporizadas, el motor une los registros coincidentes de cada feather atemporal por identidad como evidencia complementaria.

Registro de identidades consolidado — config/standard_fields/identities.json es la fuente única de verdad para cada columna que los motores + Eye deben consultar: 98 categorías, 1,146 sinónimos de columna (aplicación/proceso, archivo, hash, usuario, host/dispositivo, red, registro, servicio/tarea, evento, correo, navegador, nube, internals de Windows, certificado, contenedor, objetos del SO). Añadir un nuevo sinónimo de columna es una edición JSON, no un cambio de código.

Correcciones de falsos positivos en el mapeo semántico — la puerta de múltiples indicadores ahora se aplica de verdad (data-exfiltration-pattern requiere ≥2 indicadores); las reglas AND imposibles (4625 AND 4624) se reescriben como OR; las reglas de wiper/herramientas remotas usan expresiones regulares reales en lugar de dispararse con cada entrada de Prefetch; las reglas de actividad de línea base se rebajan de high/critical a info/low (la puntuación ponderada del wing escala las amenazas reales).

✅ Estado de producción

El Correlation Engine está listo para producción y se utiliza activamente en investigaciones (Correlation Engine v1.7.0):- ✅ Motor de Escaneo por Ventana de Tiempo — listo para producción, recomendado para análisis basado en tiempo (O(N log N))

• ✅ Motor Basado en Identidad — listo para producción, recomendado para seguimiento de identidad (O(N log N))
• ✅ Feather Builder / FeatherWriter — importa CSV/JSON/SQLite desde cualquier herramienta; procesamiento por lotes transaccional + metadatos de esquema
• ✅ Sistema Wings y Orquestación de Pipelines — crea/gestiona reglas de correlación y automatiza flujos de trabajo
• ✅ Agrupación de Identidad — unificada en el motor, los visores y la fase semántica
• ✅ Registro de Campos Estándar — fuente central de verdad para sinónimos de campos
• ✅ Expansión Multi-timestamp — cada marca de tiempo de listas JSON se correlaciona
• 🔄 Correlación Paralela — base implementada; perfilado + despacho por pool de procesos a continuación
• 🔄 Mapeo Semántico y Puntuación de Correlación — mejoras activas

Características Principales

• 🔄 Arquitectura de Doble Motor: Elija entre estrategias de correlación de Escaneo por Ventana de Tiempo (O(N log N)) y Basada en Identidad (O(N log N)).
• 📊 Soporte Multi-Artefacto: Correlacione Prefetch, ShimCache, AmCache, Event Logs, archivos LNK, Jumplists, MFT, USN, SRUM, Registry, RecycleBin y más.
• 🔌 Importación Universal: Importe salidas CSV/JSON/SQLite de cualquier herramienta forense y conviértalas a bases de datos Feather.
• 🎯 Agrupación de Identidad Inteligente: Variantes como Chrome.exe/chrome.dll/Chrome.EXE colapsan en un mismo grupo; las versiones y los calificadores de arquitectura se mantienen diferenciados.
• 🕒 Marcas de Tiempo Tolerantes: FILETIME, ISO 8601, Unix epoch (s/ms/μs), YYYYMMDD, barras estadounidenses y cadenas anotadas se analizan correctamente al primer intento.
• 📈 Expansión Multi-Timestamp: Las listas de marcas de tiempo JSON (Prefetch run_times) se expanden para que cada ejecución reciba su propio evento de correlación.
• 🧰 Una Única Fuente de Verdad: Sinónimos de campos en config/standard_fields/*.json; metadatos por tabla en correlation_engine/config/feather_schemas.json — amplíe editando JSON, no código.
• ⚡ Streaming + Seguro para Subprocesos: query_time_range_iter con memoria O(1); cachés de feather protegidos por bloqueos; listo para correlación paralela.
• 🔍 Reglas Flexibles: Defina reglas de correlación personalizadas (Wings) con parámetros configurables.
• 📋 Diagnósticos Honestos: Línea de estadísticas por ventana (records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted) para que siempre sepa si se descartó evidencia.
• 🧪 Calidad Garantizada: Una suite de regresión pytest que cubre el análisis de marcas de tiempo, normalización de identidad, expansión, el contrato del escritor, la creación de Eye (gobernanza GEP en el lado de escritura) y el registro de campos estándar.

Arquitectura del Sistema

El Motor de Correlación consta de cuatro componentes principales:

1. 🗄️ Feathers (Normalización de Datos)

Propósito: Transformar artefactos forenses sin procesar en un formato estandarizado y consultable.

• Bases de datos SQLite que contienen datos de artefactos forenses normalizados — un feather por tipo de artefacto (Prefetch, ShimCache, Event Logs, …) con un esquema estandarizado y metadatos para consultas eficientes.
• Un formato universal que acepta datos de cualquier herramienta 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

**Formatos de importación admitidos:** CSV (cualquier archivo con cabecera), JSON (plano o anidado) y SQLite (importación directa). Mapeo automático de columnas, detección de tipos de datos, normalización de marcas de tiempo a ISO, validación e índices optimizados.```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Wings (Reglas de correlación)

Propósito: Definir qué artefactos correlacionar y cómo.

• Reglas JSON/YAML que especifican una ventana de tiempo, coincidencias mínimas, prioridad de ancla y las plumas (con pesos) a correlacionar — reutilizables entre casos. Cada Wing es autorizable y sellable (registra quién lo creó, por qué y la evidencia que lo motivó).```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. ⚙️ Motores (Estrategias de Correlación)

**Propósito**: Ejecutar lógica de correlación para encontrar relaciones entre artefactos. Los enlaces estructurales vienen **primero**; una puntuación ponderada por niveles se superpone como *interpretación/clasificación*, no como base para una coincidencia.

**Motor de Escaneo por Ventana de Tiempo** — mejor para análisis basado en tiempo y correlación temporal sistemática. Escanea el tiempo en intervalos fijos, recopila registros de todas las plumas por ventana, aplica coincidencia de campos semánticos + puntuación ponderada, y evita duplicados mediante el seguimiento MatchSet. **O(N log N)** (consultas de marcas de tiempo indexadas); procesamiento por lotes (~2,567 ventanas/segundo).

**Motor de Correlación Basado en Identidad** — mejor para conjuntos de datos grandes (>1,000 registros) y seguimiento de identidad. Extrae y normaliza identidades, agrupa registros por identidad, construye anclas temporales dentro de cada clúster, clasifica la evidencia como primaria/secundaria/de respaldo, y transmite para conjuntos muy grandes (>5,000 anclas) con memoria constante. **O(N log N)**; más de 40 patrones de campos de identidad por tipo.

**Selección del motor:** use el motor de Ventana de Tiempo para análisis basado en tiempo y el motor Basado en Identidad para seguimiento de identidad — ambos están listos para producción y optimizados para grandes conjuntos de datos con consultas indexadas.

#### 4. 🔄 Pipelines (Orquestación de Flujos de Trabajo)

**Propósito**: Automatizar flujos de trabajo de análisis completos desde la creación de plumas hasta la generación de resultados. Un pipeline lee su configuración (tipo de motor, alas, plumas), instancia el motor correcto mediante el EngineSelector, ejecuta cada ala, agrega coincidencias, guarda los resultados (DB + JSON) y los muestra en la GUI con filtrado y visualización.```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"
  }
}

Cómo funciona todo en conjunto```

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

### Caso de uso de ejemplo: Encontrar pruebas de ejecución

**Escenario**: demostrar que `malware.exe` se ejecutó en un sistema.```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

El contenido de entrada está vacío. No se ha proporcionado ningún texto para traducir. Por favor, envía el chunk 18/25.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

El contenido de entrada está vacío: no se incluyó texto del chunk 20 para traducir.```
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

Puntos de referencia de rendimiento

Primeros pasos con el motor de correlación

1. Inicio: python -m correlation_engine.main
2. Crear Feathers: importa tus artefactos forenses (Prefetch, ShimCache, …).
3. Crear Wings: define reglas de correlación para tu investigación.
4. Crear un Pipeline: configura qué wings y feathers usar.
5. Ejecutar: ejecuta el pipeline y visualiza los resultados correlacionados.
6. Analizar: usa el Visor de Resultados para explorar las relaciones temporales.

📚 Documentación del motor de correlación

• Descripción general del motor de correlación — descripción general del sistema con diagramas de arquitectura
• Documentación del motor — arquitectura de doble motor, selección de motor, optimización del rendimiento
• Arquitectura — integración de componentes y flujo de datos
• Documentación de Feather — el sistema de normalización de datos
• Documentación de Wings — reglas de correlación
• Documentación de Pipeline — orquestación del flujo de trabajo
• Añadir un artefacto — el flujo de trabajo para conectar un nuevo analizador al motor
• Registro de campos estándar — sinónimos canónicos de nombres de columnas cargados por ambos motores y por Eye
• Guía de contribución — cómo contribuir al motor
• Enlaces rápidos: Selección de motor · Solución de problemas · Optimización del rendimiento

👁️ Eye — El asistente de IA forense

Un asistente potente, no un sustituto. Eye automatiza y verifica las hipótesis de un investigador; nunca decide por ti.

Eye es el asistente de IA forense integrado de Crow-Eye: un investigador forense experto respaldado por una base de conocimiento real de artefactos de Windows. Te ofrece una interfaz de lenguaje natural para consultar, correlacionar y documentar todo en un caso — Prefetch, MFT, Registry, Event Logs, AmCache, ShimCache, SRUM y más — mientras mantiene un registro auditable y a prueba de manipulación de exactamente lo que hizo. Eye puede ejecutarse por completo en tu propio hardware (incluido totalmente aislado de la red), en línea con la postura de privacidad de Crow-Eye de "0 ms de datos enviados fuera del dispositivo". Arquitectura completa: eye/README.md.

Eye convierte preguntas conversacionales ("muéstrame qué se ejecutó desde C:\Temp después de las 22:00") en trabajo forense real: planifica un enfoque, recupera conocimiento relevante de artefactos, ejecuta SQL y búsquedas entre artefactos contra las bases de datos del caso, y sintetiza una respuesta validada. Cada respuesta se produce en dos lugares a la vez — una respuesta de chat para ti y un bloque estructurado escrito en un Espacio de trabajo de Informe en Vivo, de modo que el expediente se construye solo a medida que avanza la investigación.

El Protocolo Ghassan Elsman (GEP)

Todo lo que hace Eye se ancla al Protocolo Ghassan Elsman (GEP) — un estándar neutral respecto al proveedor e independiente de la herramienta sobre cómo debe usarse cualquier IA en la informática forense. Son 10 principios que un sistema conforme debe cumplir para que los hallazgos asistidos por IA sigan siendo veraces, trazables hasta los registros fuente y respaldados por una cadena auditable y a prueba de manipulación, con el investigador humano al mando:

El Eye de Crow-Eye es la implementación de referencia del GEP; los comportamientos dentro del producto que lo sostienen son las Reglas Operativas. 📜 Lee el estándar: eye/docs/GEP_standard.md.

Modos de despliegue

Eye se adapta a tu modelo de amenazas mediante tres modos de despliegue:

En el modo agente CLI, Crow-Eye utiliza un agente de terminal/línea de comandos de IA existente como modelo — en lugar de una API en la nube o un servidor local sin conexión — para que puedas investigar con el agente que ya usas.

El bucle de investigación:

1. Abre o crea un caso — Eye se limita a las bases de datos de artefactos y al historial de ese caso.
2. Haz una pregunta en lenguaje natural, o lanza un triaje exhaustivo con un clic.
3. Eye ejecuta su pipeline — detectar intención → recuperar conocimiento → ejecutar herramientas → sintetizar.
4. Obtienes una salida dual — una respuesta directa en el chat y un nuevo bloque en el Informe en Vivo.
5. Aprueba las acciones restringidas — las exportaciones y otros pasos críticos esperan tu visto bueno.

Puedes cambiar de modelo en tiempo de ejecución con la herramienta switch_model. El cambio está restringido al mismo backend, de modo que la evidencia nunca se envía silenciosamente a un proveedor distinto del que elegiste.

Seguimiento del proceso de razonamiento del LLM

Eye está diseñado para que puedas ver — y luego probar — cómo llegó a una conclusión. Mientras Eye trabaja, transmite actualizaciones estructuradas ThinkingStep a la interfaz en tiempo real; cada una incluye un step_id, type, una label legible por humanos, un status (active → done, o error), y opcionalmente tool/params/detail.

Una consulta típica se desarrolla como thinking → rag → thinking → tool_call → synthesis, y cada caso conserva en disco artefactos de rastreo que puedes inspeccionar después:

Ejecución de herramientas

Eye está orientado a herramientas: el modelo nunca toca la evidencia directamente. Emite llamadas a herramientas, y Eye las ejecuta contra las bases de datos del caso y devuelve los resultados — de modo que cada acción es explícita, queda registrada y es reproducible. Las herramientas están definidas en configs/llm_config.json y se envían a través de eye/services/context_manager.py.

Herramientas de investigación — leer y analizar evidencia:

Las herramientas de informes construyen el Espacio de trabajo de Informe en Vivo: 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 y export_report (la exportación requiere aprobación humana).

Herramientas de autoría (gobernadas — consulta Construcción de Wings de correlación y Mappings semánticos): correlation_create_wing, correlation_edit_wing, correlation_create_semantic_mapping, correlation_edit_semantic_mapping. Las llamadas a herramientas se traducen a lo que el backend activo espera — llamada nativa a funciones para APIs en la nube y servidores locales, o un envoltorio XML <tool_call> para agentes CLI.

Construcción de Wings de correlación y Mappings semánticos

Eye no solo consulta el Motor de Correlación — también puede ayudar a extenderlo. Cuando Eye detecta un patrón recurrente entre artefactos, puede proponer nuevos Wings (reglas de correlación) y Mappings semánticos (traducciones de términos técnicos a lenguaje humano). Esto es autoría gobernada: Eye propone, el analista revisa el artefacto guardado, y cada cambio está justificado y respaldado por evidencia.

Un Wing une feathers dentro de una ventana de tiempo y un umbral mínimo de coincidencias para probar una afirmación:

Un Mapping semántico traduce un valor técnico bruto a un significado legible por humanos (p. ej., EventID 4624 → "Successful Logon"). Se presenta en dos variantes: un mapping simple (valor único/regex → valor semántico) o una rule multicondición (condiciones unidas por AND/OR). Ambos admiten category, severity, confidence y scope, y ambos requieren reason + related_evidence.

Gobernanza — reglas del lado de escritura que sostienen el GEP:

• Reason-Required (sostiene GEP-9 + GEP-2): cada creación y edición debe incluir una reason forense.
• Evidence-Link (sostiene GEP-2): cada creación debe citar al menos una referencia database:table:rowid.
• Eye-Stamped / solo lectura para otros (sostiene GEP-7 + GEP-9): Eye sella su autoría + razón + historial de ediciones y solo puede editar lo que Eye ha creado — las reglas integradas y las creadas por humanos permanecen en solo lectura.

Contexto autocurativo

Las investigaciones largas pueden superar la ventana de contexto de un modelo — especialmente los modelos locales más pequeños. En lugar de fallar o descartar evidencia silenciosamente, Eye autocompacta su propio contexto antes de cada llamada al modelo (dentro de su ruta de generación protegida, totalmente auditada).

Antes de cada llamada, Eye mide la carga útil completa y reserva espacio para la respuesta (10% de la ventana, mínimo 512 tokens, nunca más de la mitad). Si aun así no cabe, se cura en dos pasadas ordenadas, sin tocar nunca los mensajes protegidos (fijados, evidencia autodetectada o un resultado de herramienta):

1. Pasada de resumen (una vez) — el historial no protegido se condensa en un único resumen, registrado como SUMMARIZED.
2. Pasada de descarte — el mensaje no protegido más antiguo se elimina uno a uno hasta que quepa, registrado como TRUNCATED.

Si el núcleo de evidencia irreductible (fijado + resultados de herramientas + la pregunta actual) aún se desborda, Eye se niega a continuar en lugar de truncar evidencia (REFUSED_OVERFLOW) y te pide que acotes la consulta o uses analyze_large_dataset. Lo que finalmente vaya al modelo es la carga útil exacta que se sella para la cadena de custodia.

🗺️ Mapa Narrativo — La memoria persistente de caso de Eye

El Eye es sin estado entre turnos — por eso el Mapa Narrativo es donde vive "lo que sabemos y lo que hemos concluido" para un caso. Es la memoria de trabajo persistente, auditable y a prueba de manipulación de Eye, y su contenido se inyecta en el prompt de Eye en cada turno (el mapa literalmente es la memoria).

• 🧭 Veredicto → Narrativa → Evidencia. Una jerarquía estricta: un Veredicto por caso, las Narrativas debajo (afirmaciones, cada una con un estado — proven · open · negative · needs · absolute), y la Evidencia respaldada por artefactos debajo de estas.
• 🪟 Ventana propia. Se abre desde el botón "Mapa Narrativo" en la ventana de chat de Eye, para que puedas ver el chat, el informe en vivo y la memoria del caso lado a lado; se actualiza en vivo a medida que las cosas cambian.
• ↔️ Bidireccional — una memoria que controlas. Tanto las ediciones de Eye como tus propias notas pasan por un único commit validado por GEP y se sellan en un registro de auditoría encadenado por hash (narrative_map_audit.jsonl). Puedes añadir, editar y eliminar sus afirmaciones y evidencia, moldeando directamente cómo Eye entiende e interpreta el caso.
• 🚫 Nunca afirma lo no respaldado. Una narrativa de Eye puede permanecer open sin evidencia mientras investiga, pero nunca puede estar proven sin evidencia; un tema que Eye revisó pero encontró vacío se convierte automáticamente en negative — porque una ausencia documentada es en sí misma un hallazgo.

Cómo funciona el cumplimiento

El cumplimiento no es una función añadida por encima — se aplica dentro del pipeline.

• 🔗 Cadena de custodia (Sello de evidencia). Cada carga útil que Eye envía a un LLM se sella: el SHA-256 de los bytes exactos, el recuento de tokens, el modelo + su límite de contexto, y la procedencia de cada fila de evidencia (database:table:rowid, más los desplazamientos calculados para los registros MFT). Los sellos son de solo añadir y encadenados por hash en <case>/EYE_Logs/eye_payload_seal.jsonl — un único registro alterado o eliminado rompe la cadena, de modo que el registro demuestra matemáticamente qué bytes analizó el modelo.
• 🚫 Sin truncación silenciosa. Cuando el contexto se queda corto, Eye se autocura y reasigna presupuestos en un orden estricto: Prioridad 1 (Inamovible): Evidencia bruta + el Prompt del sistema › Prioridad 2 (Sacrificable): Conversación informal › Prioridad 3 (Flexible): Contexto RAG. Si el núcleo de evidencia aún no cabe, Eye se niega en lugar de descartar evidencia silenciosamente.
• 🧾 Rastro de auditoría de truncación. Cada decisión de contexto se registra en <case>/EYE_Logs/truncation_audit.log (SUMMARIZED, TRUNCATED, PRESERVED, PINNED, UNPINNED, BUDGET_REDUCED), cada una con un hash. La evidencia detectada se fija automáticamente por encima de un umbral de confianza; también puedes fijar mensajes manualmente.
• 📑 Mandato de evidencia al informe. Eye debe responder en el chat y persistir la evidencia de respaldo en el informe; no registrar la evidencia se señala como una violación del protocolo.
• ⚖️ Gobernanza de correlación. Cualquier Wing o mapping que Eye cree debe incluir una reason forense y related_evidence; las reglas creadas fuera de Eye son de solo lectura y no pueden reescribirse silenciosamente.
• 🔐 Privacidad y aislamiento de red. En los modos sin conexión, Eye realiza cero llamadas salientes; las claves de API en la nube viven en los llaveros nativos del sistema operativo — nunca codificadas, nunca escritas en los registros.

📖 Arquitectura completa de Eye: eye/README.md.

📖 Eye-Describe — Base de conocimiento de artefactos a nivel de byte

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

Históricamente, los investigadores caían en la trampa de confiar en sus herramientas forenses sin entender cómo se comportan los artefactos subyacentes ni cómo los analizó la herramienta. El riesgo hoy es simplemente reemplazar "la herramienta" por "la IA". Una IA puede analizar un registro con una precisión técnica perfecta y aun así situarlo en el contexto equivocado — cambiando por completo el significado de la evidencia.

Eye-Describe existe para que ni el humano ni el modelo tengan que adivinar. Es una referencia interactiva a nivel de byte de las estructuras binarias brutas de los artefactos de Windows, y cumple dos roles a la vez:

Al anclar la capa de IA al comportamiento documentado de los artefactos, Crow-Eye no te pide que confíes en un modelo — está limitando el modelo para que respete los datos forenses brutos.

No reemplaces la confianza en la herramienta por la confianza en la IA. Entiende los datos.

🧪 Calidad y validación

Una herramienta forense solo es útil si su salida puede defenderse. El trabajo de corrección de Crow-Eye es deliberadamente visible:

• Suites de regresión. El Motor de Correlación está asegurado por una suite pytest que cubre el análisis de marcas de tiempo, la normalización de identidades, la expansión multi-marca de tiempo, el contrato del escritor, la autoría de Eye (gobernanza GEP del lado de escritura) y el registro de campos estándar. El motor UBA incluye su propia suite, incluida una ejecución de extremo a extremo contra un caso real.
• Arnés de validación. Un arnés holístico ejercita los 7 wings predeterminados contra ambos motores en un caso real de Windows de ~700K registros.
• Historial de defectos publicado. Las regresiones de precisión y su impacto medido se documentan abiertamente en RELEASE_NOTES.md — incluidos casos donde una corrección cambió los registros vistos en órdenes de magnitud. Saber qué estuvo mal, y cuándo, es parte de lo que hace defendible un resultado.
• Contabilidad de evidencia verificable. Cada registro termina en una coincidencia o en un depósito de descarte con nombre, y el libro de descartes por ventana hace que "no queda evidencia sobrante" sea algo que puedes comprobar desde el registro en lugar de aceptar por fe.
• Registros a prueba de manipulación. verify_chain() re-recorre el registro de auditoría del Mapa Narrativo y la cadena del Sello de evidencia para detectar modificaciones — incluso en los campos legibles por humanos.

🔬 Plataforma de investigaciónCrow-Eye es más que un software — es una plataforma abierta de investigación que acelera todo el campo de la informática forense de Windows. El proyecto se centra en:

• Publicar documentación detallada sobre las estructuras internas de los artefactos.
• Compartir lógica y metodologías de correlación.
• Permitir la revisión por pares, la transparencia y la colaboración académica.
• Contribuir al conocimiento colectivo de la comunidad forense.

🛠️ Notas técnicas

• El análisis del registro requiere archivos hive de registro completos.
• Algunos artefactos requieren un manejo especial debido a los mecanismos de bloqueo de archivos de Windows (consulte Registro personalizado / archivos bloqueados).
• El análisis de LNK y Jump List lo realiza el propio analizador dedicado de Crow-Eye.

📸 Capturas de pantalla

Una selección de las vistas de interfaz y análisis de Crow-Eye.

🎥 Vídeo de demostración:

🚧 Hoja de ruta

Trabajo planificado y en curso (consulte RELEASE_NOTES.md para ver los cambios publicados):

• 📊 Vistas e informes avanzados de GUI — visualización y creación de informes más enriquecidas.
• 🔄 Diálogo de búsqueda mejorado — filtrado avanzado con soporte de lenguaje natural.
• 🎯 Mapeo semántico mejorado — mapeo integral de campos en todos los tipos de artefactos.
• 📈 Puntuación de correlación avanzada — puntuación de confianza refinada y explicable.
• ⚡ Correlación paralela — despacho mediante pool de procesos, habilitado por defecto para cargas de trabajo grandes.

¿Tienes una idea o quieres añadir un artefacto? Abre un issue o consulta Contribuir.

📚 Documentación

• TECHNICAL_DOCUMENTATION.md — arquitectura, componentes y guía de desarrollo.
• RELEASE_NOTES.md — novedades de cada versión (UBA, Narrative Map, backends cloud de Eye, endurecimiento de la gestión de casos, …).
• Documentación del Correlation Engine — descripción general, motor, feathers, wings, pipelines.
• Arquitectura de Timeline — detalles internos del módulo de timeline.
• Arquitectura de Eye y estándar GEP — el asistente de IA y su protocolo regulador.

🤝 Contribuciones

Crow-Eye está construido como una plataforma abierta de investigación, y las contribuciones son bienvenidas: nuevos parsers, reglas de correlación, documentación e investigación de artefactos.

• Contribuciones generales: CONTRIBUTING.md
• Correlation Engine (área prioritaria): correlation_engine/CONTRIBUTING.md
• Contacto: [email protected] · o abre un issue / pull request.

🌐 Sitio web y comunidad

• 🌍 Sitio web oficial: crow-eye.com — recursos, documentación y descargas.
• 💬 Discord: Únete al Discord de Crow-Eye — ayuda directa, investigación de artefactos y anuncios de versiones.

📄 Licencia

Crow-Eye se publica bajo la GNU General Public License v3.0 (GPL-3.0). Es libre de usar, estudiar, compartir y modificar según los términos de esa licencia.

📝 Cómo citar Crow-Eye

Si utilizas Crow-Eye en trabajos académicos, investigaciones publicadas o un informe de caso, por favor cítalo:```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} }

Texto plano: Elsman, G. *Crow-Eye: Un motor de análisis forense para Windows* (GPL-3.0). https://github.com/Ghassan-elsman/Crow-Eye

Para citas de metodología, el Protocolo Ghassan Elsman está documentado por separado en [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md).

## 💖 Apoyo

Crow-Eye es gratuito y de código abierto, creado y mantenido por una sola persona. Si te resulta útil para tu trabajo, considera patrocinarlo — financia directamente nuevos parsers e investigación: **[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**.

## Créditos

Creado y mantenido por **Ghassan Elsman**.