How to acquire image of disk on Linux computer?

Question

Pertaining to computer forensics, if the suspect's computer (which cannot be removed from the scene), is Linux, can you directly use tools such as dd or dcfldd on his computer to acquire the disk image? Or do you need to use forensic live cds like Helix, Penguin sleuth or FFCU on top of the existing OS?

Answer 1

While running a command like

# dd if=/dev/sda of=/path/to/external/medium/file.img

on a live system will work, it's going to result in a number of problems which you won't have if you boot into a separate OS and make the image(s) from there:

1. If you image an entire disk, it probably contains a boot loader and a partition table. Those are going to get in your way when you go to try and do forensics/recovery on the image.

   What you really want is to image each filesystem independently:

   # dd if=/dev/sda1 of=/path/to/external/medium/filesystem1.img
   # dd if=/dev/sda2 of=/path/to/external/medium/filesystem2.img
   ...etc...
   

   Doing it this way makes mounting the filesystems trivial:

   # mount -oloop,ro filesystem1.img /mnt/fs1
   

   (I show the mount done as root because on some Linuxes, loop devices are locked down, so regular users can't use them.)

2. You're snapshotting live, mounted filesystems, so when you mount them later, it's effectively no different than if you had power-cycled the machine. The partitions will be "dirty," which can make mounting them without forensically damaging them difficult.

3. You're using the suspect machine's copy of dd(1). If someone were trying to hide something from you, they could provide a sneaky or malicious copy of dd(1).

Now, all that having been said, there are some good reasons to do an on-line clone. The best reason is that the system is using some form of filesystem or whole-disk encryption, and rebooting it will erase the decryption keys for the mounted volumes.

dd is not the right tool for this job, however, since that will just get you a copy of the encrypted-at-rest data. A regular backup is a better idea. E.g.,

# tar -cvJf --exclude={'/proc/*','/sys/*','/tmp/*'} \
  /path/to/external/medium/everything.tar.xz /

That won't discover hidden partitions and such, but at least it will force the OS to decrypt every file accessible directly from the root of the filesystem.

Answer 2

In a forensic investigation, you need to retrieve data from a possibly hostile system, and you need to provide strong evidence that the data you retrieved is genuine. Acquiring a disk image from the live computer is extremely bad in both respects.

The system software may be some non-standard software that's programmed to lie to you, and provide the “interesting” data only upon presentation of credentials that you don't have. For example, you may be interacting with a virtual machine that masquerades as the real hardware. System executables or the kernel may have been modified to not report genuine data. This is both a problem for you because you want genuine data, and a problem for any legal proceedings because the suspect's lawyer will have a field day showing that you can't prove that what you grabbed was genuine.

The normal procedure for any forensics is to disconnect the storage medium and connect it to your own laptop which is running software that you can precisely account for.

Furthermore, dd is the wrong tool for the job because it does not reliably copy its complete input. (If you're reading from a block device and not from a pipe, it might work, but good luck proving that with any measure of confidence.) At least use a proper tool like dcfldd or at least cat.

Not only can you not trust the software running on the computer, but you can't trust the hardware either. So it isn't safe to attempt to boot your own media on the suspect's computer. For example, your OS could end up running in a hypervisor that you can't detect but that returns corrupted data. You need to bring your own computer and connect the hard disk to it.

It's also important that you don't write to the suspect's computer (because you need the suspect's data, not your own data derived from the suspect's). So standard procedure is to connect the hard disk through a write blocker — a dedicated hardware component that enforces at the protocol level (e.g. USB storage protocol) that the disk will not be written to. Then you keep that grab as a reference copy — on physically write-once media if possible, on a hard disk that you never write to otherwise — and never work directly off it, only from secondary copies.

Preferably, grab an image of the whole disk, and reconstruct filesystems, etc. from there. Beware that the mere act of assembling volumes or mounting a filesystem (even read-only!) can modify it: setting a dirty bit, updating a last use date, replaying a journal, … When mounting an ext3/ext4 filesystem which wasn't cleanly unmounted, the noload mount option (in addition to ro) skips the journal update and causes nothing to be written to the disk; this has the downside that the data you'll read may be inconsistent (which can have a silver lining in making freshly deleted files still present).

If you need to get something from the live system, for example because the data is encrypted, then grab what you can the way you can. Document what you did as precisely as possible (taking videos may help). But grab the real underlying data in addition. Use what you got from the live system (typically keys) to reconstruct, in an easily traceable manner, the interesting data from the direct dump.

You'll find more information on this topic on Security Stack Exchange, in particular:

• Can DD on its own be used to acquire a hard drive?
• What are the options for acquiring disk image from a Linux computer that can't be removed from a crime scene?
• Write-protection at hardware level for security
• How reliable is a write protection switch on a USB flash drive?
• What should be included in a jump bag and how often should it be reviewed?