Full description

Every feature: what it does, when to use it, and what it will not prove

Written for the person who has to defend their findings. For each feature we state not only what it does, but its typical use in casework and its interpretive limits — because an opinion built on an unstated limitation falls apart at the first question.

Contents

Where a feature needs an extra component, administrator rights or a particular Windows edition, we say so. No such note means the application alone is enough.

ElPlayer

Video analysis

A player built for material that ends up in the case file. The timeline handles both constant and variable frame rates — which matters with CCTV recorder output, where the declared duration often disagrees with the actual frame count.

From–To markers define a fragment that can then be exported as a separate file or described in the analysis form. Annotations are stored alongside the recording rather than in a separate document, so they cannot drift apart from the material when the case is moved.

Use: Establishing the moment of an event on surveillance footage, cutting the fragment for an opinion, and documenting which frame a conclusion rests on.

Limits: The recording timestamp comes from the recorder and is often unsynchronised with real time. The program shows the time stored in the material; it does not verify its correctness.

Requirements: The FFmpeg component (about 293 MB). Transcription and speech search use the Whisper component (about 191 MB).

ElView

Photograph review and assessment

Review of photographic material with EXIF metadata reading and support for the HEIC format used by Apple phones. Every file can be preserved with a SHA-256 checksum straight from the preview window.

The module issues a supporting authenticity assessment: whether metadata is present and internally consistent, whether it carries GPS data, and which circumstances reduce its reliability. The result takes the form of indications, not a verdict.

Use: Initial selection of photographic material, establishing the source device and capture date, preparing an interactive report with markers.

Limits: EXIF metadata can be altered with any ordinary tool. Its presence does not prove authenticity, and its absence does not prove manipulation.

Requirements: No extra components.

ElCommander

Inventory and preservation

A dual-pane file manager with an evidence mode that computes checksums on the fly and displays a warning when either medium is writable. The warning appears before the operator acts, not after.

Directory comparison shows the differences between medium and copy, which lets you demonstrate that the preservation was complete. Archives are produced as ZIP with AES-256 encryption, 7Z or TAR.GZ.

Use: Preserving the contents of a medium into the case folder, demonstrating that the copy matches the original, packaging material for hand-over.

Limits: Evidence mode warns about a writable medium but does not replace a hardware write blocker. When working on an original, the hardware blocker remains the correct answer.

Requirements: The 7-Zip component (about 3 MB). Auto-Blocker needs administrator rights — Windows will ask for UAC consent.

ElCarver

Recovery of deleted files

Fast mode reads the NTFS, FAT32 and exFAT file system structures, recovering files together with their original name, date and size. Deep mode searches for signatures in raw data and works even on a damaged file system, but recovers files without names.

The source is opened strictly read-only. Results pass a verification step that rejects false hits — fragments resembling a file header without being a valid file.

Use: Recovering deleted photographs, documents and recordings from a medium or from a RAW, E01 or AFF4 image.

Limits: A recovered file carries no reliable timestamp and no certain position in the directory structure. An overwritten area cannot be recovered by any method.

Requirements: No extra components.

ELVoice

Voice recording analysis and comparison

The module decodes a recording to mono 16 kHz using FFmpeg; the source is opened strictly read-only and the first five minutes of material are analysed. Twenty formats are supported — WAV, MP3, FLAC, M4A, AAC, Ogg, Opus, AMR and 3GP, plus the audio track of MP4, MOV, MKV and WebM, which covers typical phone and messenger recordings.

For each sample it computes acoustic parameters: estimated fundamental pitch, spectral centroid, zero-crossing rate, the proportion of voiced frames, RMS and peak level, crest factor and the proportion of clipped samples. Two images are produced as well — a waveform and a spectrogram — saved as separate files, so they go straight into the report and the case file.

Comparing two samples yields a percentage together with a verbal band: high, moderate or low similarity. The method is written into the report rather than hidden — it is a comparison of acoustic feature vectors. An analysis form, time markers and a PDF report with SHA-256 checksums of both files complete the output.

