◇ OpenCyber Academy
Engineering · Chapter 34 · English

Chapter 34 — Digital forensics and malware analysis: integration

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 34 — Digital forensics and malware analysis: integration

Lesson map

Lesson 34 published. Map, example, EX100.

flowchart TD
  N0["Learning outcomes"]
  N1["34.1 Integration points"]
  N2["34.2 File-based interfaces"]
  N3["34.3 Mismatches"]
  N4["34.4 Storage"]
  N5["34.5 End-to-end test"]
  N6["34.6 Version compatibility"]
  N7["34.7 Documentation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX100"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["34.1 Integration points"]
  N2["34.2 File-based interfaces"]
  N3["34.3 Mismatches"]
  N4["34.4 Storage"]
  N5["34.5 End-to-end test"]
  N6["34.6 Version compatibility"]
  N7["34.7 Documentation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX100"]

[Learning outcomes]
    |
    v
[34.1 Integration points]
    |
    v
[34.2 File-based interfaces]
    |
    v
[34.3 Mismatches]
    |
    v
[34.4 Storage]
    |
    v
[34.5 End-to-end test]
    |
    v
[34.6 Version compatibility]
    |
    v
[34.7 Documentation]
    |
    v
[Worked example] --> [Exercise EX100]

Learning outcomes

You will (1) integrate EvidenceDesk with imaging tools and storage; (2) define file-based interfaces; (3) test integration end to end; (4) manage version compatibility.

34.1 Integration points

Imaging tools produce images and logs; storage holds them; examination tools read them. EvidenceDesk must ingest imaging logs, register image paths, and export records examiners can cite.

Priya draws the flow on a whiteboard: the write blocker and imager on the left, storage in the middle, examination suites on the right, and EvidenceDesk recording each handover. Every arrow is an interface where data could be lost or changed. She labels each one with what crosses it, such as an image file, a log, or a hash, and which side is responsible for checking it arrived intact.

34.2 File-based interfaces

Rather than linking to each vendor tool's internals, EvidenceDesk reads the acquisition log the imager writes, extracts tool name, version, digest and times, and asks the examiner to confirm. Parsing is tested against sample logs from each supported tool version.

Reading a vendor's internal libraries would tie EvidenceDesk to one product's release cycle and possibly its licence terms. Log files, by contrast, are produced anyway and are already part of the acquisition record. The confirmation step guards against a parser that silently picks the wrong field. Sample logs from each tool version are kept in the test folder with the values a human read from them, so parser output can be compared automatically.

34.3 Mismatches

If the log's digest differs from EvidenceDesk's own hash of the image, the acquisition is flagged, and the examiner investigates before proceeding.

Possible causes include a copy error after imaging, a fault in the storage, a bug in one hashing implementation, or a log that belongs to a different image. The examiner rehashes the image with a second tool, checks the log's file name and size, and records each step. If the image itself is damaged, it is reacquired from the original where possible, and the mismatch and its explanation stay in the record permanently.

34.4 Storage

Images go to write-once storage paths assigned by EvidenceDesk; the path is part of the record.

Letting examiners choose paths leads to images saved in personal folders or under inconsistent names that are hard to find years later. EvidenceDesk builds the path from the item identifier and acquisition number, so the location follows directly from the record. Because the path is stored with the hash, a later audit can open the file, rehash it and confirm that the stored image is the one the record describes.

34.5 End-to-end test

A synthetic item goes from intake through imaging, verification, working copy, examination flag and export. Every record and log is checked at the end.

Unit tests check each component on its own, but integration failures appear in the handovers: a time written in local zone by one tool and read as UTC by another, or a path that changes between steps. The synthetic item uses a small disk image with known contents, so every expected hash and record field can be written down in advance. The test runs before each release and after any tool upgrade.

34.6 Version compatibility

When an imaging tool updates, its log format may change. EvidenceDesk refuses unknown versions until a parser test is added.

An updated imager might move the digest to a different line or change its label, and a parser that guesses could record the wrong value without any visible error. Refusing unknown versions is inconvenient for a day or two, while an updated parser and test are written. During that window, examiners record the digest by hand from the log and a second person checks it, which is slower but leaves no silent errors.

34.7 Documentation

An integration guide lists supported tools and versions, and what to do with unsupported ones.

Each listed tool has the versions tested, the sample log used, and any quirks, such as an imager that writes times without a zone. For unsupported tools, the guide gives the manual route: attach the log as a file, type the key values, and have them checked by a colleague. The guide is versioned with EvidenceDesk itself, so a reader knows which software release a given page describes.

Clock agreement

Imager logs carry the imaging workstation's time; EvidenceDesk records its server's time. Priya compares both on every ingest and flags differences above one minute, so examiners can explain or correct clock drift before timelines depend on those times. Each flag is stored with the acquisition for review.

Worked example

A new imager version writes digests in uppercase. EvidenceDesk's comparison was case-sensitive and flagged every acquisition. Priya normalises case before comparison, adds a test, and records the change in the release notes.

Synthetic case. The imager behaviour is invented.

Errors and limits

Parsing third-party logs is fragile; confirmation by the examiner and independent hashing are the safety net.

Exercises

Synthesis

Integrate through tested file interfaces, hash independently and refuse what you have not tested.

Continue studying — chapter 34 of 50

← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →