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!
