Appendices

Appendix A: Example Folder Structure

<data-root>/
  <hashed-user-email>/
    C-20260429-101010000UTC/
      C-20260429-101010000UTC-DB.sqlite
      A-20260429-101500000UTC/
        A-20260429-101500000UTC-DB.sqlite
        Chain of Custody/
          User-Activity
          User-Activity.html
        Browser-Profile/
        Pages-Source-Code/
        Artifacts-Network/
          Browser-NetLogs.json
          A-20260429-101500000UTC.PCAPNG-TLSKeys.log
          Local-TShark/
            A-20260429-101500000UTC.PCAPNG
            A-20260429-101500000UTC.log
        Evidences/
          E-20260429-101700000UTC/
            E-20260429-101700000UTC-Screenshot-A4.png
            E-20260429-101700000UTC-Screenshot-A4.png.pdf
            E-20260429-101700000UTC-summary.json
            E-20260429-101700000UTC-hashlist.txt
          E-20260429-101700000UTC-archive.zip
          E-20260429-101700000UTC-report.pdf
          E-20260429-101700000UTC-report.json
          E-20260429-101700000UTC.zip
        systeminfo.txt
        certificates.txt
        A-20260429-101500000UTC-hashlist.txt
      A-20260429-101500000UTC-archive.zip
      A-20260429-101500000UTC-report.pdf
      A-20260429-101500000UTC-report.json
      A-20260429-101500000UTC-summary.json
      C-20260429-101010000UTC-archive.zip
      C-20260429-101010000UTC-report.pdf
      C-20260429-101010000UTC-report.json
      C-20260429-101010000UTC-summary.json

Appendix B: Sample Evidence Package Contents

E-20260429-101700000UTC.zip
  E-20260429-101700000UTC-archive.zip
  E-20260429-101700000UTC-report.pdf
  E-20260429-101700000UTC-report.json
  E-20260429-101700000UTC-summary.json
  E-20260429-101700000UTC-summary.json.tsq
  E-20260429-101700000UTC-summary.json.tsr
  E-20260429-101700000UTC-summary.json.tsq_text
  <blockchain raw metadata file, when present>

The archive inside the package may contain:

E-20260429-101700000UTC-Screenshot-A4.png
E-20260429-101700000UTC-Screenshot-A4.png.pdf
E-20260429-101700000UTC-PageSource.txt
E-20260429-101700000UTC-Whois.txt
E-20260429-101700000UTC-Robots.txt
E-20260429-101700000UTC-SiteMap.txt
E-20260429-101700000UTC-hashlist.txt
Downloads/
  downloaded-file.ext
PDF/
  E-20260429-101700000UTC-Pageshots-A4-0-50.pdf

Appendix C: Sample Acquisition Package Contents

A-20260429-101500000UTC-archive.zip
A-20260429-101500000UTC-report.pdf
A-20260429-101500000UTC-report.json
A-20260429-101500000UTC-summary.json
A-20260429-101500000UTC-summary.json.tsq
A-20260429-101500000UTC-summary.json.tsr
<blockchain raw metadata file, when present>

The acquisition archive may contain:

A-20260429-101500000UTC-DB.sqlite
Chain of Custody/User-Activity
Chain of Custody/User-Activity.html
Browser-Profile/
Pages-Source-Code/
Artifacts-Network/Browser-NetLogs.json
Artifacts-Network/A-20260429-101500000UTC.PCAPNG-TLSKeys.log
Artifacts-Network/Local-TShark/A-20260429-101500000UTC.PCAPNG
Artifacts-Network/Local-TShark/A-20260429-101500000UTC.log
Evidences/E-20260429-101700000UTC.zip
systeminfo.txt
certificates.txt
A-20260429-101500000UTC-hashlist.txt

Appendix D: Sample Chain-Of-Custody Log

