Part II Checkpoint: Read the Evidence
Where you are: Part II — The Technical Foundations · Checkpoint · This checkpoint brings together Chapters 2.2 to 2.6 of Dr. Al-Doori's IT Forensics Essentials: hashes, hexadecimal and file signatures, storage, volatile data, Windows artifacts and FTK Imager.
Part II Checkpoint: Read the Evidence
You have finished Part II. This checkpoint gives you three short, realistic situations that test how well you can read the technical traces evidence leaves. For each one, read the scenario, choose what you would do, and then read the model answer. There is no score to record. Allow about 12 minutes.
All people, organizations and values below are fictional.
Scenario 1: The Hashes Do Not Match
An examiner was asked to acquire data from a company web server that could not be taken offline. She hashed the server's live data volume at 10:02, began the acquisition, and at 10:47 hashed the volume again for comparison. The two SHA-256 values are different. Her image file's internal verification, however, shows that the image matches the data as it was read.
What is the most likely explanation, and what should she do?
Model answer: d. The book warns that hashing a running system gives different results because background processes keep changing data. That is expected, not suspicious. The image's own verification shows it is an exact copy of what was read. The book's rule is that hashes should match, and if they do not, you must try again or explain why. Here she can explain, so she documents it. Option a throws away good evidence. Option c jumps to a conclusion the evidence does not support. Option b gets it backwards: MD5 is the weaker algorithm.
Scenario 2: The Song That Is Not a Song
In an investigation into stolen design documents, signature analysis flags a file called track07.mp3 in a music folder. Its first four bytes are 50 4B 03 04.
What is the best next step?
Model answer: c. 50 4B 03 04 ("PK") is the ZIP signature, which modern .docx, .xlsx and .pptx files also start with. That makes it worth examining, on the image, with forensic tools. But a mismatch alone does not prove that it holds the stolen designs, or who renamed it (b). Option a misses a classic hiding technique. Option d would change the original evidence.
Scenario 3: The Running Laptop with an SSD
Investigators with a valid warrant find a suspect's laptop switched on and unlocked. It has a solid-state drive with BitLocker encryption, and a chat application is open. The lead investigator wants to switch it off and take it to the lab, where a full physical image of the SSD will be made next week.
Which plan best fits what you learned in Part II?
Model answer: a. Memory may hold the BitLocker key and the open chat, and both are lost at shutdown. Without the key, a physical image of the encrypted SSD may be unreadable. RFC 3227's order of volatility puts memory before disk. SSDs can also erase deleted data through TRIM and garbage collection whenever they are powered, so imaging should not wait a week. Option b loses the volatile evidence. Option c changes the evidence and is not a forensic method. Option d risks remote wiping and continued change.
Before You Move On
If any of these felt uncertain, revisit the lesson behind it: Lesson 2.1 for hashes, Lesson 2.2 for signatures, Lesson 2.3 for SSDs and slack space, and Lesson 2.4 for volatile data and the order of volatility. Next, Part III brings digital forensics together with incident response.
Sources
- Dr. Tahseen Al-Doori — IT Forensics Essentials: Concepts, Tools, and the Practice of Digital Investigation, Chapters 2.2–2.6
- IETF — RFC 3227: Guidelines for Evidence Collection and Archiving
- GCK's File Signatures Table (Gary Kessler, hosted by SEARCH)
- Microsoft Learn — BitLocker overview: device encryption
- arXiv — Hadi, Ullah and Harris, SSD Forensic: Evidence Generation and Forensic Research on Solid State Drives Using Trim Analysis (2023)