If you can see this check that

Main Page

System Level Disk Control

System Level Disk Control



This practical covers an introduction to system administration level commands which are useful for forensics. This is mostly focused on disk and block control. The commands considered include:

fdisk family (e.g. cfdisk)

Concepts covered include snapshot disks, disk control, and block reads and writes.

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

Question 1: DD and data blocks

This initial button sets up a few files needed for the rest of this question. You can click the button multiple times, and each time it will restore the files back to their starting format. This could be useful if you accidentally damage one of these files.

The file created which you will be using is /home/caine/small.dd, which represents a 64kb disk image.

Tests - not attempted
Setup Scenario UNTESTED

Assuming a block size of 512 bytes, extract block 4 (counting from block 0) from small.dd and write that block to /home/caine/block4.dd.

Tests - not attempted
Small.dd is not damaged UNTESTED
block4 ok UNTESTED

The device file "/dev/zero" produces an infinite number of 0 bytes (i.e. a long string of 0x00). This can be useful if you want to produce a file with all the data set to 0.

Using the dd command, and using "if=/dev/zero", copy 512 bytes from /dev/zero and create a file "/home/caine/zero.dd" which is 512 bytes long and filled with zeros. Remember to give the dd command a limit, or the command will never finish and you will run out of diskspace!

If you forget to put in a limit, and the dd command is taking more than a second, press CTRL and C, which will kill off the dd command...

Tests - not attempted
zero.dd created ok UNTESTED

Copy small.dd to copy.dd, and then set block 9 (i.e. the 10th block) of THE COPY (i.e. copy.dd) to be all zeros. To do this "dd" zero.dd into block 9 of copy.dd. Do not change small.dd.

One complexity of doing this is that the default behaviour of dd is to truncate the destination file. So if you change block 9, block 10 onwards will be deleted from the file and the file made much shorter. You therefore MUST tell dd not to truncate by doing "conv=notrunc".

Tests - not attempted
Small.dd is not damaged UNTESTED
copy.dd copied and updated UNTESTED

Copy small.dd to copy2.dd, and then overwrite block 2 of copy2.dd with block 10 of small.dd. In all cases the first block of a disk is called block 0. Again do not truncate.

Tests - not attempted
Small.dd is not damaged UNTESTED
copy2.dd copied and updated UNTESTED

Using the "strings" command and grep together, look for a sentence with the word "secret" which exists in small.dd. What is the last word in the sentence found?
Last word in the sentence:

Tests - not attempted
Small.dd is not damaged UNTESTED
Last word is right UNTESTED

Adapt your command from the last question, using the option in strings of "-t d", and calculate the block number (where the first block is known as block 0) where the string containing the word "secret" is stored.
Block number of the sentence:

Tests - not attempted
Small.dd is not damaged UNTESTED
Correct block number UNTESTED

Question 2: Intro to Physical Disks

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

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. Make sure you enter this as a lowercase hex number.
md5 hash:

Tests - not attempted
USB connection is still ok UNTESTED
Hash is correct UNTESTED

Using the sfdisk command, making sure you are using "sectors" as units, get a partition table listing of /dev/sdd. What information can be found?

Partition nameStart sectorEnd Sector
Tests - not attempted
USB connection is still ok UNTESTED
/dev/sdd1 is ok UNTESTED
/dev/sdd2 is ok UNTESTED

How many bytes is the partition /dev/sdd1?
Size of sdd1:

Tests - not attempted
USB connection is still ok UNTESTED
/dev/sdd1 size is ok UNTESTED

If you were going to DD partition sdd1 from /dev/sdd to /home/caine/usb1.dd, what parameters would you use?

dd if=/dev/sdd of=/home/caine/usb1.dd skip= bs=512 count=
Tests - not attempted
Correct parameters UNTESTED

Click here before moving on to disconnect the virtual USB stick

Tests - not attempted
USB stick removed UNTESTED

Question 3: SUDO

Sometimes in caine you will have to run commands as the administrator, rather than as caine. The administrator username is called "root". In these tutorials you may see some commands written with underscores, such as mount. This is a hint to you that the command needs to run as the administrator. This hint will not always be shown, so eventually you should be able to work out when a command needs to be executed as the administrator yourself!

To run a command as the administrator you need to begin the command with the string "sudo ".

First, try to print to the screen the first line of /etc/shadow, using the head command. What happens?
Error message:

Tests - not attempted
Message seen UNTESTED

Now try:

sudo head -1 /etc/shadow
With sudo, it may ask for the password of caine, the current user. This is just a security check. Enter the caine password, i.e. "caine".

What is the word that appears at the beginning of the first line, ignoring all the text after the first colon ':'. So if the line was:

the answer would be "jim".
First word of shadow:

Tests - not attempted
First word of shadow UNTESTED

As the administrator, what is the whole of the last line of /etc/gshadow?
Last line of gshadow:

Tests - not attempted
Correct last line UNTESTED

Question 4: Mount and umount

In this question we will be accessing a different USB stick. Again we need to virtually connect this first to our virtual computer. Again click on the connect button below to connect. Once you are finished with this question then at the end of the question click on Remove USB stick to disconnect it.

Tests - not attempted
Mounted USB stick UNTESTED

In this set of questions we are going to access disks and disk images which have been created under operating systems other than Linux. This can lead to some inconsistences.

In some images the idea of physical C/H/S and the logical C/H/S being identical is lost. This can happen for a variety of reasons, such as errors in the disk capture or simply bugs or misunderstandings by the code which originally formatted the disk. Additionally the BIOS usually tries to report geometry, but for a captured disk image the BIOS does not know the disk geometry. So dont worry about errors like "cannot get geometry". Usually geometry is stored in the partition table too, and the tools we use can access this.

Lastly, linux likes partitions to use all available space, but some systems perfer to stop partitions on a cylinder boundary. So do not worry too much about expected/found errors involving C/H/S where "found" indicates a cylinder end and "expected" is just slightly more space...

The new USB device in /dev/sdd. What sort of filesystem partition is partition 1? How many BYTES into the disk is it before this partition starts? How many BYTES is it in length? Hint: Use sfdisk.
What is the partition type?
Offset in bytes:
Length in bytes:

Tests - not attempted
Correct partition type UNTESTED
offset is ok UNTESTED
length is ok UNTESTED

Assume your forensic lab technician has captured a disk image of /dev/sdd as a file called /images/usbimg1.dd. Verify the capture was successful by storing the md5sum of /dev/sdd in /home/caine/usbdev.hash, and storing the md5sum of /images/usbimg1.dd as a file /home/caine/usbdd.hash. Confirm the contents of these files to ensure they have the same hash value.
Are the hashes the same?

Tests - not attempted
/home/caine/usbdev.hash exists UNTESTED
usbdev.hash correct UNTESTED
/home/caine/usbdd.hash exists UNTESTED
usbdd.hash correct UNTESTED
Hashes the same? UNTESTED

Click here before moving on to disconnect the virtual USB stick

Tests - not attempted
USB stick removed UNTESTED

We are going to mount the disk image in such a way as to be able to use standard Linux command to see what is on the disk image. To do this you need a loop device. Loop devices are numbered 0 to 9, and for instance the first loop device is called /dev/loop0. Loop devices allow you to like a file to a disk device, thus allowing you to use your linux disk commands on disk images as well as normal disks. In this way /dev/loop0 is similar in functionality to /dev/sdd.

First, create a loop device /dev/loop5, which is associated with /images/usbimg1.dd, using an offset in bytes which is the offset in bytes which you previously calculated for partition 1. This uses the "losetup" command in the format:

losetup /dev/loop5 /images/usbimg1.dd -o OFFSET
where OFFSET is the offset you calculated previously. Note that "losetup" is underlined. This is a hint to you that this command needs to run with administration privilages. Remember, to do this add the string "sudo " to the beginning of the command. If you dont do this you get "Permission Denied".

To see the loop device you can do:

losetup -a
To delete a loop device (if you make a mistake), e.g. to delete loop5
losetup -d /dev/loop5 

Tests - not attempted
loop5 file ok UNTESTED
loop5 offset ok UNTESTED
Only one loop running UNTESTED

Mount the loop device in /mnt. "/mnt" is known as the "mountpoint". This is the directory in which the files belonging to the loop disk image will appear. To do this do:

mount /dev/loop5 /mnt
As /images is readonly, the /mnt device will also be a readonly filesystem.

Tests - not attempted
loop5 mounted in /mnt UNTESTED

The current mounts are all stored in a file called /proc/mounts. Look at this file and find the line with "/dev/loop5" on it. This takes the following format:

/dev/loop5 /mnt FILESYSTEM_TYPE OPTIONS 0 0
FILESYSTEM_TYPE is the format of the filesystem which has been mounted. You may remember that the partition type was FAT32. This is named slightly differently in Linux, and the filesystem is usually automatically detected by Linux. What does Linux call this filesystem type.
Filesystem type:

Tests - not attempted
/proc/mounts filesystem type? UNTESTED

How many jpeg files are in the mountpoint? These files all end in ".jpg".
No of files:

Tests - not attempted
mount still ok UNTESTED
No of files UNTESTED