TimeStamp | Event Type | Event Description | URL | File Name | SHA2_256 File Hash |
2026-04-29 10:15:00.000 UTC | System | Welcome Jane Investigator! | | | |
2026-04-29 10:15:01.000 UTC | System | Eviquire Version: D[Version] | | | |
2026-04-29 10:15:04.000 UTC | System | Acquisition ID: A-20260429-101500000UTC | | | |
2026-04-29 10:15:06.000 UTC | Browser | Browser Navigation Requested |
https://example.test | | |
2026-04-29 10:15:09.000 UTC | Browser | Page load succeeded | https://example.test | | |
2026-04-29 10:16:20.000 UTC | System | ScreenShot taken (PNG) | https://example.test |
/Evidences/E-20260429-101620000UTC/E-20260429-101620000UTC-Screenshot-A4.png |
<sha2-256> |
2026-04-29 10:16:21.000 UTC | System | Evidence summary saved (JSON) |
https://example.test | /Evidences/E-20260429-101620000UTC/E-20260429-101620000UTC-
summary.json | <sha2-256> |
2026-04-29 10:16:30.000 UTC | System | Evidence archive saved | https://example.test |
/Evidences/E-20260429-101620000UTC-archive.zip | <sha2-256> |
2026-04-29 10:16:35.000 UTC | System | Evidence report saved (PDF) | https://example.test
| /Evidences/E-20260429-101620000UTC-report.pdf | <sha2-256> |
2026-04-29 10:16:42.000 UTC | System | Evidence timestamped | https://example.test |
/Evidences/E-20260429-101620000UTC-summary.json.tsr | <sha2-256> |
2026-04-29 10:20:00.000 UTC | System | Session Closed | | | |

Appendix E: Sample Verification Workflow

Use this workflow to validate a delivered evidence package.

1. Copy the delivered evidence ZIP to a review workstation.
2. Compute SHA2-256 of the delivered ZIP and record it.
3. Extract the ZIP into a review folder.
4. Locate the summary JSON.
5. Open the summary JSON in read-only mode.
6. Identify the expected hash of the raw evidence archive.
7. Compute SHA2-256 of the raw evidence archive.
8. Compare the computed hash to the summary value.
9. Identify the expected hash of the PDF report.
10. Compute SHA2-256 of the PDF report.

Compare the computed hash to the summary value. 12. Validate the .tsq and .tsr files using an approved timestamp validation process. 13. Review blockchain metadata if present. 14. Extract the raw evidence archive only if file-level inspection is required. 15. Review the evidence hash list. 16. Compare file-level hashes for any files used in analysis or presentation. 17. Record verification results in the review notes.

Appendix F: Sample Acquisition Review Checklist

Before accepting an acquisition as complete, confirm:

• Acquisition ID is correct.
• Case ID is correct.
• Investigator identity is correct.
• Acquisition start and end times are present.
• Evidence list is complete.
• Chain-of-custody logs are present.
• Acquisition database is present.
• Reports are present.
• Summary JSON is present.
• Hash list is present.
• Network artifacts are present if network capture was enabled.
• Video artifacts are present if video recording was enabled.
• System info is present if enabled.
• Certificates are present if enabled.
• Evidence packages open successfully.
• No unexpected hash mismatch is present.
• Known errors are documented.

Appendix G: Sample Case Closure Checklist

Before closing a case, confirm:

• All acquisitions are complete.
• All evidence packages are finalized.
• Reports have been generated.
• Errors have been reviewed.
• Legal scope has been satisfied.
• Sensitive material has been identified.
• Export location has sufficient space.
• Password protection requirements are known.
• Viewer package requirement is known.
• Case package hash will be recorded.
• Transfer method is approved.

Appendix H: Artifact Reference

Artifact	Purpose
Evidence PNG	Visual capture of observed content
Evidence PDF	Stable human-readable visual rendering
Page source TXT	Technical source or markup capture
Mail EML	Preserved email message file
Downloaded file	File obtained during acquisition
WHOIS TXT	Domain registration context
Robots TXT	Host robots.txt context
Sitemap XML/TXT	Host sitemap context
Evidence hash list	File-level integrity manifest
Evidence archive ZIP	Raw evidence container
Evidence report PDF	Human-readable evidence report
Evidence report JSON	Structured evidence report
Evidence summary JSON	Integrity metadata for package
TSQ	Timestamp request
TSR	Timestamp response
Blockchain raw metadata	External anchoring metadata
Acquisition DB SQLite	Session records, events, evidence, metadata
User-Activity	Text chain-of-custody log
User-Activity.html	HTML chain-of-custody log
Browser profile	Browser cookies, cache, storage, profile data
Browser-NetLogs.json	Browser network activity log
PCAPNG	Packet capture
TShark log	Packet capture tool log
TLS key log	TLS decryption support data
Video MP4	Session or device recording
systeminfo.txt	Acquisition workstation details
certificates.txt	Trusted certificate context
Acquisition report PDF/JSON	Session-level report
Case report PDF/JSON	Case-level report

