Carving partitions with dd
Now we can try a more useful exercise in carving withdd. Often, you will obtain or be given addimage of a full disk. At times you might find it desirable to have each separate partition within the disk available to search or mount. Remember, you cannot simply mount an entire disk image, only the partitions.
This can be accomplished in a number of ways. One theoretically complex method would be to use the Enhanced Loopback driver (provided by NASA’s Computer Crimes Division) to associate an entire disk image with a single loop device that is “partition aware”. We will talk more about this method a little later.
The method we will use in this exercise entails identifying the partitions within addimage using the standard loopback device along withfdiskorsfdisk. We will then useddto carve the partitions out of the image.
First, let’s grab the practice disk image that we will be working on. This is addimage of a 330MB disk from a Linux system that was compromised (“hacked”).
ftp://ftp.hq.nasa.gov/pub/ig/ccd/linuxintro/able2.tar.gz
Thetararchive contains the disk image, the MD5 digest values, and the imaging log file with information collected during the imaging process.
Create a directory called “able2” in your_/root_directory. This will be the working directory for the following exercise. Again, the vast majority of steps taken in preparation for, and execution of a forensic analysis require root access to commands and devices.
Once you have downloaded the file, check the md5sum (it should match the output below):
md5sum able2.tar.gz
a0cef6c441ae84ef931c541d73ee619f able2.tar.gz
The file name is derived from the original_hostname_of the machine that was compromised (“hacked”). Very often we name our cases and evidence with the original hostname of the machine we are investigating.
If the MD5 matches, then we can continue…We now need to check the contents of thetararchive, then extract and decompress the archive.
tar tzvf able2.tar.gz able2.dd (disk image)able2.log(log of the collection)md5.dd (md5 hash of the image)
md5.hdd (md5 hash of the original disk)
tar xzvf able2.tar.gz
This executes thetarcommand with the options–xto extract the files,-zto decompress the files,-vfor verbose output, and–fto specify the file.
Have a look at the files that result:
ls -lh
total 464M
-rwxrwxr-x 1 root root 330M Aug 10 21:16 able2.dd -rwxrwxr-x 1 root root 3.6k Aug 11 07:56 able2.log
-rwxrwxr-x 1 root root 134M Aug 11 14:42 able2.tar.gz
-rwxrwxr-x 1 root root 43 Aug 10 21:16 md5.dd
-rwxrwxr-x 1 root root 43 Aug 10 21:04 md5.hdd
The output ofls –lh(the–lhis for “long list with human readable sizes”) shows the 330MBddimage, the logfile and two files that record the original MD5 hashes, one for the image (md5.dd) and one for the original disk (md5.hdd). At this point you can check the hash of the_able2.dd_and compare it to the value stored in_md5.dd_to be sure the image is intact.
cat md5.dd
02b2d6fc742895fa4af9fa566240b880 able2.dd
md5sum able2.dd
02b2d6fc742895fa4af9f__a566240b880 able2.dd
Okay, now we have our image, and we have verified that it is an accurate copy. We now want to know a little bit about the contents of the image and what it represents. During the evidence acquisition process, it is essential that information about the disk be recorded. Standard operating procedures should include collection of disk and system information, and not just theddimage itself.
The file_able2.log_was created from the output of various commands usedduring the ev**idence collection process. The log includes information about the investigator that gathered the evidence, information about the system, and the output of commands includinghdparm,fdisk,sfdisk**and hashing functions. We create the log file by appending (“>>”) the output of the commands, in sequence, to the log:
command>> logfile.txt
Look at the log file,_able2.log,_usinglessand scroll down to the section that shows the structure of the disk (the output offdisk –l /dev/hddandsfdisk –l –uS /dev/hdd):
fdiskoutput for SUBJECT disk:
Disk /dev/hdd: 345 MB, 345830400 bytes
15 heads, 57 sectors/track, 790 cylinders
Unit__s = cylinders of 855 * 512 = 437760 bytes
Device Boot Start End Blocks Id System
/dev/hdd1 1 12 5101+ 83 Linux
/dev/hdd2 13 132 51300 83 Linux
/dev/hdd3 133 209 32917+ 82 Linux swap
/dev/hdd4 210 790 248377+ 83 Linux
#####################################################sfdiskoutput for SUBJECT disk:
Disk /dev/hdd: 7__90 cylinders, 15 heads, 57 sectors/track
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System /dev/hdd1 57 10259 10203 83 Linux /dev/hdd2 10260 112859 102600 83 Linux
/dev/hdd3 112860 178694 65835 82 Linux swap
/dev/hdd4 178695 675449 496755 83 Linux
The output shown above is directly from the victim hard drive (the machineable2), recorded prior to obtaining theddimage. It shows that there are 4 partitions on the drive. The data partitions arehdd1, hdd2_and_hdd4. The_hdd3_partition is actually a_swap_partition (for virtual memory). Remember that the designation_hdd_indicates that the victim hard drive was attached to our forensic workstation as the slave drive on the secondary IDE controller during the imaging process, NOT how it was attached inthe original machine.
The commandsfdisk –l –uS /dev/hddgave us the second listing above and shows the partition sizes in units of “sectors” (-uS). The output also gives us the start of the partition. For our partition carving exercise (as with the raw data carving), all we need is the starting offset, and the size.
Let’s go ahead andddout each partition. If you have the output ofsfdisk –l –**uS /dev/hdx,**the job is easy.
dd if=able2.dd of=able2.part1.dd bs=512 skip=57 count=10203 dd if=able2.dd of=able2.part2.dd bs=512 skip=10260 count=102600 dd if=able2.dd of=able2.part3.dd bs=512 skip=112860 count=65835 dd if=able2.dd of=able2.part4.dd b**s=512 skip=178695 count=496755**
Examine these commands closely. The input file (if=able2.dd) is the full disk image. The output files (of=able2.part#.dd) will contain each of the partitions. The block size that we are using is the sector size (bs=512),which matches the output of thesfdiskcommand. Eachddsection needs to start where each partition begins (skip=X),and cut as far as the partition goes (count=Y).We also obtained partition number three, the swap partition. This can also be searchedwithgrepandstrings(or carving utilities) for evidence.
This will leave you with four_able2.part*.dd_files in your current directory that can now be loop mounted.
What if you have addimage of the full disk, but no log file or access to the original disk, and therefore no info fromsfdiskorfdisk?
We can use the standard loopback device to associate theddimage with a device, and then run our commands against that:
losetup /dev/loop0 able2.dd
As we discussed earlier (during our floppy exercise), theloop_device allows us to associate a regular file (forensic image) with a device. In this case we have addimage that we want to view as a disk. We uselosetupto tell the system to associate thefile_able2.dd_to the device file/dev/loop0.Essentially, this makes/dev/loop0_look like the original disk.
sfdisk –l –uS /dev/loop0
Disk /dev/loop0: cannot get geometry
Disk /dev/loop0: 0 cylinders, 0 heads, 0 sectors/track Warning: The first partition looks like it was made for C/H/S=*/15/57 (instead of 0/0/0). For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System /dev/loop0p1 57 10259 10203 83 Linux /dev/loop0p2 10260 112859 102600 83 Linux
/dev/loop0p3 112860 178694 65835 82 Linux swap /dev/loop0p4 178695 675449 496755 83 Linux
Aside from the error messages at the beginning of the output, notice that the actual disk geometry (in sectors) matches that taken from the original disk! The partitions are now noted as/dev/loop0p*, indicating, “loop device zero, partitions 1 through 4”. In a pinch, we could use this to gather information from the standard loop device to determine the disk partitioning5.
When you are finished with the_loop0_association, be sure to remove it:
losetup –d /dev/loop0
Unfortunately, you cannot mountthe partitions associated with/dev/loop0p*. The block devices don’t actually exist. This is where the NASA Enhanced Loopback Driver comes in.
5. The purpose of this section is to explore the concept of theloopdevices in more detail. In actuality, the originalddimage is a file just like/dev/loop0or/dev/hdx. Try thefdiskorsfdiskcommands on theddimage itself to see what I mean. ↩