Crow Eye User Guide

Crow-Eye at a Glance

This map shows everything Crow-Eye can do and the order you'll usually work in — from starting a case, to loading evidence, analysing it, asking the Eye, and producing a report. Click any card (or press Enter) to see what it does, which button opens it, and how to use it.

Tip: click (or tap) any card above for a full explanation. Press Esc to close.

Installation

Crow-Eye is designed to be as portable and low-impact as possible. You can run it directly from source or use the executable.

python "Crow Eye.py"

Video Demonstration

Correlation Engine Guide

The Future of Open Source Forensics

Offline Analysis & Image Parsing

Live Analysis reads the machine Crow-Eye is running on. Everything else — a folder of artifacts collected from another machine, or a forensic image of its disk — comes in through the Offline analysis section of the left sidebar. The evidence is copied into the case and parsed by the offline parsers, so the original source is never written to.

1. The four Offline analysis buttons

2. Offline Importer — SCAN, COLLECT, PARSE

The window is titled Crow-eye Offline - Artifact Collector. With a case open, it starts on the case’s live_acquisition folder.

1. Choose the source. Browse offers Scan Folder or Select Files; with Select Files only the chosen files are scanned or collected, and choosing a folder afterwards replaces that selection. The type filter narrows the scan (All Types, Registry Hives, Prefetch Files, Jump Lists, Event Logs, MFT Files, USN Journal, Recycle Bin, AmCache, ShimCache, SRUM, Browsers). Four options: include subdirectories (on), calculate SHA-256 hashes (on), incremental scan, which keeps the existing scan index (off), and include browser cache (on).
2. SCAN previews what is there. It detects artifacts and lists them with their type, path, size and hash — nothing is copied and nothing in the source is changed. With hashing on, each file is read once to compute its SHA-256, so a scan of a large source takes longer than a directory listing.
3. COLLECT detects and copies in one pass into <case>/live_acquisition/, one folder per artifact type (Registry_Hives, Prefetch, C_AJL_Lnk, EVTX_Logs, SRUM_Data, MFT_USN…). A user’s hives, LNK files and Jump Lists keep their owner’s Users\<name>\ folder, and a hive keeps its .LOG1/.LOG2 files beside it. Browser profiles keep their whole folder tree, under live_acquisition/Browser/, because only the folders above a History file say which user, browser and profile it belongs to. A file whose SHA-256 is already in the case is listed as already in the case — skipped, not failed. It needs an open case, and the source cannot be the case folder itself. After a SCAN, Collect Artifacts copies the scanned files the same way a direct COLLECT does, in the background. The found / copied counters move as it runs; files that cannot be copied are named and the run reports completed with N error(s). Cancel stops after the current file and keeps everything copied so far, indexed and ready to parse.
4. Parse Artifacts opens Parse Offline Artifacts: one tab per detected type, each with Select All and a list showing whether each file is already parsed. Choose files and click Parse Selected.

Parsing straight after COLLECT. With Settings → Parsing → Parse automatically after collection on (the default), a COLLECT is followed at once by a parse of exactly the files it brought in — the same parse as the button, so the tabs load and the Parse Status report opens as usual. A SCAN never parses; it stops at a ready Parse Artifacts button. Turn the setting off to review what was collected before parsing: COLLECT then ends with the Parse button ready.

Every scan and collection is recorded in the case’s scan index, which is what lets Parse Artifacts open with the discovered files already listed by category.

Files are recognised by name. The importer does not need a particular folder layout: a KAPE target, a Velociraptor collection or a hand-made copy all work, as long as the files keep their Windows names. The one exception is ShimCache, noted in the table. Browser files are recognised by where they sit instead — inside a browser profile folder (a Chromium User Data folder, a Firefox-family folder, or an Electron app’s storage) — and the <name>\AppData folder above it says whose profile it is. Keep that part of the path: without it a Chromium or Firefox profile is still parsed, but under an _unattributed_ user, and Electron app storage is not recognised.

3. Forensic images

Forensics Images opens Forensic Image Parsing. It needs an open case. The image is read in place with the dissect framework — no mounting, and nothing is written to it.

1. Image Source. Select the image. For a split image, select all of its segment files. Supported: E01 / Ex01, VHD / VHDX, VMDK, ISO, and raw images (.dd, .raw, .img, .001).
2. Partitions & Format. The detected format and every partition, with its file system and size. All are ticked; untick the ones you don’t need.
3. Extraction Settings. Leave Type on All Types, or pick a single artifact type. Include browser cache (on) also extracts the browsers’ HTTP and Service Worker caches, which are most of a profile’s size; history, cookies, downloads and the other browser tables are extracted either way. Keep Calculate Hashes and Parse automatically after extraction ticked to have the extracted files parsed straight away (that box starts as Settings → Parsing → Parse automatically after collection says, and can be changed for one run). Click Start Analysis.
4. Execution Status and the Real-Time Log show progress — current operation, files found and extracted, elapsed time. Progress also appears on the Windows taskbar.
5. Extracted Data & Actions lists every extracted file. Parse Artifacts parses them if auto-parse was off; Export Results saves the list as CSV.

What is extracted: the system hives (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT, COMPONENTS, DRIVERS, BBI and ELAM) with their .LOG1/.LOG2 transaction logs, the RegBack copies of SYSTEM, SOFTWARE, SAM and SECURITY, every user’s NTUSER.DAT and UsrClass.dat (plus the LocalService and NetworkService profiles) with their logs, Prefetch, AmCache with its logs, LNK files and Jump Lists, $MFT, the USN Journal ($UsnJrnl:$J), the Recycle Bin, SRUM with its ESE logs, the System, Application and Security event logs, and every user’s browser profiles (Chromium family, Firefox family and Electron apps) with their folder tree intact. Volume Shadow Copies inside the image are not currently searched, so a file that cannot be read from the volume is not recovered from an earlier snapshot.

4. Crow-Claw Collector

Crow-Claw - Artifact Acquisition Tool collects the same artifact set from the running machine in two steps: Configure (choose artifacts, add custom paths) and Collect (Start Collection). Each file is copied normally first; if that fails and Crow-Claw is elevated, it falls back to a Volume Shadow Copy and then to a raw volume read, which is how locked files such as the registry hives are reached. Every collection writes a collection_manifest.json (View Manifest) next to the files. Browser profiles are collected last, after $MFT and the USN Journal, so the largest artifact cannot fill the drive first.

5. Parsing, and what happens after

• Parse Offline Artifacts parses what has been collected into the case. If nothing has been scanned yet but the acquisition folder has files, it scans and parses them in one step — without asking when Parse automatically after collection is on, after a question when it is off.
• Parsers run in a fixed order — LNK & Jump Lists, Registry, Prefetch, Event Logs, ShimCache, AmCache, Recycle Bin, SRUM, Browsers, MFT, USN — and write their databases to <case>/Target_Artifacts/, the same place a live parse does.
• The parsed tabs reload, then the Parse Status Report opens: one row per artifact with its status, the records the run read, how many were New and how many were Already present, the reason, and a Mode column reading Live system, Offline artifacts or Forensic image. A failed or partial row expands to the error, the parser’s own warning and error lines (with the traceback) and the database rows before and after; Show parser log opens that artifact’s log. Reopen the report from Case → Parse Status Report….
• Parsing again adds only what is new. Run Parse All twice on the same machine and the second run stores the rows that appeared since, and nothing twice: the report reads, for example, 1,024 record(s) read: 12 new, 1,012 already in the case. Earlier rows are never deleted, so event logs and browser history that have since rolled out of the machine stay in the case. Cases parsed before this release keep any duplicates they already hold. The chain-of-custody record lists the new and already-present counts per artifact.
• An empty table gets a Why empty? button that says whether the artifact was absent, unsupported or failed. A missing artifact is not a failure — plenty of machines never create some of them.
• Every parse is logged under <case>/logs/ and browsable in Settings → Logs.

6. Live versus offline

Database Search

Database Search looks for a term in every parsed database of the case at once — every table, every column, imported evidence included — and lists the matching rows with where each was found. A very broad term can hit limits: each database’s search stops after 60 seconds, very large result sets are capped per table, and the screen does not say when this happens. If a search returns a lot, narrow the term or the tables you tick.

