
Here's an excerpt:
4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 41,000 views in 2012. If each view were a film, this blog would power 9 Film Festivals
Click here to see the complete report.
By accepting you will be accessing a service provided by a third-party external to https://brettshavers.com/
4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 41,000 views in 2012. If each view were a film, this blog would power 9 Film Festivals
4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 41,000 views in 2012. If each view were a film, this blog would power 9 Film Festivals
After a colleague posed a question about building VMs from RAIDs, I thought it might be a good topic for a post. I won’t go into RAID basics, as you probably have a good grasp of that topic already if you’re visiting my site. The RAID systems that I see most often are RAID 0s, insofar as the system disk is concerned. We’re not concerned about a box that contains a system disk plus any variety of RAID.
In addition to being RAID 0s, the systems that are most common in my shop contain two disks. Frankly, I’d be a little hesitant about building a system on a RAID 0 with more disks because of the lack of fault tolerance. For our purpose, it really doesn’t matter. In fact, we can build our VM from a RAID 5 or even some versions of RAID 6, if we use the world’s leading forensics tool, X-Ways Forensics (XWF). For this demo, I’m going to use a two-disk RAID 0. The first step is to create an image of each disk. For the original images, the format is irrelevant. I say “original” because we’re going to create another image later.
As in most cases with XWF, there are a few (X) ways to approach a task. Let’s say that you don’t know whether you have a RAID, so you simply add your images to your case, as in the following video.
We now have two raw disks in our case. XWF also advised us that disk structure implies that a RAID may be present (the MFT message indicates the possibility of an implausible file record and likely is of no consequence). A little exploration will confirm that a RAID is present, so we can proceed to reconstruct the RAID.
When we add disk images to our case, XWF intuitively offers them as physical and/or logical disks in further tasks, as in the Select Disk box that we saw in the video. We see that our original disk images remain in our case, but it’s really not necessary to keep them. In fact, we didn’t have to add them when we created our case. For example, during the original imaging process, we could take a look at the original disks through our write blocker and determine that we have a RAID 0. After imaging, we can mount each image as a physical disk with FTK Imager or the tool of our choice.
Note that our image files are mounted as PhysicalDrive9 and PhysicalDrive10. We can now create a case in XWF and reconstruct a RAID right from the start, without adding images or media.
We begin by reconstructing a RAID, just as we did before. We’ll see that Disks 9 and 10 are offered as candidates for RAID reconstruction. After reconstructing the RAID, we’ll add it to our case through the context menu, as before. Note, however, that we must have our images mounted as disks to access our XWF case in the future. In the previous method, our image files usually are always in place.
You may recall that I mentioned stripe size in terms of sectors. Many of us are accustomed to referring to stripe sizes in terms of kilobytes, e.g., 128KB, which is a common stripe size for RAID 0s. XWF requires stripe size to be expressed as a number of sectors. It’s easy math to determine sectors by dividing the number of bytes by sector size, which usually is 512 bytes (but could be 4,096 bytes these days). Also, “bytes” mean the exact number: 128KB=131,072 bytes, so 131,072/512=256 sectors. Determining the correct stripe size may take a little research or trial and error.
We now can work our case in XWF as we would with a typical single-disk case. If we want to build a VM from our image files, we should create a new image from the physical, reconstructed RAID. From the XWF File menu, we select Create Disk Image, and XWF will present the following option box:
In the case tree, our RAID 0 is highlighted, and the viewer window is in Disk mode. My Create Disk Image options box is set to create a Raw (DD) image of the physical disk, which is our RAID 0. Once the image is created, we can create a VM from the image as we would with any image of a single disk system. Is that’s easy!
We’ve come to the point where we can conduct a rather complete exam of shadow volumes using dd and E01 image files. Let’s say that we don’t need to do such a complete exam. For example, we’re confident that one, particular folder may contain previous, unrecovered copies of a small number relevant files. Maybe we’re looking for one file in particular. In those instances, we may not need to mount the shadow volumes.
We can accomplish this task in either our SEAT workstation, in which we added a virtual disk of the target system, or in a running VM of the target. The latter approach is required for E01 images and optional for dd image files. You also can accomplish this with the VHD method that I presented earlier. The approach is the same regardless of which method you choose. Remember, however, that using a “live” VM of a system runs the risk that the system will delete old shadow volumes. The risk can be overcome, but keep it in mind.
To demonstrate the procedure, I’m going to use my SEAT workstation, in which I added a virtual disk.
It’s that easy! Note, too, that you can invoke Windows Previous Versions on almost any file or folder.
In my example, no previous versions existed. If they had, we would have seen a list of earlier versions by date. We then could open and examine any available version of the file. Should you find files of value in the approach that I presented, you can copy the files from the VM to your host system. Copying is seamless if you install VMware Tools in your VM. Otherwise, you can enable a shared folder with your host. Any such copy operation, however, is not a forensic recovery, so consider whether it suits your needs.
Now that we have a quick and easy approach to a limited review of shadow volumes, don’t become too accustomed to using it into the future. Windows 8 seems to have done away with the Previous Versions aspect of the Volume Shadow Service. In my tests of the latest Windows 8 Enterprise edition, it’s gone, and I believe that this has been confirmed on MSDN or similar forums. We can take heart, however, in the fact that shadow volumes remain; at least for the time being.
Eric Zimmerman and Brett Shavers have started writing the "X-Ways Forensics Practitioner's Guide", due out toward the end of year 2013.
Check back as to when the guide will be available. This guide intends to be the source of using X-Ways Forensics.
We’ve built our SEAT VM and added our target image to it as a virtual disk. The first thing that I do is verify that all of the shadow volumes are present. My first post presented a screen shot from the image file (MyImage) and depicted the shadow volumes. We can compare the shadow volumes from the image file with those in our VM. The following video presents the steps we use to enumerate the shadow volumes with the native vssadmin command run from our administrative command prompt.
The screen populates quite quickly, but the point is that we can identify the number of shadow volumes and their respective creation dates. To make it easy to copy, here’s the syntax: vssadmin list shadows /for=[your target volume letter followed by a colon]. Note, too, that your beginning shadow volume number will be different from mine and does not necessarily start with the number one. Another trick is to re-run the command and export the output to a text file, by adding a space at the end followed by >[path to your text file] [name of text file]. Creating a text file is handy for documenting your findings and for copying the shadow volume names, which we’ll do later.
Now we can mount any or all of our shadow volumes for examination. We’re going to use VSS, which is a free, command line tool written by Dan Mares, who is a creative, long-time forensic software developer and examiner. Dan also has developed free tools that are adjuncts to X-Ways Forensics and which help users customize certain reports. You can pick up a copy of VSS at http://www.dmares.com/pub/nt_32/vss.exe. Be sure to check for updates, as Dan is great about implementing suggestions. You’ll also want to check out his other tools. http://www.maresware.com/. Thanks, Dan!
There are a few of ways in which we can use VSS. We can mount one shadow volume; multiple shadow volumes that are numbered consecutively; or multiple, non-consecutive shadow volumes. The following screenshot displays the syntax.
We already have a list of shadow volumes produced by vssadmin. It’s now a matter of selecting the correct volume to provide to VSS. Let’s go back to an abbreviated view of vssadmin’s output.
The screenshot identifies one shadow volume. It may not be terribly clear, but the shadow volume path is \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5. We’ll feed that path to VSS and mount the shadow volume. We need only choose an unused volume letter, and we’ll pick H:
After executing the command, VSS will prompt us to hit <Return> one more time and then present what the screenshot depicts. It includes the root directory listing. Our shadow volume (#5) now is mounted as Volume H: You can repeat that process and mount any, or as many, shadow volumes as remaining drive letters permit.
Hint: to repeat the process, use your up-arrow and simply replace the volume letter and shadow volume number (#), i.e., ShadowCopy[#]. There is no need to copy/paste the entire path repeatedly.
Next, we’ll mount a range of shadow volumes. First, let’s look at the syntax, which is provided in VSS’ on-screen help.
We can start with a given shadow volume and mount every shadow volume that follows, up to our choice of the last shadow volume number. In our case, there are 19 shadow volumes and the first is #5. (I haven’t researched the question of why shadow volume numbers often start at a number greater than #1, but it doesn’t appear that it’s because there were X previous ones. Windows authority Troy Larson probably knows!) Before we go forth, I want to point out that you should study the dates of the shadow volumes in relation to your case. Several restore points can be created on the same day, perhaps within hours of one another. You’ll cut your exam and VM overhead if you exercise some judgment in picking the shadow volumes to mount and examine.
For demonstration purposes, let’s mount them all. I’ll start with no shadow volumes mounted and enter, vss h: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5 23 AUTO. Note that AUTO is upper case. The first shadow volume is #5, and the last is #23. Watch:
Actually, it was coincidental that I happened to have 19 shadow volumes and 19 open, consecutive drive letters To unmap any or all of our shadow volumes, we proceed as in the following screenshot. I’ll unmap them all.
Following the VSS command, you enter every volume letter, followed by a colon, which you want to unmap. If unmapping seems to hang, just refresh your screen in Explorer with F5.
That’s it for this post. Next time, I’ll demonstrate one or two exam approaches with X-Ways Forensics. In the meantime, if you get bored, you’re all set to examine your shadow volumes with any tools that you wish to install in your SEAT workstation.
[…] shared it. In fact, I initially used information from his 13 Jul 2012 blog post entitled Mounting Shadow Volumes to mount the VSC of interest as a RAM disk on my analysis system. At the time that I did […]
[…] where Jimmy’s blog post on mounting shadow volumes can into play. Using vss.exe, I added the VSC in question to my analysis system as X:, which […]
Windows forensics (A.Carvey) | Jacques DALBERA's IT world
[…] where Jimmy’s blog post on mounting shadow volumes can into play. Using vss.exe, I added the VSC in question to my analysis system as X:, which […]
Raffael
Jimmy,
How do you examine VSS on deleted/recovered partitions?
jimmyweg
I’ll have to guess, as I haven’t done that. First, I’ll say that you can’t examine deleted shadow volumes, AFAIK, and I tried. For example, you can recover a deleted SV and copy it into the Sys Vol Info directory. That doesn’t work, and may screw up the shadow volume service. Remember that the SVs are difference files, and the “index” has to track the SVs as a whole to rebuild things. Throwing in a “foreign” SV seems to mess up the system.
If you can recover a deleted, intact partition, I suspect that you can image it and create a VM or VMware virtual disk from the image. If you can do that, you can probaly add it to your SEAT workstation and see whether the VSS can rebuild the SVs. You also may be able to rebuild the entire physical disk (image) and boot the previously deleted partition.
Cal
Hi, nice blog!
What about an old snapshot of the same, working partition? I mean, every once an older shadow copy is deleted to create a newer one, due to space constraints to the VS service; however, sometimes a deleted snapshot can be recovered with a raw access to the disc, and .LOG# files in Sys Vol Info dir should hold some infos on syscache.hve changes.
I wonder if there is a mean to verify integrity of such a recovered shadow and to access it.
jimmyweg
The snapshots depend on linking. After deleting snapshots within a VM, VMware typically has no problem with running the VM from any given snapshots. Forensic tools, however, may be unable to mount the successive snapshots because of linking issues, I suspect. I’ve found it rather difficult to gather much any data from deleted (recovered) VSC, because the dependencies are lost.
I’m really enjoying and learning a lot these tutorials, Jimmy. Thanks for sharing!
KP
Raffael
Hi Jimmy
Thanks for your work!
I usually mount disks with Encase PE. This allows to access VSC directly in my workstation (no vm). This approach does not work if you use Ftk Imager or Mount Image Pro .
Looking forward to reading more of your posts!
Raffael
jimmyweg
Thanks very much, Raffael. Correct, mounting with FTKI or MIP will not provide access to the SVs. I don’t use EnCase, so I can’t speak to this feature, but it does seem handy. Another approach, which I’ll describe in a leter post, is mounting a VHD image. The drawback is that you have to create a VHD. If you do, however, you can access the SVs right from your host system.
Jimmy,
I’m not sure how I follow that creating a VHD is a “drawback”, per se. Analysts work on a copy of the acquired image, and not the original “evidence”, and the free tool available from MS simply appends a footer (less than 1K) to the image in order to turn it into a VHD. Once you’ve done that, you can still access the acquired image via FTK Imager, etc.
Thanks for posting this information…it’s great to see more of this sort of thing making it into the public view. Keep it up…
jimmyweg
Thanks, Harlan. Yes, converting the dd to VHD actually is quite simple with VhdTool. In my approach, I use the original image, which is not altered. If I want to convert the image to VHD, I guess that I would make a copy for that purpose, unless you can convert the VHD back to dd, but then you’d want to hash the original again. So, although I do have one or two backups of every dd (as E01) image, having to make another to convert to VHD is something I’d rather avoid. You can build your VMware device in less than one minute. Perhaps someone may develop a tool to image a medium directly to VHD with the approriate verification, something like E01. AFAIK, that’s not do-able at the moment.
This may not be good news for anyone wanting to make easy money with travel, but in the long run, your clients (and boss perhaps) will appreciate the savings and speed at which this can be done. You'll also be to get more done in a shorter period of time. That is a good thing.
In this step we’ll add our target system virtual disk to our SEAT VM. We already have the target (MyImage) virtual disk that we created, and we’ll add it to our system as in the next video.
Add Virtual Disk
As you saw, we chose to add the disk as an independent disk in non-persistent mode. Any changes to the disk are discarded when we power off our SEAT VM. Actually, as we’re going to examine shadow volumes, we’re not too concerned about routine changes that our operating system may make to volumes attached to our SEAT VM. Nothing within the shadow volumes will be changed. Remember, we’re not out to do a general exam; for that we can use our favorite tools on our image file.
When you add the disk, VMware may present a box that warns of a hardware compatibility issue. If my SEAT VM was created in an earlier version, I’ll get the following warning.
If you encounter this, change your SEAT hardware compatibility as in the video. Your hardware may differ from mine, but I bring my hardware up to my current version (Ver. 8). Choose Alter this virtual machine as your last step.
We’re ready to boot our SEAT workstation and get our target ready for a shadow volume exam. In Windows, we can see our target system as Volumes E:, F:, and G: Your volume letters may differ as may the number of partitions on your target.
A little exploring reveals that our target’s system partition is Volume F: While the last screen shot is right above us, I want to point out a very handy feature of VMware, which is the Pause button. You can see it in the screen shot as the two, vertical bars right below the File menu item. Pausing the VM freezes the action. So, if you have a number of tasks underway and don’t want to shut down your SEAT VM, just pause it until you want to return to work. Remember, too, that the VMware Snapshot feature is your friend.
The first thing that I do is write protect the target system disk. Even though the disk is non-persistent, it can be written to during our session. It’s also possible that the volume shadow service may delete one or more of the target’s shadow volumes. To write protect our target, we’ll employ Windows Diskpart, which is a command line tool that’s part of Windows 7. In the next video, I’ll step through the process. We’ll begin at the point where I entered the Diskpart shell.
Diskpart
To exit Diskpart, simply type the command exit. Note that the write protection survives a hot or cold reboot. Nevertheless, you don’t have to shut down your SEAT VM, unless you want to make certain changes to its configuration in VMware. Otherwise, you simply can use the Pause feature. Should you want to remove write protection, go through the steps in the video, but enter the command attributes disk clear readonly as the final command.
That’s it for now. In the next post, I’ll get down to mounting and accessing the shadow volumes. Thanks for visiting!
Gerald
Jimmy,
Hello, great series and info. Have you experimented with using the SIFT to make all .E01, .AFF or .RAW images available to the Windows Forensic box for Volume Shadow analysis? I have found it to be extremely quick to set up and reliable (takes about two minutes). Successive exams are faster to setup. Corey Harrell did a posting on how to do that here: http://journeyintoir.blogspot.com/2012/05/more-about-volume-shadow-copies.html
jimmyweg
>Have you experimented with using the SIFT
I haven’t. I do have SIFT, but I’m kind of linux-averse. It’s great stuff, but I like my GUI. I’m curious about the iSCSI approach, and perhaps it will work in my Windows-based VM. I’ll have to experiment. As I mentioned, I can make this work with E01s, but it’s a little more work. I started down this road because I received quite a few remarks about problems with EnCase PDE and LiveView. I don’t use EnCase, so I can’t attest to any issues, but I did play with LiveView and prefer my “hand-built” approach. My aim, which will become a little clearer as I progress, is to do a SV exam with X-Ways Forensics. You can use any tool as long as it will run in a VM. For that matter, you can do the same thing directly in the running VM of the target that we bulit in my first post. XWF can be run from a thumb! You also can add the target virtual disk directly to SIFT through VMware. You’ll have to let me know what you think as I proceed. Thanks.
Gerald
>I’m curious about the iSCSI approach, and perhaps it will work in my Windows-based VM. I’ll have to experiment.
Absolutely it will work to access VSCs. Just make sure your Win forensic box is on the same subnet as the SIFT workstation. Send me an email at This email address is being protected from spambots. You need JavaScript enabled to view it. and I will send you back a short PPT on the method. Should save you a bit of experimenting time.
We now have built a virtual machine from an image of the target system. Next, we’ll build a Windows 7 VM and configure it as our examination platform: Shadow Examination and Analysis Technique (SEAT) workstation. Building the VM basically is the same as installing a operating system from scratch, and I’ll go over the basic steps in the following video.
Build Base VM
I installed Windows 7 Ultimate 64 from a DVD, but you can use an ISO instead of a disc. I have a library of operating systems on ISOs, as they come in handy. Please be mindful of licensing requirements. I didn’t install a network adapter, but will do so later. I use as much RAM as I can afford, and you can experiment. RAM can be adjusted from a powered off state. I like using a single, growable disk for my VM. For the most part, I set up the system as I like. I turn off User Account Control, but we must leave System Protection enabled. I also set my folder view options to allow access to hidden and system files. Remember that you can use snapshots to protect the state of your VM. Below is a screenshot of my VM. I keep my frequently used tools on the desktop. Be sure to include a shortcut to the command prompt, and be set it to run in administrator mode.
For you X-Ways users, you can configure your options as you do normally. Be sure, however, to set the option to run XWF as administrator by default, and allowing multiple instances is suggested. Remember that XWF, as most forensic suites, is USB dongle based. When you want to work with XWF in your VM, you must connect the dongle to the VM as in the image below.
If you have more than one Feitian dongle as in the screenshot, you’ll have to experiment to find the correct dongle. Then, connect it to the VM (Disconnect from host). Note that, if XWF is running in the host system, it will become aware that the dongle was disconnected and issue a notice. The easiest thing to do is close the host instances of XWF before you work in the SEAT application. Of course, if you have more than one dongle, you can work simultaneously in both environments. Note that you can install any USB devices that you wish by using the same procedure.
Note, too, that our SEAT workstation is portable. At the moment, my VM is about 18GB, so it’s easily copied to another forensic workstation or USB drive. In the next post, I’ll review how we mount the target VM in out SEAT workstation and begin an exam.
Derek Frawley
Thanks for the vm creation tutorial.
Do you have anything that will show how to do with E01 file(s) or multiple raw files.( as mentioned in the tutorial) Most of the images i have are E01 and takes too long to re-image.
jimmyweg
I’ll add a post on E01s this weekend, if I have time. In any event, I’ll do that next. Thanks for the comment and suggestion!
Jimmy
http://JustAskWeg.com/
Scott Koehle
Great Stuff, Jimmy. Thanks for taking the time to put this website together. Very Helpful.
Scott Koehle, CFCE
Altoona Police Department
1106 16th St
Altoona, PA 16601
814-932-2588
jimmyweg
I’m glad that it’s helpful. If you enciunter any issues, please let me know.
Be sure to check out my DFIR Training website for practically the best resources for all things Digital Forensics/Incident Response related.
© 2023 Brett Shavers