The forensics community has a massive AI problem. Everyone is rushing to plug language models into their workflows to automate triage. But forensics requires absolute certainty. A language model is built to predict text, not to preserve a chain of custody. When you use a standard AI tool to analyze an endpoint, you are trusting a black box. If it hallucinates a single finding, your entire investigation is compromised.

We need to stop treating AI as an oracle that gives us the final answer. Instead, we must treat it as a heavily restricted junior analyst. It should do the heavy lifting of correlating massive datasets, but it must be mathematically forced to prove its work.

If we want to use AI responsibly in an investigation, we have to change the entire methodology:

Kill the Chat Window: A chat log is flat, unpredictable, and loses context rapidly. We need to use visual, node based workspaces where you can see exactly how a piece of evidence led to a specific conclusion.

Enforce Evidence Anchoring: The AI must be completely sandboxed. It should be programmatically blocked from generating any narrative unless that narrative maps directly back to the raw artifact row, like a specific registry key or Master File Table entry.

Immutable Auditing: Every time the AI touches the evidence, it needs to be cryptographically hashed. We need a permanent paper trail of exactly what the model saw and what it suggested, ensuring the whole process is court defensible.

This philosophy is exactly why we built the Narrative Map in the new 0.12.0 update for Crow Eye. We stepped back from just adding basic AI features and built a shared workspace. The AI is physically unable to mark a claim as proven without citing the exact underlying artifact. Every action is logged in a tamper evident chain. It shifts the power entirely back to the human investigator. The AI accelerates the deep parsing and correlation, but you hold the evidence and make the final call.

I want to know how the rest of the community is handling this. Are you trusting the output of commercial AI tools, or are you demanding to see the raw data behind their conclusions?

You can check out our approach and grab the open source release here: Website:https://croweye.com/

Code:https://github.com/GhassanElsman/CrowEye

Good hunting.

Hey everyone,
I’m trying to understand user behavior and workflows in the DFIR community right now. Assuming you’ve already completed your acquisition and standard artifact parsing, I have a few quick questions about how you actually spend your time and your thoughts on emerging tech:

1. When you are deep in a Windows investigation, trying to uncover malicious behavior or hunt advanced threats, what is the single most time-consuming task for you during the analysis phase?

2. If you use AI to help with this analysis, do you treat it strictly as a mechanical script/tool to automate tasks, or do you interact with it like an assistant—asking it direct questions and expecting auditable, step-by-step reasoning to validate its conclusions?
   For those using AI in your forensics workflow, do you feel you really understand how the underlying LLM works under the hood?
   Are you familiar with concepts like RAG (Retrieval-Augmented Generation) and how it applies to grounding AI answers in your evidence files, or are you currently treating these AI tools as a black box?

View Poll

Slapping an LLM onto a security tool without guardrails is a massive liability. In digital forensics and incident response (DFIR), an AI hallucination can ruin an entire chain of custody. An answer without mathematical, binary proof is completely worthless. If an AI agent cannot anchor its reasoning to exact offsets, hashes, and unmanipulated timestamps, it has no business touching forensic data.

With Crow-Eye v0.11.0, we are pushing a massive update to our full-spectrum forensic lifecycle platform. This release introduces a hardened AI compliance architecture and completely upgrades the core correlation engines.

We are treating the underlying intelligence layer like a highly supervised junior analyst. Everything it sees is hashed, everything it thinks is visible, its memory management is strictly audited, and its ability to alter rules is completely sandboxed.

Here is exactly how we are enforcing forensic integrity under the hood in v0.11.0:

1. AI Compliance & Governance

Evidence Seal & Cryptographic Chain of Custody

Every single time the AI interacts with your forensic data, it is cryptographically verified.

• The Process: Before any payload is passed to the AI model, the evidence_seal.py service steps in.
• Hashing & Provenance: It calculates the SHA-256 hash of the exact bytes being sent and attaches metadata tracking the absolute source (e.g., database:table:rowid), token count, and the specific AI model used.
• Hash-Chaining: This metadata is written to an append-only JSONL ledger. Each new record incorporates the hash of the previous record. If a single byte of historical evidence is tampered with, the entire cryptographic chain breaks instantly.

The TruncationAuditor Service (Context Auditing)

AI context windows are a massive compliance bottleneck. Silent truncation—where a tool quietly drops data when limits are exceeded—is unacceptable in an investigation. The TruncationAuditor service acts as a strict forensic bookkeeper to log exactly how history is modified during our Self-Healing Context routine.

