Crow-Eye — Mecanismo de Forense para Windows

Uma máquina do tempo forense para Windows.
Crow-Eye não apenas detecta — ele reconstrói o que realmente aconteceu na linha do tempo, desde a aquisição até um veredito rastreável aos seus registros de origem.

Table of Contents

• Visão Geral
• ✨ Destaques
• 👥 Para Quem é o Crow-Eye
• 🧭 Subsistemas em Resumo
• 🏗️ Arquitetura
• 📥 Download e Instalação
• 🚀 Início Rápido
• 📂 Artefatos Suportados
• 🔧 Modos de Análise
  • 📎 Importar Evidências (dados de terceiros)
• 🧠 Análise de Comportamento do Usuário (UBA)
• 🧩 Mecanismo de Correlação
• 👁️ Eye — O Assistente de IA Forense
• 📖 Eye-Describe — Base de Conhecimento de Artefatos em Nível de Byte
• 🧪 Qualidade e Validação
• 🔬 Plataforma de Pesquisa
• 🛠️ Notas Técnicas
• 📸 Capturas de Tela
• 🚧 Roteiro
• 📚 Documentação
• 🤝 Contribuição
• 🌐 Site e Comunidade
• 📄 Licença
• 📝 Como Citar o Crow-Eye
• 💖 Suporte
• Créditos

Visão Geral

Crow-Eye é um mecanismo de forense Windows de código aberto (GPL-3.0) que unifica aquisição, análise, verificação, inteligência e IA. A maioria das ferramentas de segurança pergunta "isto é ruim?" e descarta o que parece legítimo. Crow-Eye faz uma pergunta diferente: "o que aconteceu?" Ele correlaciona toda a atividade — suspeita ou não — e reconstrói a sequência real de eventos em um sistema, de modo que a verdade de uma investigação seja reconstruída a partir de evidências em vez de adivinhada a partir de alertas.

Esse design centrado em reconstrução é exatamente o que é preciso para caçar ameaças de APT e de estados-nação: adversários sofisticados vivem dentro de ferramentas legítimas (powershell.exe, PsExec, certutil) e na sequência de ações — invisíveis para ferramentas que descartam tudo o que parece normal. Como o Crow-Eye nunca descarta nada e raciocina sobre artefatos de execução (que sobrevivem à adulteração de logs e a técnicas antiforenses), o ataque não pode se esconder. O mesmo mecanismo permanece acessível para o trabalho diário de DFIR e para não especialistas que simplesmente querem saber o que aconteceu em um computador.

• 🕰️ Reconstrua, não apenas detecte — reconstrua a linha do tempo do que realmente ocorreu.
• 🖥️ Multiplataforma — análise completa ao vivo + offline no Windows; análise offline e parsing de imagens forenses no Linux (os parsers ao vivo são exclusivos do Windows).
• 🔒 Privado por design — 0 ms de dados enviados para fora do dispositivo; o assistente de IA Eye pode operar totalmente isolado de rede.
• 🧾 Nível judicial — as evidências são lacradas criptograficamente e cada etapa é auditável.
• 📦 Versão atual: 0.12.6 · Mecanismo de Correlação: 1.7.0 · Licença: GPL-3.0.

✨ Destaques

• Reconstrução em vez de detecção. Correlaciona cada artefato em uma única história navegável por entidade, em vez de uma pilha de alertas.
• Integrado de ponta a ponta — aquisição → correlação → linha do tempo → análise comportamental → IA → memória de caso lacrada: um pipeline completo que nenhuma ferramenta tradicional abrange.
• Profundo em artefatos, não raso em logs. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists e mais sobrevivem à limpeza de logs e aos truques de "living-off-the-land" que cegam ferramentas baseadas apenas em logs.
• O assistente de IA Eye — investigação forense em linguagem natural com uma cadeia de custódia auditável e à prova de adulteração, executável na nuvem, em um servidor privado ou totalmente offline.
• Análise de Comportamento do Usuário (UBA) — transforma artefatos brutos em uma história de atividades em linguagem simples, legível para RH/examinadores.
• Gratuito e de código aberto (GPL-3.0) — auditável por qualquer pessoa, com um esforço ativo de pesquisa e documentação.

👥 Para Quem é o Crow-Eye

O Crow-Eye é usado em fluxos de trabalho muito diferentes. Cada um entra no mecanismo por uma porta diferente:

Qualquer coletor funciona. O Crow-Eye não exige sua própria ferramenta de aquisição. Aponte o Importador Offline para uma pasta de artefatos brutos produzidos por Velociraptor, KAPE, um pacote de coleta de EDR ou qualquer outro coletor — ele indexa os artefatos suportados e executa os parsers offline sobre eles. Separadamente, a saída de Plaso, Autopsy, Volatility ou qualquer outra ferramenta pode ser importada como CSV, JSON ou SQLite via Importar Evidências e correlacionada junto com os artefatos nativos.

🧭 Subsistemas em Resumo

O Crow-Eye é construído como um ciclo integrado — cada etapa alimenta a próxima, do disco bruto a um veredito defensável.

🏗️ Arquitetura

O Crow-Eye é um pipeline integrado, não apenas um conjunto de parsers. As evidências fluem em uma única direção, e cada etapa mantém seu vínculo de volta ao registro de origem.```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

*Fonte de evidências → Ingestão → Bancos de dados do caso → Análise → Camada de IA → Relatório*


**Como ler:**

| Etapa | O que importa |
|---|---|
| ① → ② | **Quatro portas independentes para um caso.** Você nunca precisa do coletor próprio do Crow-Eye — uma pasta do Velociraptor, KAPE ou de um pacote de EDR passa pelo Importador Offline, e CSV/JSON/SQLite de terceiros passa por Importar Evidências. |
| ② → ③ | Tudo converge para um único lugar: **os bancos de dados do caso**. Os artefatos analisados vão para `Target_Artifacts/`; as evidências de terceiros importadas vão para `Imported_Evidence/` e são descobertas automaticamente. |
| ③ → ④ | **Os três caminhos de análise são independentes entre si.** A Timeline e a UBA leem os bancos de dados do caso diretamente — nenhuma exige uma execução de correlação. O Mecanismo de Correlação é uma camada *adicional*, não um pré-requisito. |
| ③ → ④ | **O Dynamic Linking fica ao lado da Timeline e da UBA** — um quarto leitor independente dos bancos de dados do caso (não tem nada a ver com a visualização da Timeline). Ele reúne mapeamentos de identidade (SID → nome de usuário, MAC → rede, hash/GUID → aplicativo) em um `Crow_Intelligence.db` por caso e, em seguida, sobrepõe esse contexto **embutido nas tabelas de dados de artefatos** por meio de `ATTACH` + `LEFT JOIN` não destrutivos. Isso muda a forma como os registros *são lidos*, nunca as evidências. |
| ④ → ⑤ | O Eye consulta os bancos de dados do caso diretamente e pode obter resultados de correlação **sob demanda**. Ele nunca toca nas evidências em si — emite chamadas de ferramenta que o Crow-Eye executa e registra. |
| ⑤ → Relatório | O **Relatório Vivo é construído apenas pelo Eye**, por meio de suas ferramentas `report_*`. A Timeline e a UBA são superfícies de análise — elas não escrevem no relatório. As conclusões em nível de caso ainda podem ser exportadas separadamente via [Busca e Exportação](#-search--export). |
| ⑤ ↔ | O **Mapa Narrativo é bidirecional**: o Eye escreve nele, você escreve nele, e seu conteúdo é injetado no prompt do Eye a cada turno. É a memória, e você pode comandá-lo. |
| ⑤ ⟳ | A página de **Conformidade audita o Eye.** Cada chamada de ferramenta que o Eye faz é ancorada na cadeia de hash **EvidenceSeal**; a página renderiza o status **GEP** por regra em tempo real (10 princípios) verificado a partir dessa cadeia e de `EYE_Logs/`, exportável como `audit_trail.json`. |

**Estágios independentes.** A Timeline e a UBA leem os bancos de dados de artefatos do caso **diretamente** — nenhum exige uma execução de correlação, e a Timeline não depende do Mecanismo de Correlação (ela aplica seu próprio agrupamento temporal leve). A correlação é uma camada de análise adicional cujos resultados o Eye pode consultar.

**Somente leitura por design.** O parsing escreve no banco de dados do caso; cada estágio downstream (UBA, Timeline, visualizadores de correlação, Eye) abre esses bancos de dados **somente leitura**. As evidências originais nunca são modificadas — o [Dynamic Linking](#-analysis-modes) lê os bancos de dados do caso para criar um `Crow_Intelligence.db` por caso com mapeamentos de identidade e enriquece as tabelas de dados de artefatos inline por meio de consultas `ATTACH` + `LEFT JOIN` não destrutivas, em vez de reescrever linhas.

**Governado por design.** Cada ação do Eye é ancorada à cadeia de hash **EvidenceSeal** à prova de adulteração, e a página de **Conformidade** verifica continuamente o Eye contra o [Protocolo Ghassan Elsman (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) — status por regra em tempo real, exportável para `EYE_Logs/audit_trail.json`.

## 📥 Download e Instalação

> **Recomendado:** obtenha o pacote de build do Windows (**instalador MSI / EXE**) no site oficial — sem configuração de Python, funciona imediatamente.

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

O **build MSI/EXE instalado é a forma recomendada de executar o Crow-Eye**, e é a nossa **maior prioridade em atualizações**:

- 🛡️ **Correções mais rápidas.** Quando um problema é encontrado ou um bug é relatado, lançamos um EXE atualizado **o mais rápido possível** — o build empacotado é onde as correções chegam primeiro.
- 🔄 **Atualização automática integrada.** No aplicativo instalado, abra **Configurações → Atualizações** para **verificar atualizações e instalá-las automaticamente** — sem reinstalação manual.
- 📦 **Zero configuração.** Nenhuma instalação de Python, Node ou dependências é necessária.

> Prefere executar a partir do código-fonte? Veja **[Início Rápido](#-quick-start)** abaixo. O build a partir do código-fonte é destinado a colaboradores e **não inclui o atualizador automático** — use o MSI/EXE para atualizações automáticas.

## 🚀 Início Rápido

### Opção A — Build instalado (recomendado)
Baixe o **MSI/EXE** de [crow-eye.com/download](https://crow-eye.com/download), instale e abra o **Crow-Eye** como Administrador. Crie um caso e comece a analisar.

### Opção B — Executar a partir do código-fonte (desenvolvedores)

> Para colaboradores e usuários avançados. Este caminho **não inclui o atualizador automático** — use o MSI/EXE para atualizações automáticas.

**Requisitos** (instalados automaticamente na primeira execução):
- Python 3.12.4
- **Node.js e npm** — necessários para a **Visualização da Timeline**
- Pacotes principais: 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 com milhões de registros) |
| **Disco** | 5 GB livres | Espaço livre ≥ 2× o tamanho das evidências sendo analisadas |
| **CPU** | 4 núcleos | 8+ núcleos |
| **SO** | Windows 10/11 (completo) · Linux (offline e análise de imagem) | — |

> A correlação processa em fluxo com memória constante para conjuntos de dados muito grandes, então a RAM raramente é o limite rígido — taxa de transferência do disco e espaço livre geralmente são.

**Execução** (execute como Administrador para que o Crow-Eye possa acessar artefatos do sistema):```bash
python "Crow Eye.py"

A interface principal abre, você cria um caso e toda a saída de análise é organizada sob o diretório desse caso para revisão e relatórios posteriores.

🖥️ Nota de multiplataforma: no Linux, os parsers ao vivo são desativados automaticamente e o Crow-Eye executa no modo offline / imagem forense. A aquisição ao vivo completa é exclusiva do Windows.

📂 Artefatos Suportados

O Crow-Eye analisa um amplo conjunto de artefatos de execução, sistema de arquivos e atividade do usuário do Windows, tanto de um sistema ao vivo quanto de fontes offline (pastas coletadas ou imagens forenses).

Jump Lists e LNK são analisados pelo parser LNK / Jump List dedicado do próprio Crow-Eye — não por um módulo de terceiros.

Registry personalizado / arquivos bloqueados: o Windows bloqueia os hives do registro ao vivo (NTUSER.DAT, SOFTWARE, SYSTEM) durante a operação. Para análise personalizada de um sistema ao vivo, inicialize a partir de mídia externa (WinPE/Live CD), use ferramentas de aquisição forense ou analise uma imagem de disco.

Detalhes por artefato

• Jump Lists e LNK — analisados automaticamente a partir dos locais padrão do sistema pelo parser dedicado do próprio Crow-Eye (acesso a arquivos, caminhos de destino, timestamps e metadados).
• Registry — analisa automaticamente os hives do sistema. Para análise personalizada do registro, copie os arquivos de hive para CrowEye/Artifacts Collectors/Target Artifacts (ou para a pasta registry/ do seu caso):
  • NTUSER.DAT de C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE de C:\Windows\System32\config\SOFTWARE
  • SYSTEM de C:\Windows\System32\config\SYSTEM
  • O Windows bloqueia esses arquivos durante a operação — em um sistema ao vivo, inicialize a partir de mídia externa (WinPE/Live CD), use ferramentas de aquisição forense ou analise uma imagem de disco.
