Disk forensics: imaging, write blockers, hashing and deleted files
In short: Disk forensics starts with an exact, verified copy of the drive made through a write blocker, so the original is never changed. Analysis then works on the image, using knowledge of the file system to find files, metadata and deleted data that has not yet been overwritten.
Why you image instead of browsing
Plugging a suspect drive into a normal computer and opening folders changes it. The operating system may write access times, create hidden folders or try to repair the file system. A forensic image is a bit-for-bit copy of the whole drive, including empty space, taken without changing the source. You then analyse the image and keep the original safe.
Write blockers and image formats
A write blocker sits between the suspect drive and your workstation and lets read commands through while blocking writes. Hardware write blockers are preferred for evidence because their behaviour is easy to test and explain. Software write blocking exists but depends on the operating system behaving correctly, so test and document it.
| Format | What it is | Notes |
|---|---|---|
| Raw (dd) | Plain byte-for-byte copy | Simple and widely supported; no built-in metadata or compression |
| E01 (Expert Witness Format) | Compressed image with case notes and embedded hashes | Very common in commercial and open-source tools |
| AFF4 | Open advanced format | Supports large and multi-source evidence; less common |
Common tools include FTK Imager, Guymager, and the command-line dc3dd and ewfacquire. A Linux lab example, with the source attached through a write blocker:
sudo dc3dd if=/dev/sdb of=/cases/exh004.dd hash=sha256 log=/cases/exh004.log
sudo ewfacquire -t /cases/exh004 -c best -D "EXH-004 laptop drive" /dev/sdbAlways confirm the device name carefully: imaging the wrong disk, or swapping input and output, can destroy data.
Hashing and verification
Hash the source before imaging and verify the image afterwards. SHA-256 is the normal choice today; some labs still record MD5 alongside it for compatibility with older tools, but MD5 alone is no longer considered strong. If the hashes do not match, find out why before going further. A failing drive with bad sectors is a common cause, and the imaging log should record which sectors could not be read.
Solid-state drives (SSDs) add a twist. The drive’s controller moves data around and the TRIM command lets it erase deleted blocks in the background, so deleted data may disappear quickly and two images taken minutes apart can differ. Note this in your report rather than treating it as tampering.
File systems and deleted files
A file system organises data on a disk. Windows uses NTFS, where the Master File Table (MFT) holds a record for every file with names, sizes and timestamps. Linux usually uses ext4, and Apple devices use APFS. Each keeps metadata that can show when files were created, changed or accessed.
Deleting a file normally just marks its MFT record and clusters as free. Until something overwrites them, the content is still there. Slack space is the unused end of the last cluster a file occupies and can hold fragments of older data. File carving searches raw data for known file headers and footers, such as the start of a JPEG, to rebuild files even without metadata. Volume Shadow Copies on Windows may hold older versions too.
Tip: practise with free test images published for training, or image a USB stick you own in a lab. Never image devices you are not authorised to examine.
Practice
What does a write blocker do?
Why might two images of the same SSD produce different hashes?
How can a deleted file still be recovered?
Key takeaways
- Analyse a verified forensic image, not the original drive.
- Use a tested write blocker and record the device details.
- Hash before and after imaging; SHA-256 is the normal choice.
- E01 adds compression, metadata and embedded hashes; raw is simplest.
- Deleted data often survives until overwritten, but SSD TRIM limits recovery.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.