1. Opening it

Click Database Search in the top bar, or press Ctrl+Shift+F. A case with parsed data must be open. If Crow-Eye is still parsing or loading, the button offers Open when ready and opens the search as soon as the work finishes. If a parse starts while the search is open, a banner appears and searching pauses until the data is complete.

2. The search term and its options

• Type the term and press Enter or click Search. By default the match is case-insensitive and partial: temp finds C:\Users\Ann\AppData\Local\Temp.
• Case Sensitive distinguishes upper and lower case. Without a time period, * and ? in a case-sensitive partial search act as wildcards; with a time period they are matched literally. A case-sensitive partial search currently finds nothing if the term contains \ _ % [ or ] (for example C:\Users or run_count), so untick Case Sensitive for such terms.
• Exact Match matches only a field whose whole value equals the term. It is not applied while the Time Period Filter is on: a time-filtered search always matches partially.
• Use Regex also appears in the Options row, but it currently has no effect on matching: the term is still searched as plain text. The pattern is only checked for validity and recorded in history and exports.
• Recent lists your recent searches for this case, newest first, with their options and time filter. Picking one fills in the term, options, selected tables and time range; press Search (or Enter) to run it again.

3. What gets searched

Every database in the case is discovered automatically and shown as a tree — category, then artifact, then table — with everything ticked. The categories are Execution Evidence, Registry Evidence, File System Evidence, System Information, System Resource Usage, Browser Activity, Imported Evidence and Custom/Other Artifacts.

• Select All, Deselect All, or Select Loaded — only the databases whose tabs are loaded in the main window.
• Each entry shows its status (Loaded, Not Loaded, or Not Available), and a clock icon marks tables that have timestamp columns.
• Narrowing the tree is the fastest way to speed a search up: there is no index, so every ticked table is read in full.

4. Time Period Filter

Tick Time Period Filter and set Start and End to keep only rows inside that window. Timestamp columns are picked per table by name (the time columns the Timeline already knows, plus time-like names such as created, modified or last_…), then confirmed by sampling their values (ISO dates, Unix time, FILETIME and similar).

While the filter is on, the Results gain a Timestamp column showing the matched times. Within each database, tables with no timestamp column are left out — but only if at least one of the tables being searched there has one. If none of them does, that database is searched without the time filter: its hits show N/A in the Timestamp column and may fall outside the window.

5. Results

• Each hit is one row: Database, Table, Matched Columns, and a Preview of the matched values. A summary line reports how many results were found and how long the search took.
• Double-click a result for Row Details — every field of the row, plus the database, table and row ID it came from — with Copy to Clipboard and Export.
• Export saves the whole result set as CSV (with the search parameters recorded at the top), JSON (grouped by database and table) or an HTML report.
• Cancel stops a long search once the current database is finished (with the time filter on, once the current table is finished). Nothing found up to that point is shown.

Timeline and Charts: Two Ways to See Time

Crow-Eye has two kinds of visualization. The Timeline Visualization puts the whole case on one time axis. The Charts dashboards each take one artifact family and read it in depth. They answer different questions, and an investigation usually needs both.

1. The Timeline Visualization

Open it from Timeline Visualization in the top bar. It needs parsed data, but no correlation run — it reads the case databases directly. Every time is shown in UTC.

• Heatmap — the Global Case Overview: one calendar cell per day, shaded by activity. Hover over a day for its Day Details (total artifacts, peak hour, most active source, per-source breakdown); double-click it to open that day in 24H Detail.
• Week — Weekly Distribution: seven day columns of stacked activity. Each column lists that day’s top five artifacts with their first and last seen times; click a column to open that day in 24H Detail.
• 24H Detail — the lanes view. Six lanes: Sessions / Power, SRUM App Usage, SRUM Network, MFT / USN, Browser Activity and Unified Artifacts (LNK, Prefetch, BAM, Registry, USB, Recycle Bin and the rest). Zoom from a whole day down to 100 ms with the −/+ buttons or Ctrl+wheel; the left/right arrow keys pan.

