The Kids Greenland Garden (KGG) is a place where parents take their kids to play in its wonderful green gardens. There were a lot of complaints about Mr.X, the KGG gardener. An official dispute was filed by one of the parents (Sally) when she was positive that something weird was going on by Mr.X and it was time to put an end to it. The police were informed, and a team of first responders was sent to the garden. The day before Sally filed an official dispute, she confronted Mr.X about his weird activity, and that he is doing something wrong. Because of that, what Mr.X did, was ruin his disk drives so he can cover whatever data he is hiding on his disks.
In this case, you are required to understand the disk partition schema and recover if any of the disks on Mr.X's machine were corrupted.
Hex Workshop, FTK Imager or Disk Editor
We are going to use Hex Workshop to solve this case, but feel free to use any hexadecimal editor that you like.
[Analysis:]
First, open the forensic image "[Lab7.001]" file [located at C:\DFP\Labs\Module04\Lab7\Lab7.001] using Hex Workshop. You will see something similar to the below:
Using FTK Imager, observe that it is only able to show you the raw physical disk space. It is unable to interpret the Master Boot Record (MBR), and display the partitions.
Take a moment, review the hexadecimal data in the boot record and MBR. Can you see the problem?
If you look at the end of the first sector, which is the sector of the MBR, we are supposed to find an end of sector marker or sector signature which should hold the bytes 55 AA in hexadecimal.
What you see is that instead it is hexadecimal DF DF as we see in the figure above.
[DIY:] By the way, I recommend you check it with another tool as well, just to make sure that it truly cannot identify the disk. In forensics, we always verify.
[Solution:]
So, what we need to do now, is change those two bytes back to 55 AA and save the disk (for example Lab7-SOL.001).
We cannot edit images in FTK Imager, but you can in Hex Workshop. Open the image in Hex Workshop
First things first, Hex Workshop's display is defaulted to sizing the hexadecimal view to the window size. Resize the Hexadecimal view to show 16 byte rows, by showing columns 0-F (remember we are in hexadecimal!). You can do this by dragging the line between the hex and ASCII data left or right. See image below.
Verify that you see hex DF DF at the end of the sector.
You now should be looking at row offeset 1FO and column E. Click the first bit "D" at offset 0x1E, and then type 55AA (no spaces). If you do this you should see 55 AA in red, ending the row.
Using "Save As" save this image file as a new image file. Remeber we never want to alter the original evidence, and you want to document the steps you took to do this and why,
Now If what you did was done properly, you should be able to open the newly created disk image in FTK Imager and it should interpret the partitions correctly.
So that's it, we managed to recover the disk that Mr.X corrupted by modifying those two bytes on his disk. This proves that digital forensics tools won't be able to identify the disk without those two bytes found at the end of the sector. By the way, I recommend you check it using FTK Imager for example too, just to make sure that it truly cannot identify the disk.
This type of corruption is not very common, but if you do encouter problems always check for the 55 AA, then begin checking for errors in the partition table it self. You can always compare them to the Volume Boot Record and see if they match up.
Now since we managed to recover the corrupted disk, I believe answering the questions below won't be a big problem. Let us move on and answer each one of them.
Which partition if any, is marked as bootable? Now to answer this question, we need to check the Boot Code in the MBR entries of the disk. Let's use FTK Imager to review them. You need to check for the active partition to see if any are marked as bootable. Refering to highlighted partitions in this images MBR.
The boot code is indicated in the first byte in byte of each partition. An active partition will have the status set to 0x80. A non-bootable partition will be set to 0x00
If we review each partition, refering to the above figure, you will find that all of them are non-bootable partitions.
So, the answer is there are no bootable partitions on this disk.
Let us move on to the final question.
You can answer these questions using different techniques, let's use FTK Imager.
From the first question, we found that there are four partitions, so let us interpret each one of them. Click on the first partition. Then in the details pane, click on properties. The first partition and its details are below:
Our answers would be: a. Starting Sector (or First LBA) = 128 b. No. of sectors in partition = 1024000 c. Partition Size = (No. of sectors) X (size of sector)
= 1024000 X 512
= 524288000 Bytes
= 500 Megabytes
Is this equal to you expected result? Compare you calculated size to your expected size in the Evidence Tree. Now this is forensics!
d. Partition Type = 07 which means we have an NTFS partition.
Click here for more information on partitions
Using the previous directions as a guide, can you determine the remaining partitions?
Our answers would be: a. Starting Sector (or First LBA) = 1024128 b. No. of sectors in partition = 512000 c. Partition Size = (No. of sectors) X (size of sector)
= 512000 X 512
= 262144000 Bytes
= 250 Megabytes
d. Partition Type = 0B which means we have a FAT32 partition.
On to the third partition, we find the details below:
Our answers would be: a. Starting Sector (or First LBA) = 1536128 b. No. of sectors in partition = 512000 c. Partition Size = (No. of sectors) X (size of sector)
= 512000 X 512
= 262144000 Bytes
= 250 Megabytes
d. Partition Type = 0C which also refers to a partition with FAT32.
And finally, the fourth partition we find the details below:
Our answers would be: a. Starting Sector (or First LBA) = 2048128 b. No. of sectors in partition = 2142208 c. Partition Size = (No. of sectors) X (size of sector)
= 2142208 X 512
= 1096810496 Bytes
= 1046 Megabytes
d. Partition Type = 05 which means we have an Extended partition type holding a NTFS file system.
To better summarize our results and add them to a report in the future, I'm going to create a table and add the final results to the table below:
Partition | Starting Sector (First LBA) | Number of Sectors | Partition Size in Bytes | Partition Type |
---|---|---|---|---|
First | 128 | 102400 | 524288000 | NTFS |
Second | 1024128 | 512000 | 262144000 | FAT32 |
Third | 1536128 | 512000 | 262144000 | FAT32 |
Fourth | 2048128 | 2142208 | 1096810496 | NTFS |
[DIY]: I highly recommend you verify these results we obtained using another tool.
(Here is a great reference to bookmark from our friends at Invoke-ir.com)[http://www.invoke-ir.com/2015/05/ontheforensictrail-part2.html]
Partition Type Information:
http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html