Appendix I: Detailed Package Internals

This appendix explains the expected structure and meaning of the three major package layers: the evidence package, the acquisition package, and the case package. These layers are intentionally redundant in some areas. Redundancy is useful in forensic work because the same fact can be confirmed from more than one place: a report, a summary JSON, a hash list, a database record, a chain-of-custody event, and the file system. When reviewing any Eviquire deliverable, begin by identifying the scope of the package. Do not assume that a ZIP file represents the whole case. An evidence ZIP may contain only one capture item. An acquisition archive may contain a full session but not necessarily every acquisition in the case. A final case ZIP is the broadest deliverable and should be treated as the primary long-term export for a completed investigation.

I.1 Evidence Package Internals

An evidence package is designed to answer a focused question: what exactly was captured for this evidence item, what files make up the evidence, what context was known at capture time, and how can the reviewer verify that the captured material has not changed? The final evidence package is normally named:

<evidence-id>.zip

Inside it, the reviewer should expect several categories of files. The raw evidence archive is normally named:

<evidence-id>-archive.zip

This archive contains the actual captured material. For a screenshot, it contains image files and possibly screenshot PDFs. For page source, it contains source text. For a download, it contains the downloaded file and any contextual screenshot/source material. For mail, it contains the mail file and related evidence. For a full-page capture, it can contain many pageshot images and generated PDF files. The evidence PDF report is normally named:

<evidence-id>-report.pdf

The PDF report is the human-readable evidence report. It is useful for investigators, attorneys, managers, and reviewers who need a clear description of the evidence without manually examining every technical artifact. The PDF should be treated as a report about the evidence, not as a replacement for the raw evidence archive. The evidence JSON report is normally named:

<evidence-id>-report.json

The JSON report is the structured counterpart to the PDF. It is intended for technical review, automated validation, or ingestion into another system. If a discrepancy appears between a PDF report and a JSON report, preserve both and perform a technical review before relying on either alone. The evidence summary JSON is normally named:

<evidence-id>-summary.json

The summary JSON is one of the most important files in the package. It is the integrity statement for the evidence package. It records file information for the evidence archive and, where applicable, the report. It can include file name, file size, file creation date UTC, file creation timestamp, MD5, SHA2-256, SHA3-256, URL, domain, device ID, evidence ID, acquisition ID, acquisition type, case ID, and investigator identity. The timestamp files are normally named:

<evidence-id>-summary.json.tsq
<evidence-id>-summary.json.tsr

The .tsq file is the timestamp request. The .tsr file is the timestamp response. The response should be validated using an approved timestamp verification process if formal timestamp validation is required. These files are important because they establish that the summary existed in a particular form at or before the timestamp response time. Blockchain raw metadata may also be present. The exact file name depends on the blockchain metadata suffix used by the application. This file records blockchain anchoring information for the submitted summary hash. Blockchain anchoring should be treated as an additional proof layer, not as the only integrity mechanism. The evidence package may contain a timestamp request text rendering:

<evidence-id>-summary.json.tsq_text

This file can help reviewers understand the timestamp request in a more readable form, depending on configuration. When a reviewer extracts the raw evidence archive, they may find an evidence hash list:

<evidence-id>-hashlist.txt

This file is a file-level integrity manifest. It is especially important because it compares hashes stored at acquisition time with hashes calculated at packaging time. A matching result supports the conclusion that files remained stable between creation and final packaging. A mismatch requires investigation and documentation. The evidence package is therefore made of three functional groups:

• Captured material: screenshots, source, downloads, mail, WHOIS, robots.txt, sitemap.xml, generated PDFs, or other evidence files.
• Interpretation material: PDF and JSON evidence reports.
• Verification material: summary JSON, hash list, timestamp files, blockchain metadata, and recorded hashes.

Forensic reviewers should keep these groups conceptually separate. A screenshot is what was captured. A report explains it. A summary and hash list help verify it.

I.2 Acquisition Package Internals

An acquisition package is designed to answer a broader question: what happened during the collection session, what settings were active, what evidence was produced, and what environmental artifacts support the collection? The acquisition archive is normally named:

<acquisition-id>-archive.zip

This archive contains the acquisition working directory after evidence packages have been created and acquisition-level artifacts have been generated. It may contain the acquisition SQLite database, chain-of-custody logs, browser profile, network artifacts, video artifacts, system information, certificates, evidence package references, and acquisition hash list. The acquisition database is normally named:

<acquisition-id>-DB.sqlite

This database is a key technical artifact. It stores structured information about chain-of-custody events, evidence records, navigation history, request/response data where enabled, acquisition metadata, evidence comments, and video duration. The database allows Eviquire to reconstruct the acquisition for review. Technical users may inspect it only using approved forensic methods and should avoid modifying it. The chain-of-custody folder normally contains:

Chain of Custody/User-Activity
Chain of Custody/User-Activity.html

The text file is a plain chain-of-custody log. The HTML file is a more review-friendly representation. These logs are valuable because they show the procedural sequence: application startup, version, investigator identity, navigation, page load, screenshot, source capture, download, report creation, timestamping, recording events, and session closure. The browser profile directory may contain cache, cookies, persistent storage, and other browser state:

Browser-Profile/

The browser profile is highly sensitive. It can help explain how content was accessed, especially in authenticated sessions, but it may contain session tokens or personal data. Do not distribute browser profile material casually. If legal disclosure does not require it, follow counsel or organizational policy before sharing it. The pages source directory may contain source files that were saved outside a finalized evidence item:

Pages-Source-Code/

These files can help reconstruct browsing or analysis activity, but the strongest evidence source files are normally those packaged into evidence items with summaries and hash records. The network artifacts directory may contain:

Artifacts-Network/Browser-NetLogs.json
Artifacts-Network/<acquisition-id>.PCAPNG-TLSKeys.log
Artifacts-Network/Local-TShark/<acquisition-id>.PCAPNG
Artifacts-Network/Local-TShark/<acquisition-id>.log

Browser-NetLogs.json is the browser network log. It can contain browser-level network activity, including requests, redirects, timing, errors, and other diagnostic data. The PCAPNG file is the packet capture. The TShark log records the packet capture tool’s behavior. The TLS key log can support decryption of browser TLS traffic in compatible tools and should be treated as highly sensitive. The acquisition may include video artifacts:

<acquisition-id>-Video001.mp4
<acquisition-id>-Video.log
<acquisition-id>-Video-Device.mp4

Exact names can vary. Video artifacts document the acquisition session visually. They are particularly useful for explaining how the investigator interacted with a dynamic page, selected content, initiated downloads, or ended the session. Video should be reviewed for accidental exposure of sensitive material before disclosure. The acquisition may include environment files:

systeminfo.txt
certificates.txt

systeminfo.txt documents the acquisition workstation. certificates.txt documents certificate trust information. These files help establish the technical environment in which evidence was collected. The acquisition report files are normally named:

<acquisition-id>-report.pdf
<acquisition-id>-report.json

These reports summarize the session. They should describe acquisition identity, type, investigator, timing, duration, settings, evidence items, archive information, and integrity metadata. The acquisition summary JSON is normally named:

<acquisition-id>-summary.json

This summary records file information and hashes for the acquisition archive and report. It is timestamped and may be blockchain anchored. Because it summarizes the acquisition archive, it is the primary acquisition-level integrity statement. The acquisition hash list is normally named:

<acquisition-id>-hashlist.txt

