EnCase forensics in Canadian litigation: how findings are documented for court
How EnCase (and Magnet AXIOM) findings are acquired, verified, and documented so they hold up under the Canada Evidence Act and provincial rules of court.
Direct answer
EnCase (OpenText) is one of the two computer-forensic platforms — alongside Magnet AXIOM — most commonly used in Canadian civil and criminal matters. What matters to counsel is not the brand on the box. What matters is that the workflow around the tool produces evidence that satisfies section 31.1 of the Canada Evidence Act (integrity of the electronic system), survives cross-examination under the White Burgess duty to the court, and can be independently verified by opposing counsel.
This guide walks through how a defensible EnCase (and AXIOM) engagement is documented from intake through report, and what to look for on a forensic report before you rely on it in court.
Table of contents
- What EnCase and Magnet AXIOM actually do
- Acquisition: making the forensic image
- Hash verification and the Canada Evidence Act
- Processing and analysis inside EnCase / AXIOM
- What the final report should contain
- Admissibility under the Canada Evidence Act and provincial rules
- Common cross-examination attacks — and how to defend against them
- FAQ
1. What EnCase and Magnet AXIOM actually do
Both are court-recognized computer-forensic platforms used to acquire, preserve, process, and analyze data from computers, external drives, memory, and — increasingly — cloud sources. They are not "hacking tools." They are auditable evidence-processing environments that produce a repeatable, hash-verified record of what was on a device at a specific moment.
- EnCase Forensic (OpenText) has been the industry reference implementation in North American courts since the late 1990s. Its evidence file format (
.E01/ EWF) is the de facto standard for forensic images. - Magnet AXIOM is the more modern platform, stronger on mobile, cloud, and chat-artifact parsing, and widely used alongside EnCase for cross-verification.
Most serious matters use both: acquisition with one, cross-verification with the other. Two independent tools producing the same result is a much harder finding to attack than a single-tool result.
Our qualifications: Teradrive Forensics examiners are EnCase Certified Examiners (EnCE) — the OpenText credential recognized by Canadian courts as evidence that the examiner has demonstrated formal competence with EnCase acquisition, verification, and reporting workflows.
2. Acquisition: making the forensic image
Nothing in a forensic report matters if the acquisition is not defensible. In an EnCase / AXIOM workflow the acquisition step produces:
- A bit-for-bit image of the source media, written through a write-blocker so the original is never modified.
- MD5 and SHA-256 hash values for the source device and the resulting image, computed at acquisition time and recorded in the image metadata.
- An acquisition log — automatically generated by EnCase / AXIOM — recording examiner name, tool version, date/time, source device identifiers, target image path, sector count, and any read errors.
- A chain-of-custody entry matching the log entry, on the physical intake form.
If the device cannot be imaged in the traditional way (encrypted drives, damaged media, live systems), a documented alternative acquisition method is used — live acquisition, RAM capture, targeted collection of specific volumes — and the deviation is explained in the final report. See our methodology for the full checklist.
3. Hash verification and the Canada Evidence Act
Section 31.1 of the Canada Evidence Act places the burden on the party seeking to admit an electronic document to prove the integrity of the electronic document system in which it was recorded or stored. Section 31.3 creates presumptions of integrity where the system was operating properly, or where the record was recorded by a party adverse in interest.
Hash values are how integrity is proven in practice:
- The acquisition hash proves what was on the device at the moment of imaging.
- The verification hash (recomputed at every subsequent handling) proves the image has not changed since.
- Any hash mismatch must be documented — cause identified, remediation recorded, new hashes computed — before analysis continues.
Both EnCase and AXIOM verify hashes automatically whenever a case is opened. That verification record is included in the final report.
4. Processing and analysis inside EnCase / AXIOM
Once the image is verified, the platform builds an index and parses artifacts. Depending on the matter, that includes:
- File system reconstruction — every allocated and deleted file, timestamps (created / modified / accessed / MFT-changed), file paths, parent directories.
- Deleted-file recovery from unallocated space and slack space.
- Registry and system artifacts (Windows) — user accounts, USB device history, program execution (Prefetch, ShimCache, Amcache, UserAssist), recent documents, network history.
- Browser artifacts — history, cache, bookmarks, downloads, form data across Chrome / Edge / Firefox / Safari.
- Email — Outlook
.pst/.ost, Apple Mail, Thunderbird. - Chat and communications — Teams, Slack, Signal, WhatsApp (where present on disk).
- Cloud artifacts left on disk — OneDrive / Google Drive / Dropbox sync metadata, credential caches, browser session tokens.
- Timeline analysis — a unified chronological view combining every timestamped artifact for the relevant date range.
Every finding is traceable back to its source artifact by file path and offset. That traceability is what allows opposing counsel to reproduce the finding independently.
5. What the final report should contain
A court-ready EnCase / AXIOM report — the kind of report we produce and the kind counsel should demand from any forensic vendor — includes:
| Section | Purpose |
|---|---|
| Examiner qualifications | Establishes the Mohan / White Burgess foundation |
| Scope of engagement | What was asked, what was not asked, retainer boundaries |
| Chain of custody | Every handling event, timestamped and signed |
| Acquisition details | Tool + version, method, write-blocker used, hashes |
| Verification record | Hash re-verification confirming image integrity |
| Methodology | Steps taken, in the order taken, with rationale |
| Findings | Numbered, with source artifact reference for each |
| Limitations | What could not be determined and why |
| Appendices | Full artifact export, hash list, tool logs |
A report that omits the acquisition method, the tool version, or the hash values is a report that will be excluded — or heavily discounted — the first time it is challenged.
6. Admissibility under the Canada Evidence Act and provincial rules
The federal framework is short: sections 31.1–31.3 for authentication and integrity, and section 31.2 confirming the best-evidence rule is satisfied by a printout or output of the electronic record. On top of that, each jurisdiction has its own expert-evidence rule:
- BC Supreme Court Civil Rule 11-2 — the expert''s duty is to the court, not the retaining party; a signed Certificate of Expert''s Duty must accompany the report.
- Ontario Rule of Civil Procedure 53.03 — Form 53 acknowledgement of expert''s duty, prescribed report contents, service timelines.
- Alberta Rule 5.34–5.40 — expert report contents and pre-trial exchange.
- Federal Court Rule 52.2 and the Code of Conduct for Expert Witnesses — analogous duty and content requirements.
- Quebec CCP art. 22, 231–246 — expert obligations in the civil-law tradition.
The common thread is the White Burgess Langille Inman v. Abbott and Haliburton Co., 2015 SCC 23 duty of independence: the expert is not an advocate for the retaining party. An EnCase / AXIOM report reads exactly the same whether it was commissioned by plaintiff or defendant.
For counsel evaluating an expert''s qualifications under R. v. Mohan, [1994] 2 SCR 9, see our companion guide to digital-forensics expert-witness requirements in Canada.
7. Common cross-examination attacks — and how to defend against them
The tool itself is rarely the target. The attacks target the process around it.
"Your write-blocker was not certified." — Answer: model, serial, and last-verified date are in the report; certification is on file.
"The hash was not recomputed after transfer." — Answer: verification hash log is in the appendix; timestamps show the recomputation event.
"You used a beta version of the tool." — Answer: tool version and release channel are recorded; only production-release builds are used for court work.
"Another examiner could reach a different conclusion." — Answer: the methodology section documents every step; a second examiner following the same methodology on the same image will reach the same result. Cross-verification with a second tool (EnCase ↔ AXIOM) is documented where it was performed.
"You did not consider exculpatory artifacts." — Answer: scope of engagement is defined; where a follow-up scope was warranted, it is called out in the Limitations section.
8. FAQ
The FAQ appears in the accordion below.