Using Symbolic Links to Map Folder Paths for DFIR / eDiscovery Tools

agungor · August 24, 2022, 7:25pm

This question came up recently in the context of ingesting FEC projects that have been moved from their original folder structure into FEI. It also applies to virtually any DFIR / eDiscovery scenario where the path to the data may need to be shown to a tool at a different location than where it actually is.

For instance, I recall answering a question in another DFIR forum where the examiner had a forensic image split between two drives, and they were looking to load the image into EnCase or FTK without having to combine the image segments onto a single drive.

While we aim to make this process much easier for FEC soon by turning FEC’s project paths into relative paths, I wanted to put a quick tutorial together at the request of one of our users.

Let’s go with an FEC project example and say I have an existing FEC acquisition whose output path was set to G:\ClientData\12345.123\ (one can find this information in FEC’s Acquisition Log). The acquisition is successfully completed, timestamped, and archived. But, months later, I need to do some further work on the acquisition such as packaging Drive attachments / revisions which I had not done the first time around.

However, I now have a different setup and no longer have a G: drive or the same folder path within the G: drive. Instead, I restore the acquisition to the path R:\NewPath. How can I tell Windows to make R:\NewPath\ accessible through G:\ClientData\12345.123\?

There are multiple ways to accomplish this. I will provide a couple of options:

OPTION 1—Works without a G: drive at all; assumes that it is okay to write to R:

Create the same folder structure under the R: drive as we wish to access on the G: drive, until the last folder. In this example, create a new folder R:\ClientData
Create a symbolic link that points R:\ClientData\12345.123 to R:\NewPath as follows:

mklink /D "R:\ClientData\12345.123" "R:\NewPath"

The above creates a symbolic soft link that points to a directory. We now need to take care of the R: ➫ G: mapping.

Associate the path on the R: drive with the drive letter G: by using the subst command:

subst G: R:\

You can now access the data through G:\ClientData\12345.123\
When done, you can remove the G: drive using:

subst /d G:

and the symbolic link on the R: drive can simply be deleted as one would delete a regular file.

OPTION 2—Requires a dummy G: drive; no need to write to R:

If we cannot write to R:, then we can follow an alternative route.

Create a dummy G: drive that is writable. Not much disk space is needed. So, a RAM disk or a mounted small and empty VHD should work. One could also use a physical USB flash drive or portable hard drive and tell Windows to mount it to the G: drive.
On the G: drive, create the folder structure we wish to access until the last folder. In other words, create the G:\ClientData\ folder in our example.
Create a symbolic link that points G:\ClientData\12345.123 to R:\NewPath as follows:

mklink /D "G:\ClientData\12345.123" "R:\NewPath"

Note: In some cases, especially if the volumes are being accessed remotely over a network, it may be appropriate to create a directory junction instead of a directory symbolic link. This can be achieved as follows (see mklink documentation for syntax and details):

mklink /J "G:\ClientData\12345.123" "R:\NewPath"

You can now access the data through G:\ClientData\12345.123\

OPTION 3

In some scenarios, as an alternative to subst in Option 1, you can also consider mapping a drive letter from a share or the administrative share (i.e., \\127.0.0.1\R$) as follows. This may require a password depending on your configuration:

net use G: \\127.0.0.1\R$

Important Note:

You may have varying levels of success in using the above options with DFIR / eDiscovery tools. I strongly recommend using a backup copy of the data, and doing thorough testing to make sure the software is working as expected.

Link Shell Extension

If you would like to use a GUI tool to create symbolic links, volume mountpoints, junctions, and more, take a look at Link Shell Extension by Hermann Schinagl.