Unmount the loop device. If you had changed directories into /mnt for some reason, you must cd away from /mnt before unmounting it (otherwise you get an error about the mount point still being in use). To unmount you need to use the "umount" administration command, and the parameter is either the mountpoint used or the loop device (it is up to you as they both work fine).

Tests - not attempted
mount gone ok UNTESTED

Release loop5 by deleting the loop5 device. This will allow you to reuse that device file in the future. Remember this is the administrative command "losetup -d" and then the name of the loop (including the /dev part of the name). If you have forgotten the name you can get the information by running the administrative command "losetup -a".

Tests - not attempted
No loops running UNTESTED

Question 5: Snapshots

In this section we will look at a concept called Snapshots. In the previous question we mounted via a loop device a disk image /images/usbimg1.dd. However, we could only mount this read only. Taking a disk image and then forensically examining it, while making sure it is not changed, is important as this ensures we are not introducing things into evidence accidentally.

However, sometimes a disk image needs to be changed as part of an investigation. This could be to correct an error which is stopping us conducting the investigation. An example of this could be that the partition table is damaged and thus we cannot access the partitions and files. There are tools available to correct damaged partition tables, but these require write access to the image.

One approach to solving this would be to take a second disk copy and make changes to that, but that could easily be hundreds of gigabytes or more. Instead, we will look at a way of accessing a read only image in a way that writes seem to work, but with the writes going to a seperate file. In this way the original image is still safe, and we can make changes to the way we see this disk in a safe and efficient manner.

For the purposes of learning about snapshots, we are going to mount the usbimg1.dd disk image in a way that the image itself is read only, but that we can add a small file to the mount data.

Firstly, create a small file to hold any changes made. The changes are held at the block level, so the file needs to be large enough to hold all the blocks which will be changed. For simplicity, make this file 2MB in size.

To do this, use the "dd" command to create 2mb of empty data. Write this into the /root directory, and to do this you will need to use sudo.

dd if=/dev/zero of=/root/changes bs=512 seek=4095 count=1
A trick here is to use "seek" to jump straight to the last block. This tricks Linux into creating a file which can hold 2mb, but which actually only has a size equal to the amount of changes made. It is called a sparse data file, and is very efficient if dealing with gb of data.

Use an admin level "ls" command, with the flags "-lhs" on /root. This reports:

???? -rw-r--r-- 1 root root 2.0M 2012-02-13 13:20 changes
The "????" indicates the size which this file is actually taking up on disk, while it says that it could take "2.0M" of data. What size is it ACTUALLY taking up? The test is case sensitive, so if the size is in capital letters make sure you do that in your answer here.
Actual usage:

Tests - not attempted
Actual Size UNTESTED

Create a loop device loop1, and link it to the first partition in /images/usbimg1.dd. Remember the offset!

Create a loop device loop2, and link it to /root/changes.

Tests - not attempted
loop1 is ok UNTESTED
loop2 is ok UNTESTED
Only 2 loops UNTESTED

The next step is to check now many blocks are going to be in the shapshot. Do:

blockdev --getsz /dev/loop1


Tests - not attempted
Snapshot size UNTESTED

Now create the snapshot using the following command:

dmsetup create sandbox --table "0 SIZE snapshot /dev/loop1 /dev/loop2 N 1"
The string "sandbox" names the new device as /dev/mapper/sandbox. You must replace the string SIZE with the blocksize of the snapshot you calculated with blockdev above.

Tests - not attempted
sandbox shapshot ok UNTESTED

mount /dev/mapper/sandbox in /mnt, then copy /etc/hosts into /mnt. You may need an admin level copy to make it work due to permission issues.

Tests - not attempted
/mnt has original files UNTESTED
/mnt has file hosts from /etc/hosts UNTESTED

First make sure the change has been written to the disk by doing a "sync". Just type:


What is the new allocated size of /root/changes after you copied in /etc/hosts? Again the units are CASE SENSITIVE (-lhs)
Actual usage:

Tests - not attempted

Clean up the system by:

  • Unmounting /mnt (or if you prefer /dev/mapper/sandbox)
  • removing the shapshot sandbox device by doing:
     dmsetup remove sandbox 
  • unloop loop1
  • unloop loop2
Tests - not attempted
No Snapshots exist UNTESTED
Mount gone UNTESTED
All loop devices unlooped 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 10.0: Essentials | Basic | Search | Acquisition | SysIntro | grep | MBR | GPT | FAT | NTFS | FRMeta | FRTools | Browser | Mock Exam |
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 |
Kali 2020-4: 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7 | 8a | 8b | 9 | 10 |
Useful: Quiz | Forums | Privacy Policy | Terms and Conditions

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