Open an investigation. Lists evidence objects in the read-only evidence root and records the chain-of-custody hash of each. Call this first.

Recompute every evidence hash and compare to the value recorded at case_open. Run at the end of an investigation to prove the originals were never modified.

Protocol hierarchy and top IP conversations for a packet capture.

Distinct DNS queries with counts.

HTTP requests with host, method, URI, and source IP.

SMTP envelope and mail header fields (sender, recipient, subject).

Targeted tshark extraction to test a specific hypothesis. display_filter is a Wireshark display filter; fields is a list of field names to extract. Example: display_filter="http.cookie", fields=["frame.number","ip.src","http.cookie"].

List partitions in a disk image (mmls).

List files in a disk image (fls). Optionally start at a partition offset or inode.

Find files by name anywhere in a disk image (e.g. name_pattern="webshell" or ".php" or "access.log"). Builds and caches a recursive listing so repeated searches on a large disk are fast. Returns matching paths with their inodes for fs_cat.

Read the content of a file by inode from a disk image (icat), read-only.

Generate a file system MAC timeline body and parse the most recent activity (fls -m + mactime).

Parse a Windows registry hive from a disk image with RegRipper (read-only). Find the hive's inode first with fs_find (e.g. fs_find image "SAM" or "SYSTEM"), then run a plugin: samparse (local accounts, find attacker-created users), profilelist, run / soft_run (Run-key persistence), services, winlogon, shimcache, usbstor, networklist.

Program-execution evidence from the SYSTEM hive's Application Compatibility Cache (Shimcache): paths and timestamps of binaries that ran or were present. Find the SYSTEM hive inode with fs_find first. Read-only via RegRipper.

Program-execution evidence from Amcache.hve: executed binary full paths and their SHA-1 hashes. Find the Amcache.hve inode with fs_find first. Read-only via RegRipper.

Process listing from a memory image (volatility3 pslist + pstree).

Network connections from a memory image (volatility3 netscan).

Injected or hidden code regions from a memory image (volatility3 malfind).

Process command lines from a memory image (volatility3 cmdline).

Run a read-only volatility3 plugin by name to test a hypothesis. Plugins that write carved data to disk (dumpfiles, memdump, procdump, ...) and any output/dump flag are refused: VERDICT exposes no write primitive. Use inspection plugins (pslist, netscan, malfind, consoles, cmdline, dlllist, getsids, handles).

Detect the Volatility 2 profile for a memory image (KDBG scan). Use this when the Volatility 3 tools fail to auto-resolve a profile (older or 32-bit images). Returns the suggested profile to pass to mem_vol2.

Run a Volatility 2 plugin for full structured memory forensics on images Volatility 3 cannot load. Common plugins: pslist, pstree, psscan, netscan, connscan, sockets, malfind, cmdline, consoles, cmdscan, dlllist, getsids, handles. If profile is empty it is auto-detected (and cached). Returns structured rows with PIDs, addresses, etc. Dump/output plugins and flags are refused (no write primitive); use read-only plugins.

Search a memory image for a literal string and return byte offsets (strings + grep, no symbol table required). Use this for cross-source IOC correlation: confirm that an artifact found on disk (a webshell filename, an attacker IP, a created account name) is also resident in memory. Works on any raw memory image regardless of OS profile.

Build a plaso super-timeline of a disk image and summarize it (log2timeline + psort).

Sweep an evidence object (disk or memory image) with a YARA rule and return matches with offsets. rules_text is the YARA rule source. Use to hunt webshell signatures, packer stubs, or campaign IOCs across an image. Read-only.

Record an investigative hypothesis to test. Returns its id (e.g. H01).

Update a hypothesis state: OPEN, SUPPORTED, REFUTED, or INCONCLUSIVE.

Propose a finding. The corroboration engine independently verifies it against archived tool output before the ledger records a verdict.

claim_type tells the engine what kind of claim this is: "observation" - a direct read of primary evidence (a value literally present in an artifact, e.g. a recipient address in a POST body or a process name in pslist). Confirmed when the value is really in the cited output. "inference" - an analytical conclusion (attribution, causation, intent). Confirmed only when independent sources agree; otherwise labeled an inference. Use this for anything that combines observations rather than quoting one.

Each citation is a dict: {exec_id, artifact, locator, asserted_value}. asserted_value is the exact string the claim depends on; the engine checks it is really in that execution's output. If the verdict comes back UNSUPPORTED, the claim is a likely hallucination: do not present it as fact, investigate further, then revise. If it comes back CONTRADICTED, an independent source disagrees: resolve it before it stands.

Revise a finding's verdict and log the change as a self-correction event with its trigger. Use this after new evidence resolves a CONTRADICTED finding or after you retract an UNSUPPORTED claim.

Check a claim against archived output without recording a finding. Useful for testing whether a hypothesis is supported before committing to it.

Fetch a provenance record by exec_id so any finding can be traced to the exact tool execution that produced it. Optionally include a slice of the archived raw output.

List all tool executions in this run with their function and evidence digest.

Map the corroborated findings recorded so far to MITRE ATT&CK techniques. The mapping is deterministic and runs only over CONFIRMED and INFERRED findings, so the technique coverage is grounded in verified evidence and each technique cites the findings that evidence it. Use this near the end of an investigation to frame the kill chain.

Build the structured investigative narrative and the accuracy report from the ledger and provenance. If ground_truth_path is given (a YAML answer key), the accuracy report scores findings against it.