• Prefetch — analisa C:\Windows\Prefetch, extraindo histórico de execução e metadados forenses (incluindo timestamps por execução).
• Logs de eventos — análise automática dos logs System/Security/Application em um banco de dados para análise abrangente.

🔧 Modos de Análise

🦅 Aquisição Crow-Claw

Crow-Claw é o mecanismo de aquisição especializado do Crow-Eye para coletar e preservar artefatos de sistemas ao vivo ou imagens montadas.

• Coleta seletiva — escolha categorias específicas de artefatos (Registry, Logs de Eventos, Sistema de Arquivos) ou colete tudo.
• Varredura profunda — percorre diretórios e subdiretórios para encontrar vestígios forenses.
• Preservação segura — os artefatos são organizados em um diretório de caso estruturado que mantém a integridade forense.

🔍 Análise Offline (Importador Offline)

Analise artefatos coletados de qualquer fonte sem conexão ao vivo com o alvo — três operações claras:

• SCAN (descoberta) — percorre a fonte e indexa todo artefato suportado por padrão de nome de arquivo e extensão (rápido, somente leitura; nenhum conteúdo de arquivo é lido e nenhuma verificação de magic bytes é realizada nesta etapa). Nada é movido.
• COLLECT (aquisição) — copia fisicamente os arquivos identificados para a pasta live_acquisition do caso, organizados por tipo.
• PARSE (granular) — revisa os itens identificados por tipo (AMCACHE, EVTX, PREFETCH, …) e analisa os arquivos selecionados (ou todos) no banco de dados forense.

A análise é feita pelos parsers offline dedicados do Crow-Eye — a mesma lógica de artefatos do modo ao vivo, operando sobre arquivos coletados: Prefetch, Registry, MFT, USN (além do correlacionador MFT/USN), AmCache, ShimCache, SRUM, Logs de Eventos, LNK/JumpLists e Lixeira.

📎 Importar Evidências (dados de terceiros)

Além de artefatos brutos, o Crow-Eye pode receber saída forense de terceiros diretamente em um caso — Plaso, Autopsy, Volatility ou qualquer exportação personalizada — e torná-la utilizável pelo Eye e pela Timeline sem exigir uma execução de correlação primeiro.

Como o gerenciador de banco de dados do caso descobre automaticamente qualquer .db na árvore do caso, as evidências importadas ficam imediatamente disponíveis para:

• The Eye — consultáveis em linguagem natural junto com artefatos nativos (o manifesto de esquema é atualizado na importação).
• A Timeline Interativa — fornecidas como tipo de artefato imported, com filtragem por janela de tempo e limites de tempo funcionais.
• O Mecanismo de Correlação — utilizáveis como uma Feather para correlação entre ferramentas contra artefatos nativos.

O importador usa apenas a biblioteca padrão (sqlite3 / csv / json) e é executado em um worker em segundo plano, para que importações grandes não bloqueiem a interface.

⚡ Análise ao Vivo

Analisa artefatos diretamente do sistema Windows em execução, extraindo automaticamente de seus locais padrão para análise forense em tempo real.

🗂️ Gerenciamento de Casos

Toda investigação é um caso: um diretório autocontido que organiza bancos de dados de artefatos e a saída da análise. O Crow-Eye acompanha casos recentes (com favoritos, tags e status), valida um caso ao abrir, grava a configuração atomicamente (à prova de falhas) e suporta importação/exportação de configuração de casos e modelos com mapeamentos semânticos prontos.

🕰️ Visualização Interativa da Timeline

Correlacione eventos entre artefatos em uma grade temporal unificada, com visualizações Heat Map, Week e Day — uma história conectada por identidade e rastreável em tribunal, em vez de uma super-timeline plana.

A Timeline lê os bancos de dados de artefatos analisados do caso diretamente e é independente do Mecanismo de Correlação — você não precisa construir feathers, criar wings ou executar um pipeline para usá-la. Ela aplica seu próprio agrupamento temporal leve (correlação por timestamp exato e janela de tempo, agrupamento por aplicativo, caminho ou usuário) para relacionar eventos na grade. Evidências trazidas por meio de Importar Evidências também aparecem na timeline como tipo de artefato imported, com filtragem por janela de tempo e limites de tempo funcionais.

🔎 Busca e Exportação

Busca de texto completo no banco de dados do caso, além de exportação para CSV (planilhas), JSON (integração com outras ferramentas) e relatórios HTML detalhados (dossiês completos consolidando todo artefato vinculado a um termo de busca).

🔗 Vinculação Dinâmica

Traduza identificadores técnicos brutos — SIDs, endereços MAC, hashes — em contexto legível por humanos em tempo real. A Vinculação Dinâmica enriquece a visualização usando consultas SQL ATTACH não destrutivas, de modo que a evidência original nunca é modificada, e pode ingerir feeds de IOC em massa para sinalizar indicadores conhecidamente maliciosos inline.

🧠 Análise de Comportamento do Usuário (UBA)

Transforme artefatos brutos em uma história de atividade em inglês simples — um relato compreensível para gerentes/Recursos Humanos do que um usuário e seus aplicativos realmente fizeram, com cada declaração rastreável até a evidência de origem exata.

A User Behavior Analytics (UBA) lê os bancos de dados de artefatos analisados na pasta Target_Artifacts/ do seu caso (estritamente somente leitura) e os reproduz por meio de um conjunto de regras declarativas para produzir uma História de Atividade clara e cronológica. Abra-a pelo botão da barra de ferramentas "User Behavior" ou com Ctrl+Shift+B (um caso deve estar carregado).

• 🧩 40 detecções de comportamento declarativas (uba/config/behavior_rules.json) — ajustáveis sem código — cada uma classificada por severidade: rotineiro · notável · suspeito · crítico.
• 🕵️ Detecta comportamento que importa: entrar / sair / desbloquear, execução · lançamento · instalação de programas, abrir / excluir / cópia inferida de arquivos, conexão de dispositivos USB, acesso a compartilhamentos de rede, persistência e autostart, uso de credenciais explícitas (runas), alterações de contas e grupos, alterações de serviços, adulteração do relógio do sistema (suspeito) e limpeza de logs de eventos (crítico).
• 🗺️ Três visualizações — um feed de História de Atividade, um heatmap de Mapa de Atividade (dia × hora) e um relatório de honestidade "What we can see" que rotula cada detecção como Working / Limited / No data / By design para este caso.
• 🔗 Toda atividade é respaldada por evidências. Clique em qualquer item para abrir o registro de origem exato (database : table : rowid) — nada é afirmado sem uma fonte.
• 👤 Atribuição honesta. Os atores são resolvidos como Usuário / Aplicativo / Sistema (ou ficam vazios) — a UBA nunca adivinha quem fez o quê.

Cobertura de Detecção

As 40 detecções abrangem quatro classes de severidade e toda a amplitude do conjunto de artefatos analisados:

Filtros: busca de texto livre · usuário/ator (incluindo "Unattributed" e um alternador de sessão conectada) · classe de comportamento (usuário / aplicativo / sistema) · severidade · aplicativo (multi-seleção pesquisável entre mais de 200 programas) · intervalo de data/hora com predefinições rápidas (todo o tempo / primeiro dia / último dia / última hora de atividade).

Fontes de dados: Security, System e Application Event Logs · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · Lixeira · SRUM (aplicativo, rede, conectividade) · hives do registro.

Garantias Forenses

• Somente leitura. Os bancos de dados de origem são abertos somente leitura; a análise nunca toca a evidência.
• Proveniência completa. Todo evento carrega database → table → rowid e abre as linhas reais de origem sob demanda.
• A atribuição nunca adivinha. Um evento é atribuído a um Usuário, um Aplicativo, o Sistema — ou fica vazio. Sessões de logon interativas são usadas apenas como rótulos de contexto ("durante a sessão de <usuário>"), nunca para atribuir uma ação.
• Redação honesta. O texto distingue interação deliberada (UserAssist, SRUM em primeiro plano) de artefatos que um aplicativo também pode gerar (ShellBags, LNK, JumpLists), com ressalvas explícitas mostradas no cartão.
• A ausência é declarada, não implícita. O relatório What we can see rotula cada detecção para este caso específico, de modo que dados ausentes nunca são silenciosamente lidos como "nada aconteceu".

A UBA é correlação e classificação comportamental orientada por regras, não pontuação estatística/ML de anomalias — cada descoberta mapeia para uma regra explícita e auditável. Veja RELEASE_NOTES.md para o catálogo completo de detecções.

🧩 Mecanismo de Correlação

Correlation Engine v1.7.0 — o núcleo de reconstrução. Veja RELEASE_NOTES.md para o histórico de versões.

O Crow-Eye Correlation Engine é um sistema de correlação forense de nível de produção. Ele ingere artefatos do Windows de qualquer fonte, normaliza-os e evidencia as relações temporais e de identidade que transformam registros isolados em uma narrativa coerente do que aconteceu em um sistema, quando e quem estava envolvido. Ele funciona de imediato com regras de correlação integradas (Wings) para as perguntas de investigação mais comuns, permite que analistas criem regras personalizadas sem tocar em código e transfere o significado para regras criáveis e para o investigador — nunca para uma pontuação de caixa-preta.

🎥 Guia do Usuário

Importação Universal de Dados: O Mecanismo de Correlação pode receber a saída de qualquer ferramenta forense em formato CSV, JSON ou SQLite e convertê-la em um banco de dados Feather. Isso significa que você pode correlacionar dados de ferramentas de terceiros (Plaso, Autopsy, Volatility etc.) com os artefatos nativos do Crow-Eye, criando uma análise de correlação unificada em todas as suas fontes de dados forenses.

🎯 Precisão e Completeza de Evidências

Uma passagem focada de precisão, validada de ponta a ponta contra um caso real do Windows com ~700 mil registros, aplicada sobre o trabalho de confiabilidade anterior. Cada correção abaixo é garantida pela suíte de testes de regressão pytest e verificada por um harness de validação holística que exercita todos os 7 wings padrão contra ambos os mecanismos.

O mecanismo de identidade captura todas as evidências

• Corrigido: o mecanismo de identidade estava iterando apenas a PRIMEIRA linha de cada feather quando um filtro de tempo estava ativo (uma comparação de datetime ciente vs ingênua de fuso horário gerava TypeError e abortava o loop por linha). Registros vistos saltaram de 3.558 → 745.615 no caso de validação.
• Corrigido: os registros de log colapsavam todo evento ao PROVIDER do evento como identidade (todos os 33.855 registros de SecurityLogs compartilhavam uma única identidade). O mapeamento por artefato agora prioriza entidades reais por linha (User, ComputerName, NewProcessName, TargetUserName) antes dos metadados de canal/provider.
• Corrigido: o mapeamento de campos ciente de artefato nunca disparava porque os parsers não carimbam uma coluna artifact em cada linha. O mecanismo agora recorre a feather_metadata.artifact_type, de modo que SecurityLogs / SystemLogs / ApplicationLogs usam sua prioridade de identidade específica do artefato.
• Corrigido: strings de espaço reservado se tornavam identidades falsas ('N/A', 'Unknown', '-', GUIDs nulos agrupavam registros não relacionados). O validador agora rejeita mais de 30 variantes de espaço reservado.

Chega de "tudo é Low — algo está errado"

• Corrigido: correspondências de feather única eram marcadas como High. Correspondências com feather_count == 1 agora recebem confidence_category="Low - single feather", de modo que a visão High se concentra na correlação real entre feathers.
• Corrigido: uma chave composta ciente de caminho estava dividindo a mesma identidade entre feathers (cada feather armazena caminhos de forma diferente, então chrome tinha 10+ chaves e nunca correlacionava). A chave agora é apenas o nome — a correlação entre feathers funciona novamente.

Detecção de impersonação via classificação de caminho — após uma correspondência ser formada, o mecanismo classifica o caminho de cada registro como TRUSTED (Program Files, System32, WinSxS, as formas /device/harddiskvolumeN/... do BAM/SRUM, …) ou SUSPICIOUS (Temp, Downloads, Public, AppData\Local\Temp, Lixeira, raízes removíveis, compartilhamentos de rede). Uma correspondência que abrange ambas as classificações levanta impersonation_alert (taxa de ≈0,05%, cada uma um candidato real).

Contabilidade honesta de evidências — um registro de descarte por janela com buckets nomeados (no_identity_field, normalize_failure, below_threshold_skipped, …) além de um resumo por pipeline (registros vistos, high/low emitidos, sem identidade, buckets de descarte, junções de feathers sem tempo). Cada registro ou cai em uma correspondência ou em um bucket de descarte nomeado — "nenhuma evidência sobrando" é verificável no log. low_confidence_review_mode está ATIVADO por padrão, de modo que grupos abaixo do limite se tornam correspondências de baixa confiança em vez de desaparecerem silenciosamente.

Enriquecimento de identidade de feathers sem tempo — feathers sem timestamps por linha (AutoStartPrograms, MUICache, SystemServices, TypedPaths) não recebem mais um timestamp falso de geração em cada linha; em vez disso, após a formação das correspondências temporais, o mecanismo junta registros correspondentes de cada feather sem tempo por identidade como evidência suplementar.

Registro de identidade consolidado — config/standard_fields/identities.json é a fonte única de verdade para cada coluna que os mecanismos + Eye devem consultar: 98 categorias, 1.146 sinônimos de colunas (app/processo, arquivo, hash, usuário, host/dispositivo, rede, registro, serviço/tarefa, evento, e-mail, navegador, nuvem, internals do Windows, certificado, contêiner, objetos do SO). Adicionar um novo sinônimo de coluna é uma edição de JSON, não uma mudança de código.

Correções de falsos positivos de mapeamento semântico — o gating por múltiplos indicadores agora é realmente aplicado (data-exfiltration-pattern exige ≥2 indicadores); regras AND impossíveis (4625 AND 4624) reescritas como OR; regras de wiper/ferramentas remotas usam regex real em vez de disparar a cada entrada de Prefetch; regras de atividade de linha de base rebaixadas de high/critical para info/low (a pontuação ponderada do wing eleva ameaças reais).

✅ Status de Produção

O Mecanismo de Correlação está pronto para produção e é ativamente usado em investigações (Correlation Engine v1.7.0):- ✅ Motor de Varredura por Janela de Tempo — pronto para produção, recomendado para análises baseadas em tempo (O(N log N))

• ✅ Motor Baseado em Identidade — pronto para produção, recomendado para rastreamento de identidade (O(N log N))
• ✅ Feather Builder / FeatherWriter — importa CSV/JSON/SQLite de qualquer ferramenta; lotes transacionais + metadados de esquema
• ✅ Sistema Wings e Orquestração de Pipelines — crie/gerencie regras de correlação e automatize fluxos de trabalho
• ✅ Agrupamento de Identidade — unificado entre o motor, visualizadores e a fase semântica
• ✅ Registro de Campos Padrão — fonte central de verdade para sinônimos de campos
• ✅ Fan-Out Multi-Timestamp — todo timestamp de lista JSON correlacionado
• 🔄 Correlação Paralela — base pronta; perfilamento e despacho por process-pool em seguida
• 🔄 Mapeamento Semântico e Pontuação de Correlação — aprimoramentos ativos

Principais Recursos

• 🔄 Arquitetura de Motor Duplo: Escolha entre estratégias de correlação por Varredura por Janela de Tempo (O(N log N)) e Baseada em Identidade (O(N log N)).
• 📊 Suporte Multi-Artigo: Correlacione Prefetch, ShimCache, AmCache, Logs de Eventos, arquivos LNK, JumpLists, MFT, USN, SRUM, Registro, Lixeira e muito mais.
• 🔌 Importação Universal: Importe saídas CSV/JSON/SQLite de qualquer ferramenta forense e converta em bancos de dados Feather.
• 🎯 Agrupamento Inteligente de Identidade: Variantes como Chrome.exe/chrome.dll/Chrome.EXE são unificadas em um único balde; versões e qualificadores de arquitetura permanecem distintos.
• 🕒 Timestamps Tolerantes: FILETIME, ISO 8601, epoch Unix (s/ms/μs), YYYYMMDD, barras no padrão americano e strings anotadas são todos analisados corretamente na primeira tentativa.
• 📈 Fan-Out Multi-Timestamp: Listas de timestamps JSON (Prefetch run_times) expandidas para que cada execução receba seu próprio evento de correlação.
• 🧰 Fonte Única de Verdade: Sinônimos de campos em config/standard_fields/*.json; metadados por tabela em correlation_engine/config/feather_schemas.json — estenda editando JSON, não código.
• ⚡ Streaming + Thread-Safe: query_time_range_iter com memória O(1); caches feather protegidos por locks; pronto para correlação paralela.

Arquitetura do Sistema

O Motor de Correlação consiste em quatro componentes principais:

1. 🗄️ Feathers (Normalização de Dados)

Propósito: Transformar artefatos forenses brutos em um formato padronizado e consultável.

• Bancos de dados SQLite contendo dados de artefatos forenses normalizados — um feather por tipo de artefato (Prefetch, ShimCache, Logs de Eventos, …) com um esquema padronizado e metadados para consulta eficiente.
• Um formato universal que aceita dados de qualquer ferramenta 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 importação suportados:** CSV (qualquer arquivo com cabeçalho), JSON (plano ou aninhado) e SQLite (importação direta). Mapeamento automático de colunas, detecção de tipo de dados, normalização de timestamp para ISO, validação e índices otimizados.```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Wings (Regras de Correlação)

Objetivo: Definir quais artefatos correlacionar e como.

• Regras JSON/YAML que especificam uma janela de tempo, correspondências mínimas, prioridade de âncora e as feathers (com pesos) para correlacionar — reutilizáveis entre casos. Cada Wing é autorável e selado (registra quem o criou, por quê e a evidência que o motivou).```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 (Estratégias de Correlação)

**Objetivo**: Executar a lógica de correlação para encontrar relações entre artefatos. Os vínculos estruturais vêm **primeiro**; uma pontuação ponderada por camadas é sobreposta como *interpretação/ranqueamento*, não como base para uma correspondência.

**Mecanismo de Varredura por Janela de Tempo** — melhor para análise baseada em tempo e correlação temporal sistemática. Varre o tempo em intervalos fixos, coleta registros de todos os feathers por janela, aplica correspondência de campos semânticos + pontuação ponderada e evita duplicatas por meio do rastreamento de MatchSet. **O(N log N)** (consultas indexadas por timestamp); processamento em lote (~2.567 janelas/segundo).

**Mecanismo de Correlação Baseado em Identidade** — melhor para grandes conjuntos de dados (>1.000 registros) e rastreamento de identidade. Extrai e normaliza identidades, agrupa registros por identidade, constrói âncoras temporais dentro de cada cluster, classifica evidências como primárias/secundárias/de suporte e faz streaming para conjuntos muito grandes (>5.000 âncoras) com memória constante. **O(N log N)**; mais de 40 padrões de campos de identidade por tipo.

**Seleção do mecanismo:** use o mecanismo de Janela de Tempo para análise baseada em tempo e o mecanismo Baseado em Identidade para rastreamento de identidade — ambos estão prontos para produção e otimizados para grandes conjuntos de dados com consultas indexadas.

#### 4. 🔄 Pipelines (Orquestração de Fluxos de Trabalho)

**Objetivo**: Automatizar fluxos de trabalho de análise completos, da criação de feathers à geração de resultados. Um pipeline lê sua configuração (tipo de mecanismo, wings, feathers), instancia o mecanismo correto por meio do EngineSelector, executa cada wing, agrega correspondências, salva os resultados (DB + JSON) e os exibe na GUI com filtragem e visualização.```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"
  }
}

Como Tudo Funciona em 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

### Exemplo de Caso de Uso: Encontrando Provas de Execução

**Cenário**: provar que `malware.exe` foi executado em um sistema.```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

(no content provided)```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

I don't see any content to translate in the input. Please provide the text for chunk 20 of 25.```
Identity: malware.exe
  Anchor 1 (2024-01-15 10:30:00):
    ✓ Prefetch: malware.exe executed at 10:30:00
    ✓ ShimCache: malware.exe modified at 10:30:15
    ✓ AmCache:  malware.exe installed at 10:29:45

  Conclusion: Execution proven with 3 corroborating artifacts

Benchmarks de Desempenho

Começando com o Mecanismo de Correlação

1. Inicie: python -m correlation_engine.main
2. Crie Feathers: importe seus artefatos forenses (Prefetch, ShimCache, …).
3. Crie Wings: defina regras de correlação para sua investigação.
4. Crie um Pipeline: configure quais wings e feathers usar.
5. Execute: execute o pipeline e visualize os resultados correlacionados.
6. Analise: use o Visualizador de Resultados para explorar relações temporais.

📚 Documentação do Mecanismo de Correlação

• Visão Geral do Mecanismo de Correlação — visão geral do sistema com diagramas de arquitetura
• Documentação do Mecanismo — arquitetura de mecanismo duplo, seleção de mecanismo, otimização de desempenho
• Arquitetura — integração de componentes e fluxo de dados
• Documentação de Feather — o sistema de normalização de dados
• Documentação de Wings — regras de correlação
• Documentação de Pipeline — orquestração de fluxo de trabalho
• Adicionando um Artefato — o fluxo de trabalho para conectar um novo parser ao mecanismo
• Registro de Campos Padrão — sinônimos canônicos de nomes de colunas carregados por ambos os mecanismos e pelo Eye
• Guia de Contribuição — como contribuir com o mecanismo
• Links rápidos: Seleção de Mecanismo · Solução de Problemas · Otimização de Desempenho

👁️ Eye — O Assistente de IA Forense

Um assistente poderoso, não um substituto. O Eye automatiza e verifica as hipóteses de um investigador — ele nunca decide por você.

O Eye é o assistente de IA forense integrado do Crow-Eye: um investigador forense qualificado apoiado por uma base de conhecimento real de artefatos do Windows. Ele oferece uma interface em linguagem natural para consultar, correlacionar e documentar tudo em um caso — Prefetch, MFT, Registry, Event Logs, AmCache, ShimCache, SRUM e mais — mantendo um registro auditável e à prova de adulteração exatamente do que fez. O Eye pode ser executado inteiramente em seu próprio hardware (incluindo totalmente isolado de rede), alinhado à postura de privacidade do Crow-Eye de "0 ms de dados enviados para fora do dispositivo". Arquitetura completa: eye/README.md.

O Eye transforma perguntas conversacionais ("mostre-me o que foi executado a partir de C:\Temp após as 22:00") em trabalho forense real: ele planeja uma abordagem, recupera conhecimento relevante dos artefatos, executa SQL e buscas entre artefatos em seus bancos de dados de caso e sintetiza uma resposta validada. Cada resposta é produzida em dois lugares ao mesmo tempo — uma resposta no chat para você e um bloco estruturado gravado em um Espaço de Trabalho de Relatório Vivo, para que o dossiê se construa sozinho à medida que a investigação avança.

O Protocolo Ghassan Elsman (GEP)

Tudo o que o Eye faz está ancorado no Protocolo Ghassan Elsman (GEP) — um padrão neutro em relação a fornecedores e independente de ferramentas sobre como qualquer IA deve ser usada na forense digital. São 10 princípios que um sistema em conformidade deve cumprir para que as descobertas assistidas por IA permaneçam verdadeiras, rastreáveis até os registros de origem e respaldadas por uma cadeia auditável e à prova de adulteração, com o investigador humano no controle:

O Eye do Crow-Eye é a implementação de referência do GEP; os comportamentos dentro do produto que o sustentam são as Regras Operacionais. 📜 Leia o padrão: eye/docs/GEP_standard.md.

Modos de Implantação

O Eye se adapta ao seu modelo de ameaça por meio de três modos de implantação:

No modo CLI-agent, o Crow-Eye utiliza um agente de terminal/linha de comando de IA existente como o modelo — em vez de uma API na nuvem ou um servidor offline local — para que você possa investigar com o agente que já utiliza.

O ciclo de investigação:

1. Abra ou crie um caso — o Eye se limita aos bancos de dados de artefatos e ao histórico desse caso.
2. Faça uma pergunta em linguagem natural ou inicie uma triagem abrangente com um clique.
3. O Eye executa seu pipeline — detectar intenção → recuperar conhecimento → executar ferramentas → sintetizar.
4. Você recebe uma saída dupla — uma resposta direta no chat e um novo bloco no Relatório Vivo.
5. Aprove ações restritas — exportações e outras etapas críticas aguardam sua aprovação.

Você pode trocar de modelo em tempo de execução com a ferramenta switch_model. A troca é restrita ao mesmo backend, para que as evidências nunca sejam enviadas silenciosamente a um provedor diferente daquele que você escolheu.

Rastreando o Processo de Raciocínio do LLM

O Eye foi projetado para que você possa ver — e depois comprovar — como ele chegou a uma conclusão. Conforme o Eye trabalha, ele transmite atualizações estruturadas de ThinkingStep para a interface em tempo real; cada uma carrega um step_id, type, label legível por humanos, status (active → done, ou error) e tool/params/detail opcionais.

Uma consulta típica se desenrola como thinking → rag → thinking → tool_call → synthesis, e todo caso mantém artefatos de rastreamento em disco que você pode inspecionar posteriormente:

Execução de Ferramentas

O Eye é orientado a ferramentas: o modelo nunca toca nas evidências diretamente. Ele emite chamadas de ferramentas, e o Eye as executa contra os bancos de dados do caso e retorna os resultados — para que cada ação seja explícita, registrada e reproduzível. As ferramentas são definidas em configs/llm_config.json e despachadas por meio de eye/services/context_manager.py.

Ferramentas investigativas — leem e analisam evidências:

Ferramentas de relatório constroem o Espaço de Trabalho de Relatório 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 e export_report (a exportação exige aprovação humana).

Ferramentas de autoria (governadas — veja Construindo Correlation Wings e Mapeamentos Semânticos): correlation_create_wing, correlation_edit_wing, correlation_create_semantic_mapping, correlation_edit_semantic_mapping. As chamadas de ferramentas são traduzidas para o que o backend ativo espera — chamada de função nativa para APIs na nuvem e servidores locais, ou um wrapper XML <tool_call> para agentes CLI.

Construindo Correlation Wings e Mapeamentos Semânticos

O Eye não apenas consulta o Mecanismo de Correlação — ele pode ajudar a estendê-lo. Quando o Eye identifica um padrão recorrente entre artefatos, ele pode propor novas Wings (regras de correlação) e Mapeamentos Semânticos (traduções técnico-para-humano). Isso é autoria governada: o Eye propõe, o analista revisa o artefato salvo, e toda alteração é justificada e respaldada por evidências.

Uma Wing une as feathers dentro de uma janela de tempo e um limite mínimo de correspondências para comprovar uma afirmação:

Um Mapeamento Semântico traduz um valor técnico bruto em significado legível por humanos (ex.: EventID 4624 → "Logon Bem-sucedido"). Ele vem em duas variações: um mapping simples (valor único/regex → valor semântico) ou uma rule com múltiplas condições (condições unidas por AND/OR). Ambos suportam category, severity, confidence e scope, e ambos exigem reason + related_evidence.

Governança — regras do lado de escrita que sustentam o GEP:

• Reason-Required (sustenta GEP-9 + GEP-2): toda criação e edição deve incluir um reason forense.
• Evidence-Link (sustenta GEP-2): toda criação deve citar pelo menos uma referência database:table:rowid.
• Eye-Stamped / somente leitura para outros (sustenta GEP-7 + GEP-9): o Eye carimba sua autoria + reason + histórico de edições e pode editar somente o que o Eye criou — regras integradas e criadas por humanos permanecem somente leitura.

Contexto Autocurável

Investigações longas podem exceder a janela de contexto de um modelo — especialmente modelos offline menores. Em vez de falhar ou descartar evidências silenciosamente, o Eye autocompacta seu próprio contexto antes de cada chamada ao modelo (dentro de seu caminho de geração protegido, totalmente auditado).

Antes de cada chamada, o Eye mede o payload completo e reserva espaço para a resposta (10% da janela, mínimo de 512 tokens, nunca mais da metade). Se ainda assim não couber, ele se auto-recupera em duas passagens ordenadas, nunca tocando em mensagens protegidas (fixadas, evidências detectadas automaticamente ou um resultado de ferramenta):

1. Passagem de resumo (uma vez) — o histórico não protegido colapsa em um único resumo, registrado como SUMMARIZED.
2. Passagem de descarte — a mensagem não protegida mais antiga é removida uma a uma até caber, registrada como TRUNCATED.

Se o núcleo de evidências irredutível (fixadas + resultados de ferramentas + a pergunta atual) ainda transbordar, o Eye se recusa a prosseguir em vez de truncar evidências (REFUSED_OVERFLOW) e pede que você restrinja a consulta ou use analyze_large_dataset. O que quer que finalmente vá para o modelo é exatamente o payload que é selado para a cadeia de custódia.

🗺️ Mapa Narrativo — A Memória Persistente de Caso do Eye

O Eye é sem estado entre as interações — então o Mapa Narrativo é onde "o que sabemos e o que concluímos" vive para um caso. É a memória de trabalho persistente, auditável e à prova de adulteração do Eye, e seu conteúdo é injetado no prompt do Eye a cada interação (o mapa literalmente é a memória).

• 🧭 Veredito → Narrativa → Evidência. Uma hierarquia estrita: um Veredito por caso, as Narrativas abaixo dele (afirmações, cada uma com um estado — proven · open · negative · needs · absolute) e as Evidências respaldadas por artefatos abaixo delas.
• 🪟 Uma janela própria. Abre pelo botão "Mapa Narrativo" na janela de chat do Eye, para que você possa acompanhar o chat, o relatório vivo e a memória do caso lado a lado; ele é atualizado ao vivo conforme as coisas mudam.
• ↔️ Bidirecional — uma memória que você comanda. Tanto as edições do Eye quanto suas próprias anotações passam por um único commit validado pelo GEP e são seladas em um log de auditoria encadeado por hash (narrative_map_audit.jsonl). Você pode adicionar, editar e remover suas afirmações e evidências, moldando diretamente como o Eye entende e interpreta o caso.
• 🚫 Nunca afirma o que não é sustentado. Uma narrativa do Eye pode permanecer open sem evidências enquanto investiga, mas nunca pode ser proven sem evidências; um tema que o Eye verificou, mas encontrou vazio, é convertido automaticamente para negative — porque uma ausência documentada é, por si só, uma descoberta.

Como a Conformidade Funciona

A conformidade não é um recurso acoplado por cima — ela é aplicada no pipeline.

• 🔗 Cadeia de custódia (Selo de Evidência). Todo payload que o Eye envia a um LLM é selado: o SHA-256 dos bytes exatos, a contagem de tokens, o modelo + seu limite de contexto e a proveniência de cada linha de evidência (database:table:rowid, além de offsets calculados para registros MFT). Os selos são somente anexação e encadeados por hash em <case>/EYE_Logs/eye_payload_seal.jsonl — um único registro alterado ou removido quebra a cadeia, então o log prova matematicamente quais bytes o modelo analisou.
• 🚫 Sem truncamento silencioso. Quando o contexto fica apertado, o Eye se auto-recupera e realoca orçamentos em uma ordem estrita: Prioridade 1 (Imovível): Evidências Brutas + o Prompt do Sistema › Prioridade 2 (Sacrificável): Conversa Casual › Prioridade 3 (Flexível): Contexto RAG. Se o núcleo de evidências ainda não couber, o Eye se recusa em vez de descartar evidências silenciosamente.
• 🧾 Trilha de auditoria de truncamento. Toda decisão de contexto é registrada em <case>/EYE_Logs/truncation_audit.log (SUMMARIZED, TRUNCATED, PRESERVED, PINNED, UNPINNED, BUDGET_REDUCED), cada uma com um hash. Evidências detectadas são fixadas automaticamente acima de um limite de confiança; você também pode fixar mensagens manualmente.

📖 Arquitetura completa do Eye: eye/README.md.

📖 Eye-Describe — Base de Conhecimento de Artefatos em Nível de Byte

🔗 Explore o Eye-Describe → crow-eye.com/eye-describe

Historicamente, os investigadores caíram na armadilha de confiar em suas ferramentas forenses sem entender como os artefatos subjacentes se comportam ou como a ferramenta os analisou. O risco hoje é simplesmente substituir "a ferramenta" por "a IA". Uma IA pode analisar um registro com precisão técnica perfeita e ainda assim colocá-lo no contexto errado — mudando todo o significado da evidência.

O Eye-Describe existe para que nem o humano nem o modelo precisem adivinhar. É uma referência interativa, em nível de byte, para as estruturas binárias brutas dos artefatos do Windows, e atende a dois papéis ao mesmo tempo:

Ao ancorar a camada de IA ao comportamento documentado dos artefatos, o Crow-Eye não está pedindo que você confie em um modelo — está restringindo o modelo a respeitar a forense bruta.

Não troque a confiança na ferramenta pela confiança na IA. Entenda os dados.

🧪 Qualidade e Validação

Ferramentas forenses só são úteis se sua saída puder ser defendida. O trabalho de correção do Crow-Eye é deliberadamente visível:

• Suítes de regressão. O Mecanismo de Correlação é assegurado por uma suíte pytest que cobre análise de timestamps, normalização de identidade, fan-out multi-timestamp, o contrato do writer, autoria do Eye (governança GEP do lado de escrita) e o registro de campos padrão. O mecanismo UBA inclui sua própria suíte, incluindo uma execução de ponta a ponta contra um caso real.
• Harness de validação. Um harness holístico exercita todas as 7 wings padrão contra ambos os mecanismos em um caso Windows real com ~700K registros.
• Histórico publicado de defeitos. Regressões de precisão e seu impacto medido são documentados abertamente em RELEASE_NOTES.md — incluindo casos em que uma correção alterou os registros vistos em ordens de magnitude. Saber o que estava errado, e quando, faz parte do que torna um resultado defensável.
• Contabilidade de evidências verificável. Todo registro ou cai em uma correspondência ou em um bucket de descarte nomeado, e o registro de descartes por janela torna "nenhuma evidência sobrando" algo que você pode verificar no log em vez de aceitar por fé.
• Logs à prova de adulteração. verify_chain() percorre novamente o log de auditoria do Mapa Narrativo e a cadeia do Selo de Evidência para detectar modificações — inclusive em campos legíveis por humanos.

🔬 Plataforma de PesquisaCrow-Eye é mais que um software — é uma plataforma aberta de pesquisa que acelera todo o campo da forense Windows. O projeto tem como foco:

• Publicar documentação detalhada sobre as estruturas internas dos artefatos.
• Compartilhar lógica de correlação e metodologias.
• Possibilitar revisão por pares, transparência e colaboração acadêmica.
• Contribuir para o conhecimento coletivo da comunidade forense.

🛠️ Notas técnicas

• O parsing do registry requer arquivos de hive completos.
• Alguns artefatos exigem tratamento especial devido aos mecanismos de bloqueio de arquivos do Windows (veja Registry personalizado / arquivos bloqueados).
• O parsing de LNK e Jump List é tratado pelo parser dedicado do próprio Crow-Eye.

📸 Capturas de tela

Uma seleção das visualizações de interface e análise do Crow-Eye.

🎥 Vídeo de demonstração:

🚧 Roteiro

Trabalhos planejados e em andamento (veja RELEASE_NOTES.md para as alterações já lançadas):

• 📊 Visualizações e relatórios GUI avançados — visualização e relatórios mais ricos.
• 🔄 Diálogo de pesquisa aprimorado — filtragem avançada com suporte a linguagem natural.
• 🎯 Mapeamento semântico aprimorado — mapeamento abrangente de campos em todos os tipos de artefatos.
• 📈 Pontuação de correlação avançada — pontuação de confiança refinada e explicável.
• ⚡ Correlação paralela — despacho por pool de processos, habilitado por padrão para grandes cargas de trabalho.

Tem uma ideia ou quer adicionar um artefato? Abra uma issue ou veja Contribuindo.

📚 Documentação

• TECHNICAL_DOCUMENTATION.md — arquitetura, componentes e guia de desenvolvimento.
• RELEASE_NOTES.md — o que há de novo em cada versão (UBA, Narrative Map, backends cloud do Eye, fortalecimento do gerenciamento de casos, …).
• Documentação do Correlation Engine — visão geral, engine, feathers, wings, pipelines.
• Arquitetura do Timeline — detalhes internos do módulo timeline.
• Arquitetura do Eye e padrão GEP — o assistente de IA e seu protocolo de governança.

🤝 Contribuindo

O Crow-Eye foi construído como uma plataforma aberta de pesquisa, e contribuições são bem-vindas — novos parsers, regras de correlação, documentação e pesquisa de artefatos.

• Contribuições gerais: CONTRIBUTING.md
• Correlation Engine (área prioritária): correlation_engine/CONTRIBUTING.md
• Contato: [email protected] · ou abra uma issue / pull request.

🌐 Site e comunidade

• 🌍 Site oficial: crow-eye.com — recursos, documentação e downloads.
• 💬 Discord: Entre no Discord do Crow-Eye — ajuda direta, pesquisa de artefatos e anúncios de lançamentos.

📄 Licença

O Crow-Eye é lançado sob a GNU General Public License v3.0 (GPL-3.0). É livre para usar, estudar, compartilhar e modificar sob os termos dessa licença.

📝 Como citar o Crow-Eye

Se você usar o Crow-Eye em trabalhos acadêmicos, pesquisas publicadas ou relatos de caso, cite-o:```bibtex @software{elsman_crow_eye, author = {Elsman, Ghassan}, title = {Crow-Eye: A Windows Forensics Engine}, url = {https://github.com/Ghassan-elsman/Crow-Eye}, license = {GPL-3.0}, year = {2026} }

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

Para citações metodológicas, o Protocolo Ghassan Elsman é documentado separadamente em [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md).

## 💖 Apoio

O Crow-Eye é gratuito e de código aberto, criado e mantido por uma pessoa. Se ele for útil para o seu trabalho, considere patrociná-lo — isso financia diretamente novos parsers e pesquisa: **[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**.

## Créditos

Criado e mantido por **Ghassan Elsman**.