Use: A first comparison of a disputed recording against reference material, describing the technical properties of the recording and documenting exactly what was compared.

Limits: This is not speaker identification and the result must not be treated as biometric proof. Acoustic similarity shifts with recording quality, codec, transmission channel, emotion and the speaker’s state of health — two recordings of the same person can score low, and two different people can score high. It is grounds for further work, or for instructing a forensic phonetician, never a finding of identity.

Requirements: The FFmpeg component (about 293 MB) and, for transcription, Whisper with an offline model (about 191 MB).

ELNetwork

Network capture analysis

The module runs two independent engines over a traffic capture: Suricata, which matches traffic against detection rules, and Zeek, which breaks sessions down into logs of connections, DNS queries, HTTP requests, TLS sessions and transferred files. PCAP, PCAPNG, CAP and raw dumps are accepted.

Results from both engines land in one view across six categories — alerts, connections, DNS, HTTP, TLS and files — merged and ordered by time. Every record carries the engine that produced it, so it never becomes unclear where a finding came from.

The capture is never modified. Each run gets its own output directory and a manifest with SHA-256 checksums of the capture and of the rules and scripts used, so the analysis can be repeated and the rule set it rested on can be demonstrated. Results export to CSV and standalone HTML.

Use: Establishing which addresses a device contacted, which domains it queried and which files crossed the network within a preserved traffic capture.

Limits: The analysis covers only what the capture contains — traffic from before capturing began does not exist. The content of encrypted connections stays unreadable; metadata is visible, including the server name from the TLS SNI field. A Suricata alert means a rule matched, not a confirmed incident, and detection coverage depends entirely on which rules were used.

Requirements: The TShark/Wireshark component (about 236 MB).

ELSandbox

Isolated execution of unknown files

The module prepares a session in the native Windows Sandbox — it does not emulate one and never runs the examined file on the host. Diagnostics check the Windows version and edition, the optional system component, virtualisation, memory, free space and the presence of WindowsSandbox.exe; a missing component can be enabled explicitly through DISM, with elevation and a clear notice about the required restart.

Material is never opened straight from the case folder. Every session gets its own working directory, files are copied into it, and SHA-256 of the source and of the copy are computed independently — a mismatch aborts the operation. Only the verified copy is mapped into the guest, as C:\EvidLock\Input with the read-only attribute. The case folder, the case database and the original path of the material are not mapped.

The protection profile disables the clipboard, microphone, camera, printers and vGPU, and enables the sandbox protected client. Networking has three modes: offline (the default), direct and through a proxy. Selected local tools — Process Monitor and Wireshark — receive separate read-only mappings, and the only directory that may be writable is the output folder you point at.

After the session is closed the module inventories the retained results with relative paths, sizes, timestamps and SHA-256 checksums. The HTML report gathers the session identifier, case signature, operator, workstation, Windows version, requirements, protection and network settings, the list of input and output copies, and a chronological event journal. It works offline and supports filtering, printing to PDF and JSON export.

Use: Inspecting a suspicious attachment, installer or macro-bearing document without running it on the examination workstation — together with a record of what was opened and under which conditions.

Limits: The sandbox reduces the risk of accidentally executing a file on the host, but it is not a guarantee that nothing escaped the environment. The proxy is a setting inside the guest that the examined program may bypass. The report documents the safeguards applied, not the absence of activity invisible to the mechanisms used — high-risk material still calls for an isolated workstation and organisational procedures.

Requirements: Windows 10 version 1903 (build 18362) or newer, in the Pro, Enterprise or Education edition — Home editions have no Windows Sandbox. The Containers-DisposableClientVM feature must be enabled and firmware virtualisation available; enabling the feature needs administrator rights and a system restart.

Case analysis

Shared findings database

Seven independent scans write into a single case database: file signatures, encryption detection, hash sets, YARA rules, SQLite journal recovery, phone backups and Sleuth Kit. Findings can be searched together, regardless of which scan produced them.

