Caine Partitions and Disks

Partition recovery tools work by assuming that a file system was located in each partition. Fortunately, many filesystems start with a data structure that has a constant "magic number" or signature value. For example, a FAT file system has the values 0x55 and 0xAA in byte offsets 510 and 511 of the first sector. The partition recovery tools search for these sort of signature values and identify where a partition may have started.

The search mechanism of each tool may vary. Some tools examine each sector and compare it to known signatures. Other tools search only cylinder boundaries because partitions are typically created on cylinder boundaries. Others may use data from the filesystem data structures to learn how big the filesystem is and jump to the end before searching for more known data structures.

An example of a linux tool that can be used for partition recovery is gpart. This command can identify a number of filesystem types by testing sectors and assessing which filesystem type is the most probable (ref B. Carrier, "File System Forensic Analysis").

First, lets search the /images/diskimg1.dd image file for signature value 0x55aa.

Execute the command:

  sigfind -o 510 55aa /images/diskimg1.dd

This should produce output similar to the following:

Block size: 512  Offset: 510  Signature: 55AA
Block: 0 (-)
Block: 63 (+63)
Block: 6803 (+6740)
Block: 6815 (+12)
Block: 48195 (+41380)
Block: 51051 (+2856)
Block: 51067 (+16)
Block: 64259 (+13192)
Block: 64260 (+1)
Block: 92460 (+28200)
Block: 92476 (+16)
Block: 112454 (+19978)
Block: 112455 (+1)
Block: 113512 (+1057)
Block: 127818 (+14306)
error reading bytes 257040

sigfind searches through a file and looks for the hex_signature at a given offset. This can be used to search for lost boot sectors, superblocks, and partition tables.

From the output you can see that there are many matches, but some of them are not relevent to finding the partitions. You need to look through the matches and identify the likely candidates for a valid partition, and/or remove useless matches.

Sometimes filesystem knowledge can help you, as for instance NTFS is formatted so that sector 0 and then the last sector of an NTFS partition both have a valid copy of the MBR (the last sector is a backup copy of sector 0). In FAT32 sector 6 usually holds a backup copy of the MBR sector 0.

Sometimes files in valid filesystems will co-incidentally have 0x55aa at offset 510. This can simply happen by chance. It is likely matches to sectors which lie within valid filesystems are not going to be deleted partitions.

Save the output of the sigfile command shown above in "/home/caine/blist1".

Using mmls on diskimg1.dd and the block information you stored in blist1, identify the blocks from blist1 which lie in unallocated areas of /images/diskimg1.dd and write them in the box below. Write them in the form of a list of numbers seperated by commas, and ordered in increasing numerical size e.g. 10,100,500,600. Be careful not to write any space characters in your answer.

