Hi,
I have a problem with mounting shadow copies when parameters -c and -s are specified.
Steps I have taken so far. I installed new Win10 instance in virtulabox on Ubuntu 16.04, created 4 shadow copies, deleted the oldest one and exported VDI to RAW image.

fdisk -l win10.img

Device Boot Start End Sectors Size Id Type
win10.img1 * 2048 104447 102400 50M 7 HPFS/NTFS/exFAT
win10.img2 104448 63691339 63586892 30,3G 7 HPFS/NTFS/exFAT
win10.img3 63692800 64737279 1044480 510M 27 Hidden NTFS WinRE
offset=104448*512=53477376

vshadowinfo /media/sun/D:/Image/win10.img -o 53477376
vshadowinfo 20191221

Volume Shadow Snapshot information:
Number of stores: 3

Store: 1
Identifier : 24a28125-397c-11ec-9e53-080027d234e6
Shadow copy set ID : efc3a883-2aed-47b2-88b2-ae7ca3016716
Creation time : Oct 30, 2021 12:24:26.085246900 UTC
Shadow copy ID : 51638f75-2950-4b77-b127-edac6f93305d
Volume size : 30 GiB (32556488704 bytes)
Attribute flags : 0x0042000d

Store: 2
Identifier : a3e89152-3a1e-11ec-9e54-080027d234e6
Shadow copy set ID : 570ac455-baf0-4204-9471-ccda32999640
Creation time : Oct 31, 2021 07:48:24.269345700 UTC
Shadow copy ID : ff5c9ef0-1dc9-4bc3-868d-4a4da47ddeb2
Volume size : 30 GiB (32556488704 bytes)
Attribute flags : 0x0042000d

Store: 3
Identifier : a3e89199-3a1e-11ec-9e54-080027d234e6
Shadow copy set ID : aba6e8fd-6bab-483e-809d-dd858315ebe8
Creation time : Oct 31, 2021 07:50:11.752992200 UTC
Shadow copy ID : 926e8df1-c4f4-4bf6-bfe3-de52a200f620
Volume size : 30 GiB (32556488704 bytes)
Attribute flags : 0x0042000d

vshadowmount /media/sun/D:/Image/win10.img /mnt/shadow/ -o 53477376
vshadowmount 20191221

sun@sun:/mnt$ ls -la /mnt/shadow/
total 4
dr-xr-xr-x 2 sun sun 0 říj 31 15:37 .
drwxr-xr-x 13 root root 4096 říj 30 09:21 ..
-r--r--r-- 1 sun sun 32556488704 říj 31 15:37 vss1
-r--r--r-- 1 sun sun 32556488704 říj 31 15:37 vss2
-r--r--r-- 1 sun sun 32556488704 říj 31 15:37 vss3
I am able to see different versions of myfile of interest in all of them.

python3 vss_carver.py -o 53477376 -i /media/sun/D:/Image/win10.img -c catalog -s storage -t RAW
vss_carver 20200312

Stage 1: Checking if VSS is enabled.
Volume size: 0x794849800
Found VSS volume header.
0x1e00: b'6b87083876c1484eb7ae04046e6cc752'
Catalog offset: 0xecf4000

Stage 2: Reading catalog from disk image.

Stage 3: Carving data blocks.
Started at 2021/10/31 15:50:47
Progress: 32556498944 / 32556488704 bytes (100.00%) at 2021/10/31 15:52:06
Finished at 2021/10/31 15:52:06

Stage 4: Grouping store blocks by VSS snapshot.

Stage 5: Checking next block offset lists.

Stage 6: Deduplicating carved catalog entries.

Stage 7: Writing store file.

Stage 8: Writing catalog file.

python3 vss_catalog_manipulator.py list catalog
vss_carver 20200312
[0] Enable, Date: 2021-10-30 12:24:26.085247, GUID: 24a28125-397c-11ec-9e53-080027d234e6
[1] Enable, Date: 2021-10-31 07:48:24.269346, GUID: a3e89152-3a1e-11ec-9e54-080027d234e6
[2] Enable, Date: 2021-10-31 07:50:11.752992, GUID: a3e89199-3a1e-11ec-9e54-080027d234e6
[3] Enable, Date: 2021-10-31 06:50:11.752992, GUID: 4270cb1d-5a3a-ec11-9204-6045cb61c09c
I can see the undeleted ones and the deleted one.

vshadowmount /media/sun/D:/Image/win10.img -c catalog -s storage -o 53477376 /mnt/shadow/
vshadowmount 20191221

ls -la /mnt/shadow/
total 4
dr-xr-xr-x 2 sun sun 0 říj 31 16:07 .
drwxr-xr-x 13 root root 4096 říj 30 09:21 ..
-r--r--r-- 1 sun sun 0 říj 31 16:07 vss1
-r--r--r-- 1 sun sun 0 říj 31 16:07 vss2
-r--r--r-- 1 sun sun 0 říj 31 16:07 vss3
-r--r--r-- 1 sun sun 0 říj 31 16:07 vss4
There is 0 size on all of the copies. Why? Where could be a problem?
I tried compilation of libvshadow-vss_carver-vss_carver.zip again then tried to test in Windows 10 with
precompiled_libyal_libs-master.zip
vshadowmount.exe -o 53477376 e:\Image\win10.img -c catalog -s storage i:
vshadowmount 20191221

Unable to run dokan main: unable to assign drive letter

It works without catalog and storage parameters and I can see vss1-vss3
vshadowmount.exe -o 53477376 e:\Image\win10.img i:
vshadowmount 20191221

mount_dokan_ZwCreateFile: unable to retrieve file entry for path: \autorun.inf.
mount_dokan_ZwCreateFile: unable to retrieve file entry for path: \autorun.inf.
mount_dokan_ZwCreateFile: unable to retrieve file entry for path: \autorun.inf.
mount_dokan_ZwCreateFile: unable to retrieve file entry for path: \AutoRun.inf.
Thanks

Sorry for posting this as an issue since i cannot find personal email of the developer.
I am new in the whole system volume and shadow copies situation.
Where can I find the value to fill the -o, -i, -c, and -s parameter in my computer?

Thank you very much in advance.

I discovered something odd. I have a vmdk from a test system, it was created as "Windows Server 2012.vmdk". I moved the disk to a different path and renamed it to remove spaces and make it easier to type, "server2012.vmdk". When I run vss_carver.py, something is still looking for the original file name. I don't know how it got this, I assume it's pulling it from the metadata somewhere. If I rename it back, it runs fine (with fine being it's still not finding VSS volume header, but it's not crashing).

Behavior after changing the original file name (scroll all the way right):

$ python3 vss_carver.py -t vmdk -o 718848 -i /mnt/c/vss_test/server2012.vmdk -c /mnt/c/vss_test/
catalog2012 -s /mnt/c/vss_test/store2012
vss_carver 20200312
Traceback (most recent call last):
  File "/home/nullsec/vss_carver/vss_carver.py", line 953, in <module>
    sys.exit(main())
  File "/home/nullsec/vss_carver/vss_carver.py", line 896, in main
    disk_image.open_extent_data_files()
OSError: pyvmdk_handle_open_extent_data_files: unable to open extent data files. libcfile_file_open_with_error_code: no such file: /mnt/c/vss_test/Windows Server 2012.vmdk. libcfile_file_open: unable to open file. libbfio_file_io_handle_open: unable to open file: /mnt/c/vss_test/Windows Server 2012.vmdk. libbfio_handle_open: unable to open handle. libvmdk_handle_open_extent_data_file: unable to open file IO handle. libvmdk_handle_open_extent_data_files: unable to open extent data file: /mnt/c/vss_test/Windows Server 2012.vmdk.

behavior after restoring the original file name:

$ python3 vss_carver.py -t vmdk -o 718848 -i "/mnt/c/vss_test/Windows Server 2012.vmdk" -c /mnt/
c/vss_test/catalog2012 -s /mnt/c/vss_test/store2012
vss_carver 20200312
==================================================
Stage 1: Checking if VSS is enabled.
Volume size: 0x200
Not found VSS volume header.

Well no luck there... the carving found the "available" VSS points. Nothing older/prior/deleted.

Originally posted by @gem611 in #5 (comment)
Hi, please tell me how you solved the problem with the 5th stage of the vss carver.

Hi. Nice work

I have 2tb image. After succefully Carver. The catalog have about 40kbs but store file was 0 kb. Is norma? . And so i got and error with shadow mount.
Says: invalid range offset value exeeds file size.

Any thoughts?
Thanks.

Hi, this carver sounds amazing, btw. I'm having a snag in use, however.
Getting the error, "ValueError: cannot fit 'int' into an offset-sized integer". I've simply added in a couple of print statements to see what integer it was getting (Otherwise, I've made no changes, so the line numbers are plus 2 in the screenshot).
You can see that in the screenshot, right before the Traceback line.
Am I doing something wrong? I've double checked my partition offset, looks to be correct (Starting Sector 1159168 * 512)

Thanks for your time!

I'm trying to do some research and documentation on this tool, but I'm continuously coming up with "Not found VSS volume header."

My methodology boils down to

1. Take a clean VM (Server 2019, although I've tried 2012 as well), VMWare Workstation Pro 16
2. Create a file
3. Enable VSS, first shadow automatically gets created
4. Verify vss is there with vssadmin list shadows
5. Delete the file w/sdelete (don't want it showing up in slack space)
6. Delete the VSS using the commands below this list.
7. Verify the vss is deleted with vssadmin list shadows
8. Shut down the VM

After this it gets into the regular forensics portion. I use qemu to convert the vmdk to a raw disk, mostly so I can get the offset easier. I've tried directly to the vmdk as well though. fdisk -l <filename.raw> to get the start and end, multiply the start of my windows drive slot by the sector bytes (512) to get the offset. offset, file name, and locations for the catalog and store go into vss_carver.py, which seems to run fine. After multiple tests though, it never finds the VSS volume header.

I'm not sure there is a fix here, I'm mostly looking into any insight as to why this is failing. Not giving the VSS enough time to create? Thin provisioned virtual disks? virtual disks residing on a solid state drive? Can you give me more information about what it means to not find the VSS volume header, and why that might be? Is Server 2019 shadows known to be supported? I can think of a ton of stuff that could go wrong, not all of it I can account for in my lab.

Deleting the vss

vssadmin delete shadows /all /quiet
wmic shadowcopy delete
wbadmin delete catalog -quiet

vss_carver 20200312
==================================================
Stage 1: Checking if VSS is enabled.
Volume size: 0xeea000000
Not found VSS volume header.

Edit: I did a much more in-depth explanation of my setup here: https://nullsec.us/carving-for/

Hi can somebody or autor of Vss_carver can help me or give instruction how restore deleted vss snapshots or restore data from it after ransomware attack which deleted vss snapshots. I have an encrypted vhdx drive and I need to recover data from vss snapshots. Please help. Send me priv @mnrkbys

I have been trying to run vss_carver for a while now. It seems to run ok until it gets to "stage 5: checking next block offset lists". I have even let it sit there for over a week a couple of times, but it has never moved past this point. What do I need to do to get it to complete?

In order for vshadowmount to work on my system, I had to install Dokany 0.7.4. The latest build, 1.2.2.1000 gave me a "Unable to run dokan main: unable to load driver" issue. Once I installed 0.7.4 (didn't even remove 1.2.2.1000) vshadowmount executed and mapped my designated drive ok.

I've got my system going, just wanted to post this for anyone else that may have the same "load driver" issue.

When I run vss_carver with -t E01 it won't run and I get the following error.
Any idea how I can fix this and make it work? I tested with RAW instead and it runs, but my file format is E01.

F:\Rec>vss_carver.py -t E01 -o 16777216 -i y:\EWF1 -c f:\data-catalog -s f:\data-store
vss_carver 20200312
Traceback (most recent call last):
File "F:\Rec\vss_carver.py", line 953, in <module>
sys.exit(main())
File "F:\Rec\vss_carver.py", line 890, in main
disk_filenames = pyewf.glob(args.image)'
OSError: pyewf_glob: unable to glob filenames. libewf_glob_wide: invalid filename - missing extension.

Hi, I have a RAW image from a Windows Server which was encrypted in 2019 and all VSS snapshots were deleted by ransomware called phobos. What I did so far:

1. vss_carver.py -t RAW -o 68719476736 -i d:\server_image.img -c d:\server_catalog -s d:\server_store (vss_carver)
2. vss_catalog_manipulator.py list d:\server_catalog

Now I see 105 (0-104) entries (vss_catalog_list) but each line has a date from last week, why that?

3. vshadowmount.exe -o 68719476736 -c d:\server_catalog -s d:\server_store d:\server_image.img x:

Now I receive error messages like "unsupported number of stores"! So I reduce the number of restore points to just one:

4. vss_catalog_manipulator.py remove d:\server_catalog 0-103
5. vshadowmount.exe -o 68719476736 -c d:\server_catalog_remove -s d:\server_store d:\server_image.img x:

Now I can see an entry (x:\VSS1) and I can mount it with FTK Imager (https://accessdata.com/product-download/ftk-imager-version-4-5)

But no matter which restore point i choose, I always see the same version after the encryption! My impression is, that only the image after the infection is loaded and the VSS catalog is ignored! What am I doing wrong? Thanks!

I am getting segmentation fault when mounting the image with store and catalog on kali linux.

Hi,

would it be possible to somehow add the option to mount the vss as rw to use ntfsfix for repairs?

a lot of my test vss are not mountable cause of some errors like "Error reading bootsector: Input/output error"

if i dd the vss into a new image - mount this one rw and use ntfsfix to repair the sectores, it is mountable.

So i was wondering if there are options to do this directly without dd'ing the vss again (which results in massive time and space consuming if big images are used..)

Thank you very much

EDIT: im using your patched vshadowmount

Hello,

I have a problem recovering the VSS.
The disc was captured with the FTK imager.
The OS of the captured disk is windows 2012 R2

I work with windows 10.

This is all i did:

mmls.exe F:\HDD-DD.001

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000718847   0000716800   NTFS / exFAT (0x07)
003:  000:001   0000718848   1953521663   1952802816   NTFS / exFAT (0x07)
004:  -------   1953521664   1953525167   0000003504   Unallocated

vshadowinfo.exe -o 368050176 F:\HDD-E01.E01

No Volume Shadow Snapshots found.

python vss_carver.py -t RAW -o 368050176 -i F:\HDD-DD.001 -c F:\catalog -s F:\store

==================================================
Stage 1: Checking if VSS is enabled.
Volume size: 0xe8cad00000
Found VSS volume header.
0x1e00: b'6b87083876c1484eb7ae04046e6cc752'
Catalog offset: 0x0
==================================================
Stage 2: Reading catalog from disk image.
VSS snapshot was enabled. But all snapshots were deleted.
==================================================
Stage 3: Carving data blocks.
Started at 2021/10/25 15:27:26
Progress: 999835041792 / 999835041792 bytes (100.00%) at 2021/10/25 16:56:17
Finished at 2021/10/25 16:56:17
==================================================
Stage 4: Grouping store blocks by VSS snapshot.
==================================================
Stage 5: Checking next block offset lists.
==================================================
Stage 6: Deduplicating carved catalog entries.
==================================================
Stage 7: Writing store file.
==================================================
Stage 8: Writing catalog file.

python vss_catalog_manipulator.py list F:\catalog

[0] Enable, Date: 2021-10-25 15:56:17, GUID: ac4b5ab5-a335-ec11-834c-b06ebf5f2047
[1] Enable, Date: 2021-10-25 14:56:17, GUID: 907d5cb5-a335-ec11-ba02-b06ebf5f2047

vshadowmount.exe -o 368050176 -c F:\catalog -s F:\store F:\HDD-DD.001 X:

Unable to open source volume
libvshadow_store_block_read_header_data: invalid store block list header identifier.
libvshadow_store_block_read: unable to read store block header.
libvshadow_store_descriptor_read_store_header: unable to read store block at offset: 0.
libvshadow_volume_open_read: unable to read store: 0 header.
libvshadow_volume_open_file_io_handle: unable to read from file IO handle.
mount_handle_open: unable to open volume.

Have an issue with mount
vss_carver.py script ran without any errors, catalog and store files were saved
If i run vss_catalog_manipulator.py with list option, i see list of files
But when I am trying to mount it with -c and -s options, I got errors:

d:\carver\extended-libvshadow\x64>vshadowmount.exe -o 240123904 -c d:\catalog -s d:\store d:\mn.img d:\mount
vshadowmount 20180403

Unable to open: d:\mn.img.
libvshadow_store_block_read_header_data: invalid store block list header identifier.
libvshadow_store_block_read: unable to read store block header.
libvshadow_store_descriptor_read_store_header: unable to read store block at off
set: 54181888.
libvshadow_volume_open_read: unable to read store: 5 header.
libvshadow_volume_open_file_io_handle: unable to read from file IO handle.
mount_handle_open_input: unable to open input volume.