Relevant items are tagged and exported to an HTML, JSON or XLSX report together with SHA-256 checksums. The database is an ordinary SQLite file inside the case folder, so it falls under the same preservation rules as the rest of the material.

Use: Filtering out known files, flagging mismatches between file type and extension, and gathering every finding into one report.

Limits: The scans point to places worth attention; they do not decide. A YARA hit means the pattern matched, not that the file is confirmed malicious.

Encryption detection

First-contact check

Recognises volume-level encryption — BitLocker, BitLocker To Go, LUKS and FileVault — and file-level encryption: password-protected ZIP, 7z and RAR archives, PDF and Office documents, and encrypted private keys.

Containers that deliberately carry no signature, such as VeraCrypt and TrueCrypt, are reported separately as suspicion. The basis is entropy close to ciphertext, a size that is a multiple of the sector, and the absence of any known header.

The check also runs as part of One-Click, that is, during the very first action on the material. This is deliberate: a detected encrypted volume changes how you proceed, and the password can sometimes only be obtained before power is cut.

Use: Establishing at the outset what in the material cannot be read, and recording that in the documentation of the procedure.

Limits: The “suspicion” level is not a confirmation and cannot be confirmed without the password. Hidden VeraCrypt volumes are designed so that their existence cannot be demonstrated.

SQLite journal recovery

Writes not yet in the database

Browsers and messengers keep their data in SQLite databases. Deleting an entry does not remove it at once — the change first lands in the WAL or rollback journal, and the old content remains on freed pages.

The module extracts addresses, e-mail addresses, phone numbers and paths from those files. It also checks the completeness of the preservation: whether the journal files accompanying the database were seized alongside it.

Use: Recovering the most recent visited addresses or messages that did not reach the main database before the medium was seized.

Limits: A recovered record carries no guarantee of completeness or of its position in time. It is material for further verification, not finished evidence.

Phone backups

Discovering sources in the material

Recognises an iTunes or Finder backup folder and the file produced by adb backup. For iOS backups it reads the device name, model, system version, serial number and creation date, and counts files grouped by domain.

It also detects whether the backup is encrypted. Worth knowing: an encrypted iTunes backup contains more data than an unencrypted one — including Wi-Fi passwords, health history and the keychain.

The feature sits in the material structure preview, because it answers the question “what is actually here”. A discovered backup gets an action that opens it in Case analysis as the source for the remaining scans.

Use: Establishing that a seized computer contains a phone backup — that is, a separate evidentiary source holding messages and call history.

Limits: The module recognises and inventories the backup but does not parse application content. Messenger databases are SQLite files and fall under a separate scan.

Timeline and evidence graph

Event correlation

Activity profiling brings into one UTC timeline the events from EVTX logs, the registry, Prefetch, LNK, Jump Lists, ShellBags, USBSTOR, Amcache, ShimCache, SRUM, the process list, network connections and browsers.

A deterministic graph with fifteen explicit correlation rules works over the normalised records. Clicking an edge reveals the rule, the confidence level, an explanation, the limitations and the identifiers of the evidence the link rests on.

Use: Reconstructing the sequence of events on a workstation and demonstrating on what basis particular artefacts were linked.

Limits: The graph does not attribute actions to a person. An event under a user account proves the account was used, not the identity of whoever was at the keyboard.

Plaso

Full timeline from a disk image

Plaso is the standard tool for building what is called a super timeline: it walks through a disk image and extracts timestamps from everything that carries them — the file system, the registry, event logs, browsers, LNK files and dozens of other sources. The result is hundreds of thousands of records ordered in time.

In EvidLock you point at the image and start processing from inside the program. Progress is visible as it runs, because on a large medium this is work measured in hours. The finished timeline loads straight into the correlation graph — with no CSV export and no copying between tools, which is where the time zone usually gets lost.

The source is opened strictly read-only, and the feature is available regardless of the installation variant chosen.