So for instance if blist contained blocks 0,100,200,300, and 400, and your mmls command showed:

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000000002   0000000003   Unallocated
02:  00:00   0000000003   0000000199   0000000196   NTFS (0x07)
03:  00:01   0000000200   0000000299   0000000100   Unallocated
05:  Meta    0000000300   0000000500   0000000201   DOS Extended (0x05)
06:  Meta    0000000300   0000000300   0000000001   Extended Table (#1)
07:  -----   0000000300   0000000500   0000000201   Unallocated

Unallocated blocks from blist:

Which of the unallocated blocks listed in you answer is also the first block of an unallocated area, as well as being a cylinder boundary?

Often 0x003 to 0x00A of the partition boot block contains information in text form which could give a clue as to the nature of a particular boot block. Typical text messages include "MSDOS5.0", "mkdosfs" (for a dos like partition created from linux), and "NTFS ".

Examine the partition block 0 candidate identified above and using dd and xxd, examine this block and see what filesystem is suggested. Remember a "partition block" is the first block of a partition, not the first block of the whole hard drive.
"mkdosfs " "FAT12   " "FAT16   " "FAT32   " "NTFS    " "MSDOS5.0"

If you were wanting to try mounting this apparently deleted partition using a loop device, what offset would you use?

Mount this unallocated partition at /mnt using the candidate block as an offset for a loop device. Use /dev/loop0 as the loop device. Once mounted, "ls" the /mnt directory and count the number of files visible. In order to make the mount work, you should include "-o ro" at the end of the mount command.

Before continuing, unmount the /mnt directory, and delete the /dev/loop0 association. Make sure all loop devices have been deleted.

With all the data you have collected, what would you expect to see in the output for mmls concerning this partition which appears to have been deleted? Do not type in any leading zeros in your answer.

In this question we will use gpart and testdisk to attempt to restore the deleted partition.

"gpart" is not installed by default in caine. So do:

  sudo apt-get install gpart

We will also be writing a repaired partition table to the diskimg1dd file. However diskimg1.dd is read only. You COULD copy this file but remember some dd files might be huge and copying them too expensive. Instead we will potentially save a great deal of time and space by using a snapshot.

Snapshots allow us to create a device which allows you to write to a read only file by saving the writes to a different file. Sometimes this is called copy on write. In our case we only need to write a tiny amount of data (the partition table) so the snapshot size is going to be tiny.

Firstly create a small data file to hold the changes you will make to diskimg1.dd.

  sudo dd if=/dev/zero of=/root/changes bs=1024 seek=2047 count=1

Next we will pretend diskimg1.dd and /root/changes are hard drives rather than just files. To do this we use a device loop. This will make diskimg1.dd look like device /dev/loop1, and changes to look like /dev/loop2.

  sudo losetup /dev/loop1 /images/diskimg1.dd
  sudo losetup /dev/loop2 /root/changes

Now check the size of /dev/loop1. You need the block size.

  sudo blockdev --getsize /dev/loop1

Use this number in the following command where it says SIZE. This creates the snapshot of extent 0..SIZE, with loop2 being the snapshot and loop1 being the read only data. N 1 just indicates the transfer size in blocks.

  sudo dmsetup create sandbox --table "0 SIZE snapshot /dev/loop1 /dev/loop2 N 1"

The writable diskimg1.dd device is now available for use as "/dev/mapper/sandbox".

"gpart" is fairly clever, but it does need to know the correct disk geometry to work. On real hardware this is easy to get from the bios, but for image files you need to calculate this from the image itself.

Find out the C H S of the image using fdisk on /dev/mapper/sandbox.
C:
H:
S:

First try gpart, but we will not ask it to make any changes yet. The command is as follows. Remember to replace CYLINDER HEADS and SECTORS with the values from above.

  sudo gpart -gv -C CYLINDER,HEADS,SECTORS /dev/mapper/sandbox 

Check the suggested changes carefully. It often does a really good job, but it in this case makes 1 significant error. What is the error?
Error Made: Partition 1 mis-sized Partition 2 mis-sized Partition 3 mis-sized Partition 4 mis-sized Deleted partition not recovered Deleted partition was not set to the right type Logical partition replaced by primary partition Partition 1 has wrong chs Partition 2 has wrong chs Partition 3 has wrong chs Partition 4 has wrong chs

Now try testdisk.

  sudo testdisk /dev/mapper/sandbox 

This is an interactive tool. Select sandbox, Proceed, Intel, Geometry (then set the cylinders, heads, and sectors), Analyse (ignore FAT warnings). You should now see the current partition table with 3 partitions. Select Quick Search, Yes, and 4 partitions appear... Check the information then select Enter and Write, Yes, OK, Quit, Quit.

Verify you have succeeded by using mmls.

Cleanup all the loops and snapshots by doing the following:

  sudo dmsetup remove sandbox
  sudo losetup -d /dev/loop1
  sudo losetup -d /dev/loop2

The following questions all work by manipulating an USB drive which is virtually connected to your VIRTUAL computer. Press the button below to connect the USB drive to your VIRTUAL PC. You do not need a real usb drive, and this has nothing to do with your own computer, as this only relates to your virtual computer. To disconnect the USB stick, go to the end of this section and click the appropriate button.

The dcfldd command is an enhanced version of dd developed by the U.S. Department of Defence Computer Forensics Lab. It has some useful features for forensic investigators such as:

• On-the-fly hashing of the transmitted data.
• Progress bar of how much data has already been sent.
• Wiping of disks with known patterns.
• Verification that the image is identical to the original drive, bit-for-bit.
• Simultaneous output to more than one file/disk is possible.
• The output can be split into multiple files.
• Logs and data can be piped into external applications.

In a forensic investigation, it is important to make sure than anything you do does not effect the data on the disk being investigated. In the case of this investigation, the USB stick has been attached as a device called /dev/sdd.

Use md5sum to calculate the md5 checksum of the usb stick attached to /dev/sdd, and save the hash into /home/caine/usb.md5. Use sha256sum to calculate the sha 256 checksum of the usb stick attached to /dev/sdd, and save the hash into /home/caine/usb.sha256. Note the check buttons may take quite a few seconds to check the correct hashes.

Use the dcfldd command to capture this usb device. Use the format:

dcfldd if=/dev/sdd hash=md5,sha256 md5log=md5.txt sha256log=sha256.txt hashconv=after bs=512 conv=noerror of=usb.dd

Confirm that the md5 and sha256 you took of /dev/sdd matches the md5.txt and sha256.txt files created during this transfer.

In this section we will aquire the image again using GUYMAGER.

Guymager is a forensic imaging tool with a graphical interface. The forensic imager was designed to support different image file formats, to be most user-friendly and to run fast. It has a high speed multi-threaded engine using parallel compression for best performance on multi-processor and hyper-threading machines.

Features include:

• Fast due to multi-threaded, pipelined design and multi-threaded data compression
• Easy user interface available in different languages
• Generates flat (dd), EWF (E01) and AFF images, supports disk cloning
• Extended acquisition info file

Go to MAIN MENU > Forensic Tools > Guymager

In the case of Guymager, the usb device should appear as /dev/loop0. If it does not go to the Devices menu and select "add special device", and then in the box named "File name:" below the file browser window type "/dev/loop0" and then Open to add it.

Now select /dev/loop0 and right click on it and select "Acquire image".

Figure 1: Acquire Image

Fill in the information as shown and press "OK".

Figure 2: Select Image Format

Look into the usbEWF.info file and verify the acquisition. Check that the hashes shown match the hashes you generated earlier.

Repeat the process but this time capture in the advanced forensic format.

Figure 3: Advanced Forensic Format

Click here before moving on to disconnect the virtual USB stick

List the sizes of the image files you have created, i.e. the usb.dd file, and the EWF Expert Witness and AFF Advanced Forensic files.

Why are the files sizes different?
Image file sizes: No the file sizes are the same. They are different as the capture was incomplete. They are different due to errors which occurred during the capture. They are different due to different compression algorithms used.

Due to different size of images do you think that all three images contain the same information?
No. Yes. Maybe. Sometimes.

To verify all three images, open "Autopsy" and create a new case and add all images (usb.dd, usbEWT.E01 and usbAFF.aff).

Figure 4: New Case

Once the case is created add a host called "host1", and in that host add each of the image files as shown in Figure 5.

Figure 5: Add the Image

You should now have a similar view in Autopsy as that shown in Figure 6.

Figure 6: Viewing all the images

Select the usb.dd disk image in Autopsy, then select "Analyse" then press "Image Details" (found at the top of the page). Complete the following information (keep sizes in sectors):

Check the Expert Witness data and the Advanced Forensic images in Autopsy. Do they hold the same partition information as you entered for usb.dd above?
Same information?: DD is the same as EWF, but not AFF DD is the same as AFF, but not EWF EWF is the same as AFF, but not DD They are all different They are all the same