Chapter 41 — Digital forensics and malware analysis: system optimization
Lesson map
Lesson 41 published. Map, example, EX121.
flowchart TD
N0["Learning outcomes"]
N1["41.1 Profile first"]
N2["41.2 The fix"]
N3["41.3 Integrity check"]
N4["41.4 What not to optimise"]
N5["41.5 Parallelism"]
N6["41.6 Memory"]
N7["41.7 Measuring gains"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX121"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["41.1 Profile first"]
N2["41.2 The fix"]
N3["41.3 Integrity check"]
N4["41.4 What not to optimise"]
N5["41.5 Parallelism"]
N6["41.6 Memory"]
N7["41.7 Measuring gains"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX121"]
[Learning outcomes]
|
v
[41.1 Profile first]
|
v
[41.2 The fix]
|
v
[41.3 Integrity check]
|
v
[41.4 What not to optimise]
|
v
[41.5 Parallelism]
|
v
[41.6 Memory]
|
v
[41.7 Measuring gains]
|
v
[Worked example] --> [Exercise EX121]
Learning outcomes
You will (1) optimise EvidenceDesk without weakening integrity; (2) profile before optimising; (3) measure gains; (4) record trade-offs.
41.1 Profile first
Users complain that export is slow for large cases. Priya profiles: 80% of export time is spent recomputing the entire chain for each page of the PDF. Guessing would have pointed at PDF rendering.
A profiler records how much time each function consumes during a real run. Without it, Priya's instinct was that PDF rendering was slow, and she might have spent a week replacing the renderer for little gain. Profiling a 5,000-event export shows the chain function called once per page, each time walking the whole history from the start.
41.2 The fix
Compute the chain once per export and reuse it. Export time for a 5,000-event synthetic case falls from 90 seconds to 6.
The change is small: compute the chain at the start of export, keep the results in a list, and pass them to each page. Fifteen-fold improvements from one change are common when the cause is repeated work rather than slow code. Priya keeps the profiler output from before and after in the change record as evidence for the claim. The page output is unchanged.
41.3 Integrity check
The optimisation must not change outputs. Priya compares exports before and after for twenty synthetic cases: identical bytes apart from the generation timestamp.
Byte-level comparison is a strict test: any change in ordering, number formatting or hash value would show up. The generation timestamp is the only expected difference, so the comparison masks just that field. Twenty cases cover small, large, corrected and empty histories. If any byte differed, the optimisation would be reverted until the difference was explained. The comparison script joins the test suite.
41.4 What not to optimise
Skipping verification reads, or caching hash results across sessions without re-reading data, would be faster but would remove the guarantee that stored images are intact. These are rejected and documented.
Caching a hash is tempting because images rarely change, but 'rarely' is exactly the case verification exists to catch: silent corruption, media decay, or tampering. A cached value would keep reporting the old, correct hash after the data had changed. Documenting the rejected ideas stops a future developer from adding them in good faith.
41.5 Parallelism
Verifying several images at once uses multiple drives in parallel, limited by storage throughput measured earlier.
Two images on separate drives can be verified at once with nearly double throughput, but two on the same drive compete for its read head and can be slower together than one after the other. EvidenceDesk therefore schedules jobs per storage device. The limit comes from the bottleneck measurements, and Priya checks it again whenever storage hardware changes. Jobs on the same drive wait in a single line.
41.6 Memory
Streaming reads keep memory use flat regardless of image size.
Streaming means reading a fixed-size chunk, updating the hash, and discarding the chunk before reading the next. A 64 KiB buffer uses the same memory for a 1 GB image as for an 8 TB one. Loading a whole image into memory would fail outright on large drives. A test hashes a file larger than the test machine's RAM to confirm the design holds. Verification of a large image never pauses the interface because of memory pressure.
41.7 Measuring gains
Report before and after with the same inputs and hardware, and the number of runs.
Changing hardware between runs could make a slower version look faster. Repeating runs reveals variation: if five runs of the old version range from 85 to 95 seconds, a single 88-second run of a new one shows nothing. Priya reports the median and range for each, so readers can judge whether a gain is real. She also states the case size used, because a gain on 5,000 events may not hold for 50 or for 500,000.
41.8 User experience
Progress indicators for long verifications reduce the temptation to cancel and skip.
A twelve-hour verification with no feedback looks frozen, and staff under pressure may cancel it and mark the item as checked from memory. A progress bar showing bytes processed and estimated time remaining, plus a log line every few minutes, makes clear the job is working. A cancelled job is recorded as cancelled, never as passed. Examiners told about the remaining time also plan other work around the job instead of waiting at the screen.
Benchmark suite
Priya keeps a small benchmark suite — exports of three synthetic case sizes and verification of a fixed image — run before each release on the reference workstation. A slowdown of more than 20% blocks release until it is explained, which catches accidental regressions early and keeps performance claims honest.
Worked example
A proposal to store each image's last verification result and skip re-verification if the file's modification time is unchanged is rejected: modification times can be altered, and the purpose of verification is to read the data. Priya records the proposal, the reason and the decision.
Synthetic case. The profiling numbers are invented.
Errors and limits
Optimisations add complexity; keep only those whose benefit is measured and whose risk is understood.
Exercises
- EX121 — Profiling result. What did profiling reveal? Rubric: 3 = chain recomputed per page, 80% of time; 2 = partial; 1 = PDF rendering; 0 = none.
- EX122 — Output check. How was the optimisation shown not to change outputs? Rubric: 3 = byte-compare 20 exports except timestamp; 2 = partial; 1 = trust; 0 = none.
- EX123 — Rejected shortcut. Why reject skipping verification when mtime is unchanged? Rubric: 3 = mtime alterable; verification must read data; 2 = partial; 1 = slower; 0 = none.
Synthesis
Profile, optimise what matters, prove outputs unchanged, and never trade away the integrity guarantee.
Continue studying — chapter 41 of 50
← Chapter 40 (draft) · Course chapter index · Chapter 42 (draft) →