Wednesday, March 12, 2014

Research Update



Welcome back to Virtual RAM Disk Forensics! It’s been a while since my last post, and since then I’ve obtained tons of information about RAM disks and how they can be analyzed forensically. I’ve managed to locate mounted disks within RAM, view and interpret their disk structure, find file locations, and also provide some examples of how RAM disks might be used in an anti-forensic manner. Keep reading for an in-depth description of my research.

RAM Disk Structure
Using DumpIt, a memory dumping tool, I was able to obtain an image of RAM while a disk was mounted. Initially, I began to analyze the RAM image with volatility, a memory analysis tool, but I actually found that due to the fact that there was an actual disk mounted in RAM, it was more beneficial for me to analyze the image manually.

In order to view the RAM image, I used a Hex editing tool called HxD. After loading the image into HxD and doing some searching, I was able to locate the actual boot block of the disk I mounted (at offset 0x19DAD000), as seen below.


I knew that this was the boot block for the disk I mounted because the size of the disk can be determined through the hexadecimal values in the boot block. At offset 0x20, a 4 byte entry denoting the size of the volume can be found, which in this case is 0x00063FF0. This is the size of the disk in blocks. Offset 0x0B has a two byte entry outlining the bytes per block, which in this case is 0x0200, or 512. Multiplying the number of blocks by the bytes per block, gives you 209MB. For this example, I mounted a 200 MB disk, which must have about 9MB of overhead.

The next step for analyzing the RAM image was to find the root directory. In FAT, every file and directory on the drive has a root directory entry, which tells the file system information about that file such as its MAC times, offset on the disk, and more. Consequently, being able to locate the root directory would be quite valuable to forensic investigators.

In a normal FAT disk, the root directory would be located directly after the File Allocation Table(s) (FATs), which come directly after the boot block. Information on the number of FATs and the size of the FATs can also be found in the boot block of the disk. After finding this information and doing some math, I determined that the root directory should be located at offset 0x19DB9A00. Unfortunately, when I navigated to this offset within the RAM image, there were no root directory entries to be found, as seen below.


In order to find the root directory, I needed to know the exact hexadecimal characters that would make up an entry for a specific file. As such, I decided to format a thumb drive as FAT, create some test files on it, and analyze the root directory entries of those files. Next, using a tool called TimeStomp, I was able to create another RAM Disk, drop files on it, and manipulate their metadata to be identical to the test files I created. Using this strategy, I was able to locate the root directory entries in the RAM image.

The boot block of this disk was located at offset 0x18FDD000, and the root directory entries I found were located at offset 0x17927FF0, as seen below. Note that this offset is before the offset of the boot block, proving that the disk is certainly not contiguous within RAM.


One of the located root directory entries is highlighted, which in this case is for a file I created called TextFile1.txt.

Analyzing the metadata located within this root directory entry revealed that the file was created on 2/7/2014, which matches the creation date of the file when viewed from Windows Explorer, as seen below. If you would like to read more information about the metadata located within root directory entries, as well as how to convert them into human-readable formats, a great tutorial can be found here.

I am still researching and trying to find the link between the boot block and the root directory, but so far have been unable to determine how the disk is structured within RAM.

Forensics
As an anti-forensic technique, it is possible that someone wishing to conduct illegal activity may store or use files on a RAM disk, and then when finished, dismount the disk in hopes that the files would be gone. Consequently, I conducted another experiment in which I mounted a disk, dropped files on it, and then dismounted the disk.

Searching through the RAM image after the disk was dismounted showed no sign of a FAT boot block, or root directory entries. However, many instances of the files and folder structure on the disk that I created still showed up, as seen below.


The next step in my research is to run an executable from the RAM disk, and attempt to determine whether or not there is any proof that the executable was run after the disk is dismounted, or even after the computer is restarted. I have written a simple batch script to mount a disk, drop an executable on it, and run the executable, using the CLI RAM Disk tool called PrimoRamdisk, but have been unable to get the executable to run properly thus far.

In the next weeks, I am hoping to wrap up my research by possibly finding the link between the root directory and the boot block, and determining whether or not it can be proved that an executable was run from a virtual disk. Come back in a few weeks for a summation of my entire project!

No comments:

Post a Comment