If you can see this check that

Main Page


File Recovery

User:
Password:

Objectives

This lab deals with searching for deleted files within the image. It will introduce you to command line tools required to find and recover deleted files. To recover deleted file you will use icat command and if file cannot be recovered due to starting cluster of the file is overwritten or missing metadata you will use file carving to recover the data.

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

Question 1: Set Up Scenario

Press the button below to create the example to work on in this question. It will create the file /home/caine/dimg2.dd.

Tests - not attempted
Setup Scenario UNTESTED

Examine the dimg2.dd file and identify the start sector, byte offset to start sector, and filesystem type.

PartitionStart SectorStart ByteDescription
000:000
000:001
001:000
Tests - not attempted
dimg2.dd seems ok UNTESTED
000:000 start sector UNTESTED
000:000 start byte UNTESTED
000:000 type UNTESTED
000:001 start sector UNTESTED
000:001 start byte UNTESTED
000:001 type UNTESTED
001:000 start sector UNTESTED
001:000 start byte UNTESTED
001:000 type UNTESTED

Using the fls command examine the files present in partition 00:00.

Identify any files which are deleted, and list the inodes in the box below in the format "1,2,3,4". Put the inodes in ascending order and do not type any spaces into the answer.

Tests - not attempted
dimg2.dd seems ok UNTESTED
Inode list ok UNTESTED

Examine the first three of the deleted files you have identified in more detail by examining their inode information. With the inode information complete the following table, ordering the information by ascending inode number:

File OrderFull File NameFirst SectorLast Logical SectorSizeDirectory Entry status
File 1
File 2
File 3
Tests - not attempted
dimg2.dd seems ok UNTESTED
file1 filename UNTESTED
file2 filename UNTESTED
file3 filename UNTESTED
file1 first sector UNTESTED
file1 last sector UNTESTED
file1 size UNTESTED
file1 status UNTESTED
file2 first sector UNTESTED
file2 last sector UNTESTED
file2 size UNTESTED
file2 status UNTESTED
file3 first sector UNTESTED
file3 last sector UNTESTED
file3 size UNTESTED
file3 status UNTESTED

All three files share the same First Sector, and have many sectors in common.
Why?

Tests - not attempted
dimg2.dd seems ok UNTESTED
Shared sector? UNTESTED

Use icat and xxd to view the first and last sectors of each inode. Note the result and consider what this means in comparison to the file extensions of each file you listed above. Remember to format hex numbers using the format 0x0000. In this question a Signature is the first 2 bytes of a file, and the tail signature is the last 2 bytes.

File OrderSignatureHead Sig CommentTail SignatureTail Sig CommentFilename Extension
suggests
File 1
File 2
File 3
Tests - not attempted
dimg2.dd seems ok UNTESTED
file1 signature UNTESTED
file1 tail signature UNTESTED
file2 signature UNTESTED
file2 tail signature UNTESTED
file3 signature UNTESTED
file3 tail signature UNTESTED
file1 signature name UNTESTED
file2 signature name UNTESTED
file3 signature name UNTESTED
file1 tail signature name UNTESTED
file2 tail signature name UNTESTED
file3 tail signature name UNTESTED
file1 filename extension UNTESTED
file2 filename extension UNTESTED
file3 filename extension UNTESTED

In this case only File 2 has a valid start and end signature which matches its file extension, so it is likely the metadata of File 2 is valid and thus the metadata of File 1 and File 3 is invalid.

Use icat and recover File 2. Save the recovered file to /home/caine/file2.jpg.

Tests - not attempted
dimg2.dd seems ok UNTESTED
File 2 recovered UNTESTED

Question 2: File Recovery: carving

The file order File 1 identified in the previous questions had an extension which suggested it was a JPEG file, but that the clusters containing its data had been lost. In this question you will try to find the lost clusters using sigfind. Use sigfind command to find all files which contain the jpeg start signature. What is the first sector found by sigfind?

Tests - not attempted
dimg2.dd seems ok UNTESTED
First sector which could be jpeg UNTESTED

Is this sector from the beginning of the disk or is it from the beginning of the partition?

Tests - not attempted
dimg2.dd seems ok UNTESTED
Offset type UNTESTED

Using ifind to see if this sector is associated with an inode. Use the command below substituting SectorInQuestion for the sector you are checking. What is the result?

  ifind -o 63 dimg2.dd -d SectorInQuestion
Result:

Tests - not attempted
dimg2.dd seems ok UNTESTED
ifind output UNTESTED

Assuming that the sectors associated with this jpeg are contiguous (i.e. one after the other in continuous sectors) look for the end of jpeg signature and calculate the overall length. Use dd to load each sector, starting from the sector you identified above, and look for a jpeg tail signature followed by some 00 bytes. From this calculate the clusters used and file size.
File size in bytes:
Clusters Used:
Slack space in bytes:

Hint. You can assume that the file is less than or equal to 100 sectors in size. Thus you could dd all 100 sectors, then grep for the tail signature using a pipe.

Tests - not attempted
dimg2.dd seems ok UNTESTED
File size in bytes UNTESTED
Number of Clusters UNTESTED
Slack space UNTESTED

Use dd to copy this file, and save it to file1.jpg in /home/caine. Make sure the file is the right length, and remember to use disk offsets and not partition offsets.

Tests - not attempted
dimg2.dd seems ok UNTESTED
File valid UNTESTED

Question 3: Text File Recovery

The second file (File 3) which needs to be recovered has an extension identified above as ".txt". This is likely to be a text file. This is harder to automatically search for, but in this case you have been told that the missing text file is about the SHA1 standard. You can use this to help search for the file.

Use the following command to search for occurances of "sha1" on the disk.

/usr/local/bin/blkls -e -o 63 -i raw dimg2.dd |  grep -ba sha1 | cut -d: -f1 > /home/caine/bsearch
This will create a file called bsearch, which contains byte offsets at which the string "sha1" can be found relative to the start of partition 1.

Tests - not attempted
dimg2.dd seems ok UNTESTED
bsearch created UNTESTED

Examine the bsearch file you just created, and take the first offset in the file. What sector of partition 1 does that offset lie in?
Partition sector:

Tests - not attempted
dimg2.dd seems ok UNTESTED
bsearch sector UNTESTED

Convert the partition sector to a disk sector, then use dd and xxd to scan from that point of the disk onwards looking for the end of the text file. On the right of the xxd output you can see the ASCII text of the file. 0x00 rarely appears in a normal text file, so one approach is to look for the start of a stream of 0x00 characters, and the non 0x00 character immediately before this stream starts will be the end of the text file.

Hint: Assume the file is smaller than 100 sectors. You could use grep to look for 0000, but note that the string "0000" appears in this file, so prepare for false matches due to matching the ASCII translation.
File size in bytes:
Clusters Used:
Slack space in bytes:

Tests - not attempted
dimg2.dd seems ok UNTESTED
File size in bytes UNTESTED
Number of Clusters UNTESTED
Slack space UNTESTED

Use the dd command to copy this file and save it to /home/caine/file3.txt. Again make sure the file is the right length and that you are using disk offsets not partition offsets.

Tests - not attempted
dimg2.dd seems ok UNTESTED
File valid UNTESTED

Question 4: Remove the scenario

Press the button to delete the img file.

Tests - not attempted
Delete scenario 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-2023 Edinburgh Napier University