• It plots 18 artifact types plus imported evidence. Toggle pills switch sources on and off, and a search box finds events, files and applications in the loaded window.
• Click an event for Event Details; Open Original (or double-clicking the event) opens every field the timeline loaded for that event in a detail window. Double-click a lane label to list that lane’s artifacts in the loaded window (browser events are listed under Unified Artifacts).
• Analytical Links join events with the same name from different sources within 30 seconds of each other — the Prefetch run, the LNK file and the USN write of one program, for example.
• Registry key write times are drawn as hollow markers: a key’s write time is an upper bound for the values under it, not the moment each one changed. Most are behind the Registry key times (<=) pill, which starts off.

2. The Charts dashboards

A Charts button sits above an artifact table, to the left of Anatomy where the table has an Anatomy page. It opens the dashboard for that table’s artifact family.

Every dashboard draws a day strip with one cell per day, including the empty ones, six months at a time, with Previous / Next 6 months, Latest and an overview of the whole range to jump through. Drill from a day to an hour to an item; every item ends at its full source record, with passwords, cookie values and card data shown as present but withheld. An Insight that counts records opens a list of them, and each one opens its full record; tiles that are plain measurements, such as distinct users or the busiest app’s days, are not clickable.

The dashboards query the case in the background: Crow-Eye stays responsive and the loading screen keeps moving while a large case is read, and a view you have already opened comes back instantly until the case is parsed again.

3. The difference

Correlation Engine

The Correlation Engine is the core intelligence of Crow-Eye. It transforms isolated forensic artifacts into a unified investigative narrative.

1. Core Architecture & Terminology

Before configuring your first pipeline, it is essential to understand the two foundational pillars of the Crow-Eye architecture:

2. The Pipeline Manager

The Pipeline Manager is your initial configuration workspace, divided into case metadata and the data/logic builders.

B. Feather Creator (Data Ingestion)

The Feather Creator maps raw artifact outputs into the engine's high-speed query format. If you used Crow-Eye’s internal parsers previously, this step is automated.

C. Wing Creator (Forensic Rulesets)

Wings dictate the investigative hypothesis. Creating a new Wing involves three primary configuration areas:

3. Execution Engine

The Execution Engine is where your configuration is deployed against the data.

4. The Result Viewer

Interpret your findings through three comprehensive views:

Dynamic Linking Engine

In complex digital forensic investigations, analyzing raw artifacts—such as SIDs, MAC addresses, GUIDs, and AmCache SHA-1 hashes—often creates a bottleneck. The Dynamic Linking Engine operates as an automated semantic translator within the Crow-Eye platform. It dynamically enriches your data display by appending human-readable context directly into your analytical tables in real-time.

Accessing the Interface

Deploying the Intelligence

Once verified, click the primary "RUN DYNAMIC LINKING" button. The interface will close, and Crow-Eye will automatically refresh forensic views (LNK, USN, Event Logs), enriching data cells instantly.

Hashes in Crow-Eye: What Is Hashed, and Why

Several Crow-Eye columns hold something that looks like a file hash but is not one. Confusing them costs time, so this is the full inventory, grouped by what each hash is actually for.

1. Windows-supplied hashes inside artifacts

Windows computes these; Crow-Eye only reads and stores them. This is the only group that can be matched against threat-intelligence feeds, and only one entry in it is a hash of file contents.

2. Crow-Eye bookkeeping hashes

Computed by Crow-Eye purely to give a row a stable identity. They are never evidence and never describe file contents — entry_hash in particular is a 32-character MD5 that is easily mistaken for an executable's MD5.

3. Chain-of-custody integrity hashes

Computed by Crow-Eye over each evidence file it collects or imports, so you can show the copy you analysed is the copy that was acquired. All are read in chunks, so an arbitrarily large file never has to fit in memory.

4. The Eye's EvidenceSeal chain

A different job again: proving what the AI was shown. Each payload sent to the model is sealed, and the seals are chained so a record cannot be altered or removed without breaking the chain.

Eye AI Assistant

The Eye Assistant is your AI-powered forensic co-pilot. It allows you to interact with your case data using natural language, making complex investigations faster and more intuitive.

Getting Started with Eye

Forensic Toolset

Eye has direct access to several specialized forensic tools:

Troubleshooting

Encountering issues? Check these common solutions for the most frequent technical hurdles.