Use: Reconstructing the full sequence of events from a preserved disk image when it is not known in advance which artefact to look for.

Limits: A super timeline contains an enormous number of technical records unrelated to the case. It is material to be narrowed down, not a finished finding. The timestamps come from the examined system and inherit its errors — a wrongly set clock shifts the whole timeline.

Requirements: Docker Desktop installed — the processing runs in a container.

Volatile memory

Material that does not survive

The capture is taken with WinPmem, with a SHA-256 checksum computed as soon as it finishes. Optionally pagefile.sys, swapfile.sys and hiberfil.sys are acquired as well, since they hold fragments of memory written to disk.

Analysis runs directly on the acquired image through Volatility 3. The HEX view reads the image page by page, so a file tens of gigabytes in size opens instantly, and the search covers the whole of it as ASCII, UTF-16 LE and raw HEX bytes.

The image manager places two captures side by side and compares their checksums, which lets you demonstrate that a copy is faithful.

Use: Capturing the memory of a running workstation, including encryption keys and connections that vanish once power is cut.

Limits: The module is in beta. Capture requires administrator rights and always alters the state of the examined system — it cannot be done without a trace, and that must be recorded.

Requirements: The Volatility 3 with WinPmem component (about 19 MB). Dumping the memory of a running system needs administrator rights.

HEX editor

Searching a capture byte by byte

A memory capture usually holds as many bytes as the workstation had RAM — tens of gigabytes. An ordinary editor tries to load such a file whole, and either takes a quarter of an hour or runs out of memory. The EvidLock view reads the image page by page, so it opens instantly whatever the size.

The search runs through the whole image in three modes at once: as ASCII text, as UTF-16 LE (the way Windows holds strings in memory) and as raw HEX bytes. That third mode is what you need when looking for a format header or part of a key rather than a word.

The hit list shows the address, the matching mode and a context preview. Jumping to an arbitrary address lets you return to a location pointed out by another tool — a Volatility plugin, for instance.

Use: Confirming that a particular string was present in memory: an address, a file name, a fragment of a conversation, or a container header no plugin detected.

Limits: A hit in memory proves the string was there at the moment of capture. It does not say which process wrote it or when — the region may have been freed and may come from a program closed hours earlier.

Memory image manager

Comparing two captures

Places two memory images side by side: name, path, size and dates. It computes SHA-256 for both and shows them one under the other, together with an unambiguous statement of whether they agree.

The usual reason to do this is prosaic: the capture goes onto another medium, or into the case file as a copy, and the copy has to be shown faithful. The second reason is verifying an image handed over by someone else — before you build an opinion on it.

From the same window you select the image passed on for further analysis, so there is no need to retype the path in the next module.

Use: Demonstrating that a copy of a capture is identical to the original, and choosing the image for analysis in Volatility.

Limits: Matching checksums prove two files are identical. They say nothing about whether the first capture was taken correctly or under what conditions it was made.

Disk images

Working on a copy instead of the original

Imaging of disks and volumes to RAW or ISO, with the checksum computed as it runs. An image is a sector-by-sector copy, so it also covers unallocated space — which is what ElCarver recovers deleted files from.

EvidLock also reads the formats used by other forensic tools: E01 and Ex01 from the EnCase suite, and AFF4. An image preserved with someone else’s software can therefore be analysed without conversion.

An image can be mounted in the system for browsing and compared against a second image where the fidelity of a copy has to be shown.

Use: Making a binary copy of a preserved medium and conducting every subsequent step on that copy rather than the original.

Limits: Imaging an original medium requires a hardware write blocker — software safeguards do not replace it. A physically damaged medium may yield an incomplete image; the program reports read errors but does not repair the medium.

Requirements: The ImDisk component (about 1 MB) for mounting images. Reading a physical disk needs administrator rights.

Integrity and One-Click

The basis of every step

