The assignment asked me to investigate the fictional disappearance of cryptography researcher Ethan Kane. I examined a Windows desktop disk image, a home-network packet capture, a laptop memory image and Android phone artefacts, then brought the findings into a timeline. This was an academic exercise with supplied evidence, not a real missing-person case or a complete professional forensic acquisition.
This article uses my October 2024 DOCX report for documented methods and findings. The DOCX contains no embedded images; six genuine figures come from a separate PDF version of the same coursework. I have not published either full report. The sources have unfinished hash, screenshot and custody fields, so these figures support specific analysis steps, not an end-to-end validated chain of custody. Evidence and limitations notes ↗
Establish what the desktop image contains before interpreting files.
My report records joining EvidenceA.001 and EvidenceA.002 into EvidenceA.dd, running MD5 and SHA-1 commands, and using Sleuth Kit's img_stat and mmls to inspect the image and partition table. I then used a calculated offset to mount the NTFS partition read-only. That mount let me browse the supplied Windows files without intentionally writing to the evidence image.
cat EvidenceA.001 EvidenceA.002 > EvidenceA.dd
img_stat EvidenceA.dd
mmls EvidenceA.dd
sudo mount -o ro,loop,offset=344981504 EvidenceA.dd /mnt/windows_mount
mmls output shows the layout used to locate the Windows volume. It does not fill the missing checksum appendix. Open at full resolution.A named user profile and journal files provided leads about the fictional subject. I also examined a password-protected ZIP recovered from the Recycle Bin with fcrackzip. Its journal entry, dated 3 August, described an intention to leave and hide research. That is a significant statement within the scenario, but not independent proof that the proposed departure occurred. The recovered password and journal text are not published here.
Use system artefacts to test the story around the files.
With RegRipper, I examined the SOFTWARE hive for Windows version and installed applications, the SYSTEM hive for time-zone configuration, and the user's NTUSER.DAT UserAssist data for recently run programs. The named user profile associated files with the scenario account; the RegisteredOwner field was a generic “Windows User,” so it could not independently establish who operated the machine. UserAssist pointed to activity worth correlating with other sources.
rip.pl -r /mnt/windows_mount/Windows/System32/config/SOFTWARE -p winver
rip.pl -r /mnt/windows_mount/Windows/System32/config/SOFTWARE -p uninstall
rip.pl -r /mnt/windows_mount/Users/Ethan\ Kane/NTUSER.DAT -p userassist
rip.pl -r /mnt/windows_mount/Windows/System32/config/SYSTEM -p timezone
The report flags an unusually named executable for further investigation but does not demonstrate what it did. Similarly, the Eastern Australia time-zone setting describes a computer configuration, not Kane's physical location. Both are contextual leads rather than conclusions.
Follow the packets, then separate traffic facts from identity claims.
I opened EvidenceB.pcap in Wireshark, filtered TCP traffic, and followed selected streams to inspect conversations and establish a communication window. The report records traffic from 1 to 23 September 2024. It names participant aliases, but captured aliases do not authenticate the people behind them. Packet times also need capture-clock and time-zone context before alignment with file-system or phone events.
Filtering on http.request exposed a Firefox 129 user-agent on Linux x86-64. That is what the client reported in the selected request, not an independently verified device or identity.
I also filtered FTP traffic and followed a control stream. It shows an anonymous login and a STOR command for sslkeyfile; the report also names pop.wav. I attempted to export and play the audio, but it was not recovered as usable sound. The FTP response records a transfer, not the file contents or a usable encryption key.
STOR filename and “Transfer complete” response support a transfer event, not the nature of the uploaded data. Open at full resolution.Start with the memory profile and process tree.
For EvidenceC.vmem, I used Volatility's imageinfo to select a Windows 7 SP1 x64 profile, then pstree to inspect process relationships. The reported tree included Firefox, Thunderbird, a text editor and command-line activity. Those names show processes in the capture; they do not by themselves prove a person's actions or that an unfamiliar executable was harmful.
vol.py -f EvidenceC.vmem imageinfo
vol.py -f EvidenceC.vmem --profile=Win7SP1x64 pstree
The report then dumps a Firefox process and runs strings with a URL pattern. That produced candidate addresses, but attempted places.sqlite recovery failed and a YARA search ended with an option-conflict error. I cannot present the strings as validated browser-history entries. The source also discusses email and password artefacts; I have omitted identifiers, hashes and recovered credentials.
Corroborate communication context without publishing private records.
I mounted the supplied Android images, listed installed packages and examined contacts, call-log and SMS SQLite databases with DB Browser for SQLite. The documented raw_contacts query gave the fictional investigation people to compare with packet-capture aliases. Installed messaging apps show only that apps were present, not that a particular message was sent through them.
SELECT display_name FROM raw_contacts;
The DOCX also records querying Chrome's History database for URLs and visit times, and checking selected image files for GPS metadata with ExifTool. Searches about location tracking and rainwater collection were context, not proof of travel. No GPS coordinates were found in the files examined; this does not establish that no location data existed elsewhere. Message bodies, numbers and addresses remain private.
Bring the sources together, but keep the hypothesis provisional.
The recovered journal entry is dated 3 August. Registry review places application-installation and execution leads in August. The packet capture supplies a September communication window, while phone and memory artefacts add possible context. This sequence is more useful than any single provocative filename or message, but it is not a fully normalized event timeline: the report does not reconcile every source clock or timestamp basis.
The submission proposed a voluntary disappearance. The journal supports an expressed intention to leave; communications and searches may be consistent with that account. They do not independently prove the disappearance happened as proposed, identify the people behind aliases, establish a location, or exclude alternatives. Interviews, source validation and corroborating records were recommendations, not documented completed steps.
Forensic value depends on provenance and restraint.
This exercise taught me to move between file-system, registry, packet, memory and SQLite evidence without treating tool output as a conclusion. Partition inspection makes a disk examinable; UserAssist points to activity; a network stream records what crossed the capture; a memory tree shows what was resident; and a phone database suggests relationships. Corroboration requires checking identities, clocks and collection integrity.
My main improvement would be a reproducible evidence register: complete acquisition notes and hashes, exact command/output references, source time zones, and a timeline separating observation, inference and uncertainty. The DOCX appendices have missing hash values and screenshot placeholders, so I cannot claim that documentation was achieved in this submission.
Sources: DIGITAL FORENSICS ASSIGNMENT.docx (11 October 2024), with six original figures from Digital Forensic Analysis Report (PDF, 16 October 2024). Evidence, source differences and limitations ↗