I think most of us agree that, in addition to shadow volume exams, one of the most useful features of building a VM from an image is to determine the configurations of various programs. Although details of configuration files are available for a number of frequently encountered applications, it’s often easier to simply run the program in a VM and determine the setup of the program. For example, I found this approach to be especially useful in peer-to-peer (P2P) exams, with respect to programs like LimeWire, FrostWire, etc. More specifically, while config files can tell us which individual files are shared, parsing through them is quite an undertaking. Anytime we start parsing complex files, the chances of error also increase. If we run the application in a VM, we can review the configuration in a virtually (no pun intended) fail-safe environment.
Obviously, to run an application in a VM, the application must exist. What about a case in which you know that the subject employed a particular application, but your exam of the acquired image reveals that the program no longer exists? A VM will only afford access to those objects that exist, although we always can explore shadow volumes. However, we can’t run most applications from a shadow volume folder or mounted shadow volume. It’s analogous to trying to run an application from a mapped volume; it may work with some, but not all, applications. I’m going to review a couple of approaches to “bring back the dead.” I’ll say up front that these methods are somewhat experimental and don’t always work. There also may be other approaches to this project, but mine assumes that you want to run the previously existing application in its native system.
Much depends on the complexity of the application that you want to restore and the method by which it was removed. I’ve found that most users employ the application uninstaller to remove an unwanted program. Some applications, particularly P2Ps, remove the application folder from the Program Files directory, but leave behind the configuration files, which usually are in the user’s AppData tree. The first approach is a simple copy and paste where we copy the application folder from the most recent shadow volume in which the program existed. We can start by using the quick shadow volume exam approach that I outlined previously.
When I undertake a program resurrection, I usually start with a base VM of the target, before I install VMware Tools or do anything that may disrupt the system. In my example, we know that the subject used a P2P program named LimeZilla. However, a look at the image file revealed that the application’s program folder was not present in Program Folders (x86).
Here are a couple of screenshots of the target VM to illustrate the point. The first shows the AppData\Roaming folder for the LimeZilla config files.
Next, here’s a look at the Program Files (x86) folder. The LimeZilla folder is missing.
Next, we’ll navigate to our available shadow volumes and look for the previously existing LimeZilla program folder. Here’s a video.
It’s always best to get as recent a copy of the application as possible. Applications, particularly P2Ps, are fussy about matching the executable with the proper version of the configuration files. Next, let’s see whether we are successful.
We now have access to the most recent version of the application. At this point, we can install VMware tools depending upon our goals.
We’re apt to find cases in which a simple copy and paste won’t work. In those instances, we resort again to the shadow volumes and try a system restore. Before I present a few warnings, I’ll demo the process.
The process may take quite a bit longer than the video made it appear. In case you didn’t notice, my desktop background reverted to what it was at the time of my selected restore point. In my example, I had installed VMware tools, although I usually don’t if I want to restore a system. By going back in time, I lost my VMware Tools as well as my installation of FTK Imager.
I did manage to recover my Skype installation. Frankly, this process isn’t successful very often, and the old BSOD presents regularly. For one, by going back in time, we probably returned to a time before we edited the drivers through the registry services. If that happens, you can try to fix the VM by returning the restored VM system’s registry to boot from the LSI SCSI drive. Even so, I’ve had some failures in this approach.
I do have a couple of other approaches in the testing phase of my research. When I make them a little more reliable, I’ll add a post.