SHA-256 checksums are computed for individual files and whole directories, and written into a manifest with a deterministic form — the same directory yields the same manifest on every verification. BLAKE3 serves for fast inventory of large sets, and MD5 exists solely as a compatibility value computed alongside SHA-256.

One-Click performs the whole first-action sequence with a single command: setting the read-only attribute, the encryption check, checksums, manifest, report and a password-protected archive.

Use: Preserving material at the start of a case in a way that is repeatable and demonstrable.

Limits: A checksum proves immutability from the moment it was computed. It says nothing about what happened to the material before that.

Browser artefacts

User activity on the network

Reads history, bookmarks, the download list, cookies and cache. Saved-password metadata is extracted separately — that is, which services the user stored credentials for, without reading the passwords themselves.

Results pass through a risky-content filter that highlights entries worth looking at first. That is a viewing order, not an assessment.

The data feeds into the shared timeline, so visiting a page lines up with a program being launched, a medium being connected and an event from the system log.

Use: Establishing which services were used on the workstation, when, and what was downloaded — and tying that to the remaining artefacts.

Limits: A history entry proves the browser loaded the address. It does not settle whether a person did it — it could have been a redirect, an advertisement, an extension or a script. Private mode leaves most of these traces behind.

Registry and Windows logs

Traces on the system side

Export of registry hives to .hiv files and to readable form: CSV, XLSX, TXT and PDF. The .hiv file is a binary copy suitable for analysis in another tool; the remaining formats are for the case file.

Event logs — application, security, setup and system — are exported with a chosen time range and record limit, to XLSX, EVTX, PDF and TXT in one pass. EVTX preserves the original form of the events; the rest are for reading and attaching.

Output files receive SHA-256 checksums and the read-only attribute at the moment they are written.

Use: Documenting logons, USB medium connections, software installations and configuration changes within a chosen time range.

Limits: Logs are rotated and overwritten — the absence of an event does not prove nothing happened. Events can also be cleared with administrator rights, which itself leaves a trace, though one that can likewise be removed.

Content search

Phrases across the whole material

Multi-threaded searching of file names and file contents. The program looks inside text documents, PDFs, Office and OpenDocument formats and EML messages — that is, where the system search usually does not reach, because its index does not cover them or there is no index at all.

Results show the path, the location of the hit and a fragment of context, so it is immediately clear whether the hit is the one you wanted.

Use: Finding a surname, an account number, an address or a phrase from the report within preserved material — without opening files one by one.

Limits: The search works on content that can be read. Scans and photographs of documents without a text layer, encrypted files and proprietary application formats will stay outside the results.

Requirements: No extra components. Reading text from scans and photos needs the Tesseract component (about 246 MB).

Event journal

A record of your own work

Every operation performed in the program enters the journal with its time, severity level, sequence number, module name and duration. The sequence number matters: it shows the order of actions even when two happened within the same second.

The record is written as the work proceeds. That is a practical difference, not a cosmetic one — documentation reconstructed from memory at the end of the day is always poorer and always exposed to the question of how you know it happened that way.

The journal can be filtered live by entry text and exported to PDF, XLSX and an interactive HTML report with sorting. The final case report gathers the whole set of actions into one document.

Use: Demonstrating exactly what was done with the material, in what order and with what result — in a form fit to attach to the case file.

Limits: The journal records operations performed in EvidLock. Steps taken with another tool or manually in the system will not appear there and must be described separately.

Reports and journal

What stays in the case file

The journal records every operation with its time, level, sequence number, module and duration. The record is written as the work proceeds, so the documentation is produced together with the work rather than after it.

Reports are produced as PDF, CSV, TXT and XLSX, and the journal additionally as an interactive HTML report with filtering and sorting. The final report gathers the whole sequence of steps taken in the case.

Use: Attaching to the case file a record of the procedure that can be reproduced and verified.

Limits: The journal records operations performed inside the program. Steps taken outside it will not appear there.

EvidLock for Windows

One installer for the main application, three portable variants and four modules with their own installers. Every release shares the same engine and the same case format.

Download