This file records the acquisition file tree, file creation times, modification times, sizes, and hashes. It is useful for technical review of the acquisition archive contents. The acquisition package therefore preserves not only individual evidence items, but also the operational context that produced them.

I.3 Acquisition Page Interpretation

The acquisition page in the application is a review interface over acquisition metadata and package records. It should be read as a structured summary of the session. Common acquisition page fields include acquisition ID, acquisition name, acquisition type, investigator, IP/country, Tor state, start time, end time, user agent, DNS-over-HTTPS mode, device ID, mail type, mail server, mail user, archive file name, archive SHA2-256, summary file name, summary SHA2-256, blockchain transactions, and enabled collection options. When reviewing the acquisition page, investigators should confirm:

• The acquisition ID matches the package and folder names.
• The acquisition type matches the intended workflow.
• The investigator name is correct.
• Start and end times are plausible and in UTC or clearly labeled.
• User agent and routing settings are expected.
• Network capture state matches expected artifacts.
• Video state matches expected artifacts.
• WHOIS, system info, certificates, and deep collection states match expected artifacts.
• Archive and summary hashes are present.
• Evidence list is complete.
• Corruption flags or error messages are absent or documented.

The acquisition page is not the evidence itself. It is a navigational and review layer. The authoritative artifacts remain the package files, reports, summaries, logs, database, and hashes.

I.4 Case Package Internals

A case package is designed to answer the broadest question: what is the complete preserved investigative matter, including all acquisitions and their supporting reports and integrity records? The case archive is normally named:

<case-id>-archive.zip

This archive contains the case directory and acquisition material. During case closure, Eviquire creates a case-level hash list, compresses the case, generates reports, creates a summary JSON, timestamps the summary, and optionally includes a viewer package in the final case ZIP. The final case package is normally named:

<case-id>.zip

The final case ZIP may contain:

<case-id>-archive.zip
<case-id>-report.pdf
<case-id>-report.json
<case-id>-summary.json
<case-id>-summary.json.tsq
<case-id>-summary.json.tsr
<case-id>-summary.json.tsq_text
<case-id><blockchain raw suffix>
viewer files, when included

The case archive contains the acquisition archives and case-level data. The case PDF report is the human-readable summary of the matter. The case JSON report is the structured equivalent. The case summary JSON is the integrity statement for the case archive and report. The timestamp files and blockchain metadata provide external verification layers for the case summary. The case package is appropriate for long-term archive and formal transfer. It should usually be treated as the master deliverable. If a case package is password-protected, preserve the password separately using approved key management procedures.

I.5 How Reviewers Should Interpret Package Layers

When reviewing Eviquire exports, use a layered interpretation model. At evidence level, ask:

• What single item was captured?
• Which raw files represent the item?
• What URL, domain, device, or mail context is recorded?
• What hashes verify the item?
• Was the evidence summary timestamped?
• Is there a report explaining the item?

At acquisition level, ask:

• What session produced the evidence?
• Which investigator performed it?
• Which options were active?
• What routing, DNS, user-agent, video, and network conditions applied?
• Which evidence items were created?
• Was the entire session video recorded properly?
• Are chain-of-custody logs complete?
• Did the acquisition finalize normally?

At case level, ask:

• What investigation does this represent?
• Which acquisitions belong to it?
• Was the case closed?
• What is the final case package hash?
• Are case reports and summaries present?
• Are timestamp and blockchain records present?
• Has transfer or disclosure been documented?

This model helps avoid a common review mistake: treating a screenshot as if it were the entire evidence record. In Eviquire, the screenshot is only one artifact. The stronger forensic object is the evidence package, and the stronger session object is the acquisition package.

I.6 Package Handling Rules

Use these rules when handling Eviquire package files:

1. Preserve original packages unchanged.
2. Compute and record hashes before extraction.
3. Extract only into controlled review folders.
4. Use copies for analysis.
5. Do not rename internal files unless creating a separate working copy.
6. Do not remove timestamp or blockchain metadata.
7. Do not discard JSON reports.
8. Do not disclose browser profile, PCAP, TLS key logs, or mail artifacts without scope review.
9. Record every transfer.
10. Keep passwords separate from packages. The most defensible workflow is to preserve the original export, create a working copy, verify the working copy hash, extract and review the copy, and document all findings separately.

