Ravindra BagaleCourses & study guides मराठी Track your progress

28. Introduction to Digital Forensics

28.4 Making and Verifying a Disk Image

By Last updated:

Disk forensics cha pahila step: bit-for-bit image banavne (nusti file copy nahi – purna disk, deleted data sah).

# list disks (identify the evidence disk carefully!)
lsblk
# make a raw image with dd (or 'dcfldd'/'dc3dd' which also hash while imaging)
sudo dd if=/dev/sdb of=evidence.dd bs=4M status=progress
# better: image and hash in one step
sudo dc3dd if=/dev/sdb of=evidence.dd hash=sha256 log=evidence.log
# verify the image matches the source
sha256sum /dev/sdb evidence.dd

In real work you attach the evidence disk through a write blocker so imaging cannot alter it. For practice, image your own spare USB stick.

Double-check if= and of=

dd copies exactly what you tell it. Swapping if= (input) and of= (output) can wipe the wrong disk. Read the lsblk output carefully and confirm the device names before running.

Ravindra Bagale's Tip

dd is also called "disk destroyer" – one mistake and the wrong disk is wiped clean! First confirm with lsblk exactly which /dev/sdX it is, then run the command. Running this command in a hurry can cost you dearly.

Lab

On a spare USB stick you own, make an image with dd (or dc3dd), record its SHA-256, and verify the image hash matches the source. Keep the .dd file for the next section.

Imaging habits that keep evidence usable

The commands in this lesson create a bit-for-bit copy. Always verify with hashes before and after.

  1. Write-block the source when hardware allows.
  2. Image to a clean destination drive.
  3. Compute SHA-256 of source and image; they must match.
  4. Record times, tool versions and hashes in the case log.

Real examples

Global: court cases have rejected evidence with broken hash chains. Indian company (sample): an IRCTC-contractor laptop case used FTK Imager hashes accepted by the investigating officer.

Recap

  • Matching hashes mean the copy is faithful.
  • Document every step.

Defender's worksheet (do this today)

  1. Write the lesson title and date in your notebook.
  2. List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
  3. Run one safe command or checklist item from the lesson on a lab system only.
  4. Paste the command and its output under an Evidence heading.
  5. Write one fix you would give a teammate in two sentences.
  6. Write one mistake students make with this topic and how to avoid it.

More real-world pictures

Indian workplace (sample data)

Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.

Global practice

Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.

Home and family

Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.

Connect to earlier chapters

Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.

Common mistakes

  • Skipping written permission just for a quick scan.
  • Practising on hostel or office Wi-Fi targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Teach one other person the warning from this lesson.