If you can see this check that

Main Page

Caine Forensic Partitions and Disks

Caine Partitions and Disks


In this practical we will continue to look at ways of handling disks and partitions in a forensic investigation.

To reset all the check buttons from a previous attempt click here

Question 1: sigfind

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 relevant 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".

Tests - not attempted
blist1 is valid UNTESTED

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
then go through the list of blocks seeing which ones lie between the start and end block numbers of Unallocated areas only. Take care, as some blocks appear to be both allocated and unallocated, such as block 300 which is in "05:", "06:", and "07:". As "06:" and "07:" are both allocated for a disk purpose, block 300 is therefore considered allocated... So in the case of 0,100,200,300, and 400, block 0 is in the Primary Table,block 100 is in an NTFS area, block 200 is Unallocated, block 300 is DOS Extended, and block 400 is Unallocated. Thus the answer would be "200,400".

Unallocated blocks from blist:

Tests - not attempted
Blocks unallocated UNTESTED

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?

Tests - not attempted
Block unallocated and block 0 candidate UNTESTED

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.

Tests - not attempted
OEM entry in partition block UNTESTED

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

Tests - not attempted
block 0 candidate offset UNTESTED

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.

Tests - not attempted
/dev/loop0 is associated with diskimg1 UNTESTED
/dev/loop0 offset seems right UNTESTED
Right no of files found UNTESTED

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

Tests - not attempted
No mount at /mnt UNTESTED
No loop devices in use UNTESTED

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.

Tests - not attempted
Numbers look ok UNTESTED
Description looks ok UNTESTED

Question 2: gpart and testdisk

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

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 --getsz /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".

Tests - not attempted
gpart available UNTESTED
loop1 is correct UNTESTED
loop2 is correct UNTESTED
Snapshot created UNTESTED
gpart available UNTESTED

"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.

In the latest Caine, the fdisk tool used to answer this no longer displays the geometry. In the interim, you cannot pass this check, even if you have the correct answer. However you still need the data to do the rest of the questions. Note that the CHS is 16/255/63. We will work on a better way to discover it asap.

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

Tests - not attempted
Geometry check UNTESTED

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:

Tests - not attempted
Second partition restored UNTESTED

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.

Tests - not attempted
Second partition restored UNTESTED

Cleanup all the loops and snapshots by doing the following:

  sudo dmsetup remove sandbox
  sudo losetup -d /dev/loop1
  sudo losetup -d /dev/loop2
Tests - not attempted
snapshot removed UNTESTED
loops deleted UNTESTED

Question 3: Forensic Capture

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.

Tests - not attempted
Mounted USB stick UNTESTED

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.

Tests - not attempted
USB connection is still ok UNTESTED
usb.md5 is ok UNTESTED
usb.sha256 is ok UNTESTED

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.

Tests - not attempted
USB connection is still ok UNTESTED
md5.txt looks ok UNTESTED
sha256.txt looks ok UNTESTED
md5 is the same UNTESTED
sha is the same UNTESTED

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".

Acquire Image
Figure 1: Acquire Image

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

Image Format
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.

Tests - not attempted
USB connection is still ok UNTESTED
usbEWF.info file exists UNTESTED
usbEWF.info includes sha256 UNTESTED
usbEWF.info includes md5 UNTESTED
usbEWF.info case no ok UNTESTED
usbEWF.info evidence no ok UNTESTED
usbEWF.info is in expert witness format UNTESTED

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

To enable AFF format open /etc/guymager/guymager.cfg. Find the line

   AFFEnabled = false
and change to "true".

Advanced Forensic Format
Figure 3: Advanced Forensic Format
Tests - not attempted
USB connection is still ok UNTESTED
usbAFF.info file exists UNTESTED
usbAFF.info includes sha256 UNTESTED
usbAFF.info includes md5 UNTESTED
usbAFF.info case no ok UNTESTED
usbAFF.info evidence no ok UNTESTED
usbAFF.info is in advanced forensic format UNTESTED

Click here before moving on to disconnect the virtual USB stick

Tests - not attempted
USB stick removed UNTESTED

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.

FileSize in Bytes
Expert Witness image file 1
Advanced Forensic image file
Tests - not attempted
Image files still ok UNTESTED

Why are the files sizes different?
Image file sizes:

Tests - not attempted
Explain the sizes UNTESTED

Due to different size of images do you think that all three images contain the same information?

Tests - not attempted
Does the size matter? UNTESTED

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

New Case
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.

Add image
Figure 5: Add the Image

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

All the images
Figure 6: Viewing all the images
Tests - not attempted
Case file exists for 'Test' UNTESTED
Case file has a description UNTESTED
Host file exists for 'host1' UNTESTED
Image usbAFF has been symlinked UNTESTED
Image usb.dd has been symlinked UNTESTED
Image usbEWF has been symlinked UNTESTED
Three disks added UNTESTED

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?:

Tests - not attempted
00:00 start UNTESTED
00:00 end UNTESTED
00:00 size UNTESTED
00:00 type UNTESTED
00:01 start UNTESTED
00:01 end UNTESTED
00:01 size UNTESTED
00:01 type UNTESTED
usbEWF and AFF the same? UNTESTED

Centos 7 intro: Paths | BasicShell | Search
Linux tutorials: intro1 intro2 wildcard permission pipe vi essential admin net SELinux1 SELinux2 fwall DNS diag Apache1 Apache2 log Mail
Caine 9.0: Essentials | Basic | Search | SysIntro | 5a | 5b | 5c | 6 | 7a | 7b | 8a | 8b | WebBrowserScript | Registry | Browser
CPD: Cygwin | Paths | Files and head/tail | Find and regex | Sort | Log Analysis
Kali: 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7a | 8a | 8b | 9 | 10 |
Useful: Quiz | Forums | Privacy Policy | Terms and Conditions
Site Links:XMLZoo ActiveSQL ProgZoo SQLZoo

Linuxzoo created by Gordon Russell.
@ Copyright 2004-2018 Edinburgh Napier University