Appendix J: Publication Notes

This manual describes Eviquire workflows and artifacts from the perspective of investigators and reviewers. Specific options may vary by edition, license, operating system, and deployment configuration. Organizations should supplement this manual with local standard operating procedures, legal authority requirements, retention rules, and security controls.

Appendix K: Courtroom And Audit Preparation Guide

Eviquire packages are designed to support later explanation, but the software does not replace the investigator’s responsibility to prepare a clear narrative. Before presenting or disclosing Eviquire evidence, the investigator should be able to explain the collection process in ordinary language and then support that explanation with technical artifacts.

K.1 Preparing The Evidence Narrative

A strong evidence narrative answers five questions:

1. What was the investigative objective?
2. What source was accessed?
3. What tool and version were used?
4. What was collected?
5. How was integrity preserved after collection?

For example, an investigator might explain that they opened a specific case, started a web acquisition, navigated to a target URL, captured a screenshot and page source, allowed Eviquire to create an evidence package, and then closed the acquisition so that reports, hash lists, timestamps, and archives were generated. The supporting package then demonstrates the details: timestamps, URLs, hashes, reports, and chain-of-custody entries. Avoid overstating what the evidence proves. A screenshot can show that certain content was displayed to the forensic browser during the acquisition. It does not automatically prove authorship, intent, identity, or truthfulness. Those conclusions usually require additional investigation.

K.2 Preparing Technical Verification

For technical review, prepare a verification worksheet containing:

• Package name.
• Package type: evidence, acquisition, or case.
• Export date.
• Export location.
• SHA2-256 hash of the delivered ZIP.
• Summary JSON name.
• Archive hash from summary JSON.
• Report hash from summary JSON.
• Timestamp validation result.
• Blockchain reference, if available.
• Name and version of verification tools used.
• Reviewer name and date.

This worksheet can be maintained outside Eviquire as part of the case file. It helps a later reviewer reproduce the verification procedure without guessing which files were checked.

K.3 Explaining Hashes To Non-Technical Reviewers

When explaining hashes to attorneys, managers, or court personnel, use precise but simple language. A hash is a calculated fingerprint of a file. If the file changes, the fingerprint changes. Eviquire records hashes when evidence is captured and packaged. A reviewer can calculate the hash again later and compare it to the recorded value. Matching values support the conclusion that the file being reviewed is the same as the file described in the package metadata. Do not describe a hash as encryption. A hash does not hide the file. It verifies the file.

K.4 Explaining Timestamping

Timestamping can be explained as an external time proof over the summary JSON. The summary JSON contains hashes of important package files. Eviquire sends a timestamp request and stores the timestamp response. If validated, the response supports the conclusion that the summary existed in that form at the timestamp time. This does not mean every raw file was individually submitted to the timestamp authority. Instead, the summary acts as the integrity statement for the package. Because the summary records the archive and report hashes, timestamping the summary helps timestamp the package integrity record.

K.5 Explaining Chain Of Custody

Eviquire’s chain-of-custody logs document tool actions during acquisition. They show when the browser navigated, when pages loaded, when screenshots or sources were saved, when downloads occurred, when reports were generated, and when the session closed. The logs should be used together with investigator notes and organizational evidence-handling records. If asked whether the logs prove that no human error occurred, answer carefully. Logs document recorded application events. They do not replace investigator testimony, case notes, or independent validation. Their value is that they provide a contemporaneous technical record of the session.

K.6 Disclosure And Redaction Considerations

Before disclosing Eviquire packages, review whether the package contains sensitive artifacts beyond the visible evidence. Browser profiles, cookies, PCAP files, TLS key logs, mailboxes, downloaded files, and video recordings may contain private, privileged, or out-of-scope information. Legal teams should decide whether complete packages, filtered exports, reports only, or specific evidence packages are appropriate for disclosure. Never alter the original package to perform redaction. If redaction is required, create a derivative disclosure set, document the redaction process, preserve the original, and record hashes for both the original and derivative materials.