• The Append-Only Audit Log: Events are permanently written to <case>/EYE_Logs/truncation_audit.log, tracking whether data was compressed (SUMMARIZED) or entirely removed (TRUNCATED).
• High-Fidelity Tracking: Every single dropped or compressed message records its unique Message ID, token count, reason (e.g., budget_exceeded), extra JSON metadata, and a SHA-256 Content Hash of the exact message text to mathematically prove what was removed.
• Tamper-Evident Hash-Chaining: Each log entry combines its content with the hash of the previous log line using a chain=... signature. If a rogue actor manually deletes a record from the text log to hide missed evidence, the chain breaks instantly, and the verify_chain() check fails.
• Protocol Compliance Panel: The auditor exports this ledger into a structured JSON array (audit_trail.json). The React UI reads this to give investigators a clean visual timeline of exactly what was preserved, summarized, or dropped.

https://preview.redd.it/7yysi31xgu5h1.png?width=3394&format=png&auto=webp&s=16032abda1bbbccd2986be1479e37a0c45ec5a69

The ThinkingStep Protocol (Anti-Black-Box Streaming)

The AI is hard-coded to "show its work." The ThinkingStep protocol bridges the Python backend (eye_bridge.py and query_processor.py) and the React frontend (EyeDialogue.tsx), streaming real-time updates over QWebChannel across 4 distinct, auditable phases:

• Phase 1: thinking (Intent Detection): The backend queries the LLM to determine intent (e.g., separating general questions from direct MFT queries). The UI displays "Analyzing request..."
• Phase 2: rag (Retrieval-Augmented Generation): The backend searches local forensic rules inside configs/knowledge_base/ (like pulling up Living off the Land tactics for PowerShell analysis) and shows you exactly what was fetched.
• Phase 3: tool_call (Execution): If the AI needs hard data, it sends a structured command to the backend to fire off a tool (e.g., executing a raw SQLite database query). The UI displays a dedicated "Tool Execution" block exposing the exact arguments, execution status, and raw JSON payloads returned. This layer loops sequentially if multiple tools are required. If a tool fails on a bad SQL query, the step turns red, exposes the raw Python exception, and allows the AI to catch the error in its context to heal and try a corrected query.
• Phase 4: synthesis (Final Generation): The backend bundles the RAG knowledge and tool results securely using the Evidence Seal, routing them to the model to stream out the final human-readable response.
• UI Transparency: In the frontend, these phases are rendered as interactive, collapsible accordion blocks. You can expand a tool block to verify every database query syntax or piece of documentation the AI used before arriving at its final conclusion.

Governance Enforcement Protocols (GEP Rules 9-11)

When the AI acts as an author (like generating correlation rules), it is locked down:

• Reasoning Required (R9): The AI cannot create or edit any rule without rendering a clear text justification.
• Evidence Linking (R10): The AI cannot hallucinate a rule. It must bind it back to the exact physical forensic artifact (related_evidence) that prompted it.
• Read-Only Built-ins (R11): The AI is strictly sandboxed from modifying human-authored rules or built-in system defaults.

2. Core Engine Upgrades

With the AI heavily supervised, v0.11.0 also delivers massive architectural upgrades to the data engines feeding the platform.

Advanced Core Correlation Engine Upgrade An adversary leaves footprints across multiple layers of the system simultaneously.

• Deep Artifact Stitching: Crow-Eye automatically maps the connective tissue between Master File Table (MFT) records, Registry hives, LNK files, and Jump Lists.
• Instant Timeline Reconstruction: The engine identifies non-obvious relationships instantly, allowing you to trace an execution lifecycle from initial file access straight to system persistence without manual cross-referencing.

Ironclad Identity Engine Upgrade Attributing actions to specific security identifiers (SIDs) in modern Windows 11 environments can get incredibly messy during high-stress triage.

• The upgraded Identity Engine brings precise, deterministic execution-context tracking. It resolves user sessions, elevation states, and mapped SIDs with absolute certainty, eliminating ambiguity during credential abuse investigations.

For the next release, I am focusing completely on user bugs and performance edge-cases. Please feel free to contact me for any bug reports or support queries you can find all of my direct contact details on the official website:https://crow-eye.com/

GitHub:https://github.com/Ghassan-elsman/Crow-Eye

for the full details of the Resale notes please check https://github.com/Ghassan-elsman/Crow-Eye/releases/tag/0.11.0

Good hunting,

Slapping an LLM onto a security tool without guardrails is a massive liability. In digital forensics and incident response (DFIR), an AI hallucination can ruin an entire chain of custody. An answer without mathematical, binary proof is completely worthless. If an AI agent cannot anchor its reasoning to exact offsets, hashes, and unmanipulated timestamps, it has no business touching forensic data.

With Crow-Eye v0.11.0, we are pushing a massive update to our full-spectrum forensic lifecycle platform. This release introduces a hardened AI compliance architecture and completely upgrades the core correlation engines.

We are treating the underlying intelligence layer like a highly supervised junior analyst. Everything it sees is hashed, everything it thinks is visible, its memory management is strictly audited, and its ability to alter rules is completely sandboxed.

Here is exactly how we are enforcing forensic integrity under the hood in v0.11.0:

1. AI Compliance & Governance

Evidence Seal & Cryptographic Chain of Custody

Every single time the AI interacts with your forensic data, it is cryptographically verified.

• The Process: Before any payload is passed to the AI model, the evidence_seal.py service steps in.
• Hashing & Provenance: It calculates the SHA-256 hash of the exact bytes being sent and attaches metadata tracking the absolute source (e.g., database:table:rowid), token count, and the specific AI model used.
• Hash-Chaining: This metadata is written to an append-only JSONL ledger. Each new record incorporates the hash of the previous record. If a single byte of historical evidence is tampered with, the entire cryptographic chain breaks instantly.

The TruncationAuditor Service (Context Auditing)

AI context windows are a massive compliance bottleneck. Silent truncation—where a tool quietly drops data when limits are exceeded—is unacceptable in an investigation. The TruncationAuditor service acts as a strict forensic bookkeeper to log exactly how history is modified during our Self-Healing Context routine.

• The Append-Only Audit Log: Events are permanently written to <case>/EYE_Logs/truncation_audit.log, tracking whether data was compressed (SUMMARIZED) or entirely removed (TRUNCATED).
• High-Fidelity Tracking: Every single dropped or compressed message records its unique Message ID, token count, reason (e.g., budget_exceeded), extra JSON metadata, and a SHA-256 Content Hash of the exact message text to mathematically prove what was removed.
• Tamper-Evident Hash-Chaining: Each log entry combines its content with the hash of the previous log line using a chain=... signature. If a rogue actor manually deletes a record from the text log to hide missed evidence, the chain breaks instantly, and the verify_chain() check fails.
• Protocol Compliance Panel: The auditor exports this ledger into a structured JSON array (audit_trail.json). The React UI reads this to give investigators a clean visual timeline of exactly what was preserved, summarized, or dropped.

https://preview.redd.it/7yysi31xgu5h1.png?width=3394&format=png&auto=webp&s=16032abda1bbbccd2986be1479e37a0c45ec5a69

The ThinkingStep Protocol (Anti-Black-Box Streaming)

The AI is hard-coded to "show its work." The ThinkingStep protocol bridges the Python backend (eye_bridge.py and query_processor.py) and the React frontend (EyeDialogue.tsx), streaming real-time updates over QWebChannel across 4 distinct, auditable phases:

• Phase 1: thinking (Intent Detection): The backend queries the LLM to determine intent (e.g., separating general questions from direct MFT queries). The UI displays "Analyzing request..."
• Phase 2: rag (Retrieval-Augmented Generation): The backend searches local forensic rules inside configs/knowledge_base/ (like pulling up Living off the Land tactics for PowerShell analysis) and shows you exactly what was fetched.
• Phase 3: tool_call (Execution): If the AI needs hard data, it sends a structured command to the backend to fire off a tool (e.g., executing a raw SQLite database query). The UI displays a dedicated "Tool Execution" block exposing the exact arguments, execution status, and raw JSON payloads returned. This layer loops sequentially if multiple tools are required. If a tool fails on a bad SQL query, the step turns red, exposes the raw Python exception, and allows the AI to catch the error in its context to heal and try a corrected query.
• Phase 4: synthesis (Final Generation): The backend bundles the RAG knowledge and tool results securely using the Evidence Seal, routing them to the model to stream out the final human-readable response.
• UI Transparency: In the frontend, these phases are rendered as interactive, collapsible accordion blocks. You can expand a tool block to verify every database query syntax or piece of documentation the AI used before arriving at its final conclusion.

Governance Enforcement Protocols (GEP Rules 9-11)

When the AI acts as an author (like generating correlation rules), it is locked down:

• Reasoning Required (R9): The AI cannot create or edit any rule without rendering a clear text justification.
• Evidence Linking (R10): The AI cannot hallucinate a rule. It must bind it back to the exact physical forensic artifact (related_evidence) that prompted it.
• Read-Only Built-ins (R11): The AI is strictly sandboxed from modifying human-authored rules or built-in system defaults.

2. Core Engine Upgrades

With the AI heavily supervised, v0.11.0 also delivers massive architectural upgrades to the data engines feeding the platform.

Advanced Core Correlation Engine Upgrade An adversary leaves footprints across multiple layers of the system simultaneously.

• Deep Artifact Stitching: Crow-Eye automatically maps the connective tissue between Master File Table (MFT) records, Registry hives, LNK files, and Jump Lists.
• Instant Timeline Reconstruction: The engine identifies non-obvious relationships instantly, allowing you to trace an execution lifecycle from initial file access straight to system persistence without manual cross-referencing.

Ironclad Identity Engine Upgrade Attributing actions to specific security identifiers (SIDs) in modern Windows 11 environments can get incredibly messy during high-stress triage.

• The upgraded Identity Engine brings precise, deterministic execution-context tracking. It resolves user sessions, elevation states, and mapped SIDs with absolute certainty, eliminating ambiguity during credential abuse investigations.

For the next release, I am focusing completely on user bugs and performance edge-cases. Please feel free to contact me for any bug reports or support queries you can find all of my direct contact details on the official website:https://crow-eye.com/

GitHub:https://github.com/Ghassan-elsman/Crow-Eye

for the full details of the Resale notes please check https://github.com/Ghassan-elsman/Crow-Eye/releases/tag/0.11.0

Good hunting,

If you are doing DFIR research, writing custom parsers, or if you're a student trying to understand what’s actually happening under the hood, you know how hard it is to find solid documentation on modern Windows 11 binary structures. Microsoft has made subtle changes, and staring at a wall of raw hex without context is a nightmare when you're trying to learn or build.

To fix that, I just pushed a major update to Eye Describe an educational hub specifically designed for researchers and students. I’ve fully mapped out the exact binary anatomy of 6 core Windows 11 artifacts, down to the individual byte.

• Byte-by-byte hex mapping of the structures (Headers, flags, data blocks, etc.).
• Visual layouts so you can actually see how the offsets connect instead of guessing.

https://preview.redd.it/bwkndczoiy1h1.png?width=1547&format=png&auto=webp&s=841bd17315f6d0e5685226d3cb3db75cce92732b

You can check out the interactive anatomy guides here:https://crow-eye.com/eye-describe

I'd love to hear your feedback on the layouts. For the researchers and students out there doing deep Windows 11 forensics: what artifacts or specific offsets are you struggling to find documentation for right now?

When I started building Crow Eye, I did not want to just add another tool to the pile. I wanted to build a full spectrum forensic lifecycle platform. This release is a massive step toward making that level of transparency a reality.

The Vision: A Definitive Hub for Students and Researchers While it is true that not every tool out there is a black box, the DFIR industry still relies heavily on automated parsers that hide their underlying logic. To truly understand an artifact, you have to get down to its physical binary structure.

https://preview.redd.it/aq6x31z1jp0h1.png?width=1785&format=png&auto=webp&s=1ae9a2ac4f5ccedb1d0e3bb0240e3f25d5bcb9ad

Whether you are a student learning digital forensics for the first time, or a dedicated researcher reverse engineering new artifacts, Eye Describe Anatomy is built to be your ultimate learning hub. This is where we map the ground truth. Our goal is to document everything we currently know about these complex binary structures and, just as importantly, openly share what we do not know yet. This gives researchers a solid starting point to help fill in the blanks.

On top of that, Eye Describe will serve as the official documentary for exactly how the Crow Eye parsers work under the hood. No more guessing how the tools reach their conclusions. You get to see the exact structural logic driving the platform.

What is Live Right Now I built an interactive UI that maps out the exact binary structures of critical Windows artifacts step by step. You can explore the raw hex, translate values, and read forensic deep dives for:

Main Hub : https://crow-eye.com/eye-describe

The Roadmap: Empowering The Eye AI As you might know, our recent release introduced The Eye, our robust intelligence layer for comprehensive investigative support. Looking ahead, we plan to feed the entire Eye Describe knowledge base directly into The Eye AI assistant. Instead of just querying external data, the AI will have native access to this structural textbook. This will help investigators with their research and allow the AI to accurately analyze new and evolving versions of these artifacts.

The Roadmap: Empowering The Eye AI As you might know, our recent release introduced The Eye, our robust intelligence layer for comprehensive investigative support. Looking ahead, we plan to feed the entire Eye Describe knowledge base directly into The Eye AI assistant. Instead of just querying external data, the AI will have native access to this structural textbook. This will help investigators with their research and allow the AI to accurately analyze new and evolving versions of these artifacts.

Crow Eye v0.10.1 EXE is Now Available!

To support this growing ecosystem, I am excited to share that the compiled executable for Crow Eye v0.10.1 is officially out.

GitHub : https://github.com/Ghassan-elsman/Crow-Eye

I am proud to announce the release of Crow-Eye v0.10.0. This milestone marks the official launch of The Eye a robust intelligence layer designed to integrate your own AI agents directly into Crow-Eye, This isn't just a regular update; it’s a massive milestone for us . My goal from day one has been to build an ecosystem that doesn't just chase known signatures, but actually gives investigators the power to hunt zero-days

But as we celebrate this release and introduce our new AI layer, we need to talk about the elephant in the room.

The Problem with AI in Forensics

There’s a huge rush right now to slap AI onto cybersecurity tools, and honestly, a lot of it is dangerous. We are seeing "black box" solutions where investigators feed raw data into an LLM and just trust the answers it spits out.

In DFIR, an AI hallucination can ruin a case. An answer without mathematical, binary proof is worthless. If an AI agent cannot anchor its reasoning to exact offsets, hashes, and unmanipulated timestamps, we cannot trust it. To fix this, I realized we had to architect a system where the AI is bound by the exact same strict evidentiary rules as a human analyst.

The Starting Line: Automated Triage

Before the AI even wakes up, Crow-Eye does the heavy lifting. When you launch The Eye, the platform immediately runs a high-speed Automated Triage phase.

It queries the underlying SQLite databases to map out the ground truth: active users, execution histories, accessed files, USB devices, and Auto Run configs. This builds a comprehensive Initial Report. This report isn't the final investigation it’s the baseline. It’s the verified starting line before we let the AI touch the data.

The Brain of "The Eye"

I believe you should have total control over your data and your analytical "brain." That’s why The Eye is completely modular. You can plug in whatever intelligence fits your environment:

• Cloud AI Models: Hook up your public API keys for high-performance reasoning.
• Offline Servers & Local Inference: For air-gapped labs where privacy is non-negotiable.
  • Dev Note: A lot of my testing and development for The Eye was actually done using LM Studio and Google’s open-weights models (like the Gemma family). If you're a solo investigator, running Gemma locally on your own machine is incredibly powerful. Just a tip: push your context window as high as possible to handle the dense forensic payloads!
• CLI Agents: If you are a developer or researcher, you can hook up your own custom-built local agents, or seamlessly pipe in tools like Claude Code and the Gemini CLI.

https://preview.redd.it/zdg32192ic0h1.png?width=2023&format=png&auto=webp&s=a1458500b3765ccb1a7fb4018a9dcd2203bd7a1a

Keeping the AI Honest: The Ghassan Elsman Protocol (GEP)

Triage gives us the data, but the Ghassan Elsman Protocol (GEP) ensures the AI doesn't mess it up. The GEP is a strict set of rules hardcoded into the workflow to maintain a perfect chain of custody:

1. Case Awareness: The Initial Report is injected directly into the prompt to ground the AI in reality.
2. Pre-Flight Ping: Validates backend connectivity to stop silent failures.
3. Evidence Anchoring: Automatically tags and preserves raw hashes, IPs, and timestamps in the chat history.
4. Chain of Custody: Every truncation or data preservation event is meticulously logged.
5. Non-Repudiation: Messages are assigned deterministic, hash-linked IDs so records can't be altered.
6. Context Pinning: Critical evidence is locked and excluded from automated AI summarization.
7. Tool Traceability: Every tool the AI uses (like querying LOLBAS) is logged with exact execution counts.
8. Machine-Readable Synthesis: You get a clean JSON audit trail at the end to prove compliance.

What's Next: Bridging Analysis and Anatomy

While The Eye handles the high-speed analysis, our educational hub, Eye Describe, In upcoming updates, we are going to start building a bridge between these two tools. The goal is to gradually integrate visual references alongside the AI's findings. We want to reach a point where the AI doesn't just give you an answer, but helps point you toward the structural anatomy of the artifact it analyzed. It’s an iterative, ongoing project, but we believe it is an important step toward total forensic transparency.

This is the very first release of The Eye. You might hit a few bumps connecting to certain local backends or managing specific CLI tools, but we are actively squashing bugs and refining the experience over the next few weeks. Please submit any issues you find!

The latest source code and release are available right now on our GitHub. For those waiting for the compiled .exe version, it will be dropping very soon on our official website.

GitHub : https://github.com/Ghassan-elsman/Crow-Eye

good hunting