libyal / libvshadow Goto Github PK

Library and tools to access the Volume Shadow Snapshot (VSS) format

License: GNU Lesser General Public License v3.0

PowerShell 1.76% Shell 4.44% C 80.39% Makefile 1.33% C++ 0.15% Python 2.71% M4 8.50% Roff 0.72%

libvshadow's Introduction

libvshadow is a library to access the Volume Shadow Snapshot (VSS) format.
The VSS format is used by Windows, as of Vista, to maintain copies of data on a storage media volume.

Project information:

* Status: alpha
* Licence: LGPLv3+

Also see:

* OSDFC 2012: Paper - Windowless Shadow Snapshots: https://github.com/libyal/documentation/blob/master/Paper%20-%20Windowless%20Shadow%20Snapshots.pdf
* OSDFC 2012: Slides - Windowless Shadow Snapshots: https://github.com/libyal/documentation/blob/master/Slides%20-%20Windowless%20Shadow%20Snapshots.pdf

Work in progress:

* Dokan library support
* Multi-threading support

For more information see:

* Project documentation: https://github.com/libyal/libvshadow/wiki/Home
* How to build from source: https://github.com/libyal/libvshadow/wiki/Building

libvshadow's People

Contributors

Stargazers

Watchers

libvshadow's Issues

Add dokany support

Hi Joakim,

I'm running into an issue with building libvshadow on Win2012 R2 server.
I compiled Libvshadow using Visual studio Express 2017 and Dokan provided from your Git.
I suppose this is due to the dokan version been too old for Windows2012 but havn't been able to use dokany instead.
Do you have any suggestions?

Thanks.
Olivier.

vshadowmount: Why is there a limit of 99 stores?

libvshadow does not appear to support more than 100 snapshots.
The relevant line of source code is quoted below.

libvshadow/vshadowtools/mount_file_entry.c

Line 675 in ee8681d

|| ( number_of_stores > 99 ) )

Windows Server creates snapshots frequently, so more than 100 snapshots may be created.
What is the reason for setting the maximum number of snapshots to 100?

vshadowmount segfault

Using vshadowmount included via SANS's SIFT workstation I get a segfault when attempting to access a volume shadow copy. vshadowmount works, and I can even losetup the resulting vss1, etc. files, but when I try to do anything more complicated than a plain ls on them (say, actually mounting the /dev/loopN) I get a segfault.

The disk image is taken from a windows 8.1 machine (CurrentVersion : 6.3). I am not sure if the issue is related to Win 8.1 disk images specifically. I haven't tested with a win7 or win10 image yet. When I get a chance I can update this issue once I test with more images.

Here is the version of vshadowmount and libvshadow

root@siftotron:/mnt/DFIR/win81# vshadowmount -V
vshadowmount 20160110

Copyright (C) 2011-2016, Joachim Metz.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Report bugs to <[email protected]>.

root@siftotron:/mnt/DFIR/win81# file /usr/lib/libvshadow.so.1.0.0
/usr/lib/libvshadow.so.1.0.0: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c2ad89c9acd48894c7708fa041cbf6061701598b, stripped

Here's a typescript of the steps I took to create the issue, as well as the backtrace.

root@siftotron:/mnt/DFIR/win81# mmls hdd.raw
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Safety Table
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  Meta      0000000001   0000000001   0000000001   GPT Header
003:  Meta      0000000002   0000000033   0000000032   Partition Table
004:  000       0000002048   0000821247   0000819200   Basic data partition
005:  001       0000821248   0001353727   0000532480   EFI system partition
006:  002       0001353728   0001615871   0000262144   Microsoft reserved partition
007:  003       0001615872   0921436159   0919820288   Basic data partition
008:  004       0921436160   0922357759   0000921600
009:  005       0922357760   0976764927   0054407168   Basic data partition
010:  -------   0976764928   0976773167   0000008240   Unallocated

root@siftotron:/mnt/DFIR/win81# mkdir /mnt/vssmount

root@siftotron:/mnt/DFIR/win81# vshadowmount -o $((512*1615872)) /mnt/DFIR/win81/hdd.raw /mnt/vssmount/
vshadowmount 20160110

root@siftotron:/mnt/DFIR/win81# ls -al /mnt/vssmount/
total 4
dr-xr-xr-x  2 root root            0 Apr 20 04:17 .
drwxr-xr-x 24 root root         4096 Apr 20 04:17 ..
-r--r--r--  1 root root 470947987456 Jan  1  1970 vss1
-r--r--r--  1 root root 470947987456 Jan  1  1970 vss2
root@siftotron:/mnt/DFIR/win81# losetup -a
/dev/loop0: [fd01]:2229319 (/dev/loop0)
/dev/loop1: [fd01]:2229320 (/dev/loop1)
root@siftotron:/mnt/DFIR/win81# losetup -f /mnt/vssmount/vss1
root@siftotron:/mnt/DFIR/win81# losetup -a
/dev/loop0: [fd01]:2229319 (/dev/loop0)
/dev/loop1: [fd01]:2229320 (/dev/loop1)
loop: can't get info on device /dev/loop2: Transport endpoint is not connected
root@siftotron:/mnt/DFIR/win81# ls -al /core
-rw------- 1 root root 13721600 Apr 20 04:18 /core
root@siftotron:/mnt/DFIR/win81# date
Wed Apr 20 04:18:46 UTC 2016
root@siftotron:/mnt/DFIR/win81# mv /core ./vshadowmount.core
root@siftotron:/mnt/DFIR/win81# which vshadowmount
/usr/bin/vshadowmount
root@siftotron:/mnt/DFIR/win81# gdb /usr/bin/vshadowmount ./vshadowmount.core
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/vshadowmount...done.
[New LWP 3354]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `vshadowmount -o 827326464 /mnt/DFIR/win81/hdd.raw /mnt/vssmount/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fa1bb418935 in libcdata_btree_replace_value () from /usr/lib/libvshadow.so.1
(gdb) bt full
#0  0x00007fa1bb418935 in libcdata_btree_replace_value () from /usr/lib/libvshadow.so.1
No symbol table info available.
#1  0x00007fa1bb404078 in libvshadow_block_tree_insert () from /usr/lib/libvshadow.so.1
No symbol table info available.
#2  0x00007fa1bb40ae6b in libvshadow_store_descriptor_read_store_block_list ()
   from /usr/lib/libvshadow.so.1
No symbol table info available.
#3  0x00007fa1bb40b56f in libvshadow_store_descriptor_read_block_descriptors ()
   from /usr/lib/libvshadow.so.1
No symbol table info available.
#4  0x00007fa1bb40b87e in libvshadow_store_descriptor_read_buffer () from /usr/lib/libvshadow.so.1
No symbol table info available.
#5  0x00007fa1bb40661e in libvshadow_internal_store_read_buffer_from_file_io_handle ()
   from /usr/lib/libvshadow.so.1
No symbol table info available.
#6  0x00007fa1bb40676d in libvshadow_store_read_buffer () from /usr/lib/libvshadow.so.1
No symbol table info available.
#7  0x0000000000414562 in mount_handle_read_buffer (mount_handle=0x209c060, store_index=0,
    buffer=0x209cde0 "\270n\033\273\241\177", size=4096, error=0x7ffe74bfd0b8) at mount_handle.c:585
        function = 0x44162a "mount_handle_read_buffer"
        read_count = 0
#8  0x0000000000414e6a in vshadowmount_fuse_read (path=0x209cc10 "/vss1",
    buffer=0x209cde0 "\270n\033\273\241\177", size=4096, offset=470947921920, file_info=0x7ffe74bfd1e0)
    at vshadowmount.c:352
        error = 0x0
        function = 0x441f5b "vshadowmount_fuse_read"
        path_length = 5
        read_count = 0
        result = 0
        store_index = 0
        string_index = 5
#9  0x00007fa1bb6f91a7 in fuse_fs_read_buf () from /lib/x86_64-linux-gnu/libfuse.so.2
No symbol table info available.
#10 0x00007fa1bb6f9352 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
No symbol table info available.
#11 0x00007fa1bb70181e in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
No symbol table info available.
#12 0x00007fa1bb70222b in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
No symbol table info available.
#13 0x00007fa1bb6fea6c in fuse_session_loop () from /lib/x86_64-linux-gnu/libfuse.so.2
No symbol table info available.
#14 0x00007fa1bb6f71c8 in fuse_loop () from /lib/x86_64-linux-gnu/libfuse.so.2
No symbol table info available.
#15 0x0000000000416074 in main (argc=5, argv=0x7ffe74bfd7a8) at vshadowmount.c:2320
        error = 0x0
        mount_point = 0x7ffe74bff8ab "/mnt/vssmount/"
        option_extended_options = 0x0
        option_volume_offset = 0x7ffe74bff889 "827326464"
        source = 0x7ffe74bff893 "/mnt/DFIR/win81/hdd.raw"
        program = 0x441c01 "vshadowmount"
        option = -1
        result = 1
        verbose = 0
        vshadowmount_fuse_operations = {getattr = 0x4156cc <vshadowmount_fuse_getattr>,
---Type <return> to continue, or q <return> to quit---
          readlink = 0x0, getdir = 0x0, mknod = 0x0, mkdir = 0x0, unlink = 0x0, rmdir = 0x0,
          symlink = 0x0, rename = 0x0, link = 0x0, chmod = 0x0, chown = 0x0, truncate = 0x0,
          utime = 0x0, open = 0x414a3b <vshadowmount_fuse_open>,
          read = 0x414bcb <vshadowmount_fuse_read>, write = 0x0, statfs = 0x0, flush = 0x0,
          release = 0x0, fsync = 0x0, setxattr = 0x0, getxattr = 0x0, listxattr = 0x0,
          removexattr = 0x0, opendir = 0x0, readdir = 0x4151ee <vshadowmount_fuse_readdir>,
          releasedir = 0x0, fsyncdir = 0x0, init = 0x0,
          destroy = 0x415934 <vshadowmount_fuse_destroy>, access = 0x0, create = 0x0, ftruncate = 0x0,
          fgetattr = 0x0, lock = 0x0, utimens = 0x0, bmap = 0x0, flag_nullpath_ok = 0,
          flag_nopath = 0, flag_utime_omit_ok = 0, flag_reserved = 0, ioctl = 0x0, poll = 0x0,
          write_buf = 0x0, read_buf = 0x0, flock = 0x0, fallocate = 0x0}
        vshadowmount_fuse_arguments = {argc = 0, argv = 0x0, allocated = 0}
        vshadowmount_fuse_channel = 0x209c480
        vshadowmount_fuse_handle = 0x209c4d0
(gdb) where
#0  0x00007fa1bb418935 in libcdata_btree_replace_value () from /usr/lib/libvshadow.so.1
#1  0x00007fa1bb404078 in libvshadow_block_tree_insert () from /usr/lib/libvshadow.so.1
#2  0x00007fa1bb40ae6b in libvshadow_store_descriptor_read_store_block_list ()
   from /usr/lib/libvshadow.so.1
#3  0x00007fa1bb40b56f in libvshadow_store_descriptor_read_block_descriptors ()
   from /usr/lib/libvshadow.so.1
#4  0x00007fa1bb40b87e in libvshadow_store_descriptor_read_buffer () from /usr/lib/libvshadow.so.1
#5  0x00007fa1bb40661e in libvshadow_internal_store_read_buffer_from_file_io_handle ()
   from /usr/lib/libvshadow.so.1
#6  0x00007fa1bb40676d in libvshadow_store_read_buffer () from /usr/lib/libvshadow.so.1
#7  0x0000000000414562 in mount_handle_read_buffer (mount_handle=0x209c060, store_index=0,
    buffer=0x209cde0 "\270n\033\273\241\177", size=4096, error=0x7ffe74bfd0b8) at mount_handle.c:585
#8  0x0000000000414e6a in vshadowmount_fuse_read (path=0x209cc10 "/vss1",
    buffer=0x209cde0 "\270n\033\273\241\177", size=4096, offset=470947921920, file_info=0x7ffe74bfd1e0)
    at vshadowmount.c:352
#9  0x00007fa1bb6f91a7 in fuse_fs_read_buf () from /lib/x86_64-linux-gnu/libfuse.so.2
#10 0x00007fa1bb6f9352 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#11 0x00007fa1bb70181e in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#12 0x00007fa1bb70222b in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#13 0x00007fa1bb6fea6c in fuse_session_loop () from /lib/x86_64-linux-gnu/libfuse.so.2
#14 0x00007fa1bb6f71c8 in fuse_loop () from /lib/x86_64-linux-gnu/libfuse.so.2
#15 0x0000000000416074 in main (argc=5, argv=0x7ffe74bfd7a8) at vshadowmount.c:2320
(gdb) quit
root@siftotron:/mnt/DFIR/win81# exit
exit

Improve win2k3 support

~~handle missing catalog entry type 0x03~~
~~do not display type 0x03 information in vshadowinfo~~
~~add means to indicate a store has data~~
~~vshadowinfo add indication that data is not stored in-volume~~

unable to build with wide-character-type

the follow libraries may be effected (they were build with --wide-character-type too):

   libclocale support:                           local
   libcsplit support:                            local
   libcfile support:                             local
   libcpath support:                             local
   libbfio support:                              local

the error:

configure:23850: checking whether to use search for libclocale in includedir and libdir or in the specified DIR, or no if to use local version
configure:23857: result: auto-detect
configure:23878: checking for libclocale >= 20120425
configure:23885: $PKG_CONFIG --exists --print-errors "libclocale >= 20120425"
configure:23888: $? = 0
configure:23902: $PKG_CONFIG --exists --print-errors "libclocale >= 20120425"
configure:23905: $? = 0
configure:23943: result: yes
configure:23951: checking whether libclocale/features.h defines LIBCLOCALE_HAVE_WIDE_CHARACTER_TYPE as 1
configure:23975: x86_64-pc-linux-gnu-gcc -c -march=native -O2 -pipe  conftest.c >&5
conftest.c: In function 'main':
conftest.c:94:0: error: unterminated #if
 #if !defined( LIBCLOCALE_HAVE_WIDE_CHARACTER_TYPE ) || ( LIBCLOCALE_HAVE_WIDE_CHARACTER_TYPE != 1 )
 
conftest.c:93:1: error: expected declaration or statement at end of input
 {
 ^
configure:23975: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libvshadow"
| #define PACKAGE_TARNAME "libvshadow"
| #define PACKAGE_VERSION "20180403"
| #define PACKAGE_STRING "libvshadow 20180403"
| #define PACKAGE_BUGREPORT "[email protected]"
| #define PACKAGE_URL ""
| #define PACKAGE "libvshadow"
| #define VERSION "20180403"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define ENABLE_NLS 1
| #define HAVE_GETTEXT 1
| #define HAVE_DCGETTEXT 1
| #define HAVE_WIDE_CHARACTER_TYPE 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_WCHAR_H 1
| #define SIZEOF_INT 4
| #define SIZEOF_OFF_T 8
| #define SIZEOF_SIZE_T 8
| #define SIZEOF_WCHAR_T 4
| #define HAVE_LIBINTL_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_WCHAR_H 1
| #define HAVE_WCTYPE_H 1
| #define HAVE_FCLOSE 1
| #define HAVE_FEOF 1
| #define HAVE_FGETS 1
| #define HAVE_FOPEN 1
| #define HAVE_FREAD 1
| #define HAVE_FSEEKO 1
| #define HAVE_FSEEKO64 1
| #define HAVE_FWRITE 1
| #define HAVE_VFPRINTF 1
| #define HAVE_FGETWS 1
| #define HAVE_FREE 1
| #define HAVE_MALLOC 1
| #define HAVE_MEMCMP 1
| #define HAVE_MEMCPY 1
| #define HAVE_MEMSET 1
| #define HAVE_REALLOC 1
| #define HAVE_MEMCHR 1
| #define HAVE_MEMRCHR 1
| #define HAVE_SNPRINTF 1
| #define HAVE_SSCANF 1
| #define HAVE_STRCASECMP 1
| #define HAVE_STRCHR 1
| #define HAVE_STRLEN 1
| #define HAVE_STRNCASECMP 1
| #define HAVE_STRNCMP 1
| #define HAVE_STRNCPY 1
| #define HAVE_STRRCHR 1
| #define HAVE_STRSTR 1
| #define HAVE_VSNPRINTF 1
| #define HAVE_DECL_MEMRCHR 0
| #define HAVE_SWPRINTF 1
| #define HAVE_TOWLOWER 1
| #define HAVE_WCSCASECMP 1
| #define HAVE_WCSCHR 1
| #define HAVE_WCSLEN 1
| #define HAVE_WCSNCASECMP 1
| #define HAVE_WCSNCMP 1
| #define HAVE_WCSNCPY 1
| #define HAVE_WCSRCHR 1
| #define HAVE_WCSSTR 1
| #define HAVE_WMEMCHR 1
| #define HAVE_WMEMCMP 1
| #define HAVE_WMEMCPY 1
| #define HAVE_PRINTF_JD 1
| #define HAVE_PRINTF_ZD 1
| #define HAVE_LIBCERROR 1
| #define HAVE_LIBCTHREADS 1
| #define HAVE_MULTI_THREAD_SUPPORT 1
| #define HAVE_LIBCDATA 1
| /* end confdefs.h.  */
| #include <libclocale/features.h>
| int
| main ()
| {
| #if !defined( LIBCLOCALE_HAVE_WIDE_CHARACTER_TYPE ) || ( LIBCLOCALE_HAVE_WIDE_CHARACTER_TYPE != 1 )
| #error LIBCLOCALE_HAVE_WIDE_CHARACTER_TYPE not defined
| ##endif
|   ;
|   return 0;
| }
configure:23988: result: no

vshadowmount: No sub system to mount VSS format

The DD image is from https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

vshadowinfo works, but vshadowinfo doesn't

libvshadow-alpha-20190112 error on mount

Dear @joachimmetz,
first, thanks for this great library and all your other projects 👍

I was migrating from the 20181216 version to 20190112 when I encountered the following error occurring on mounting the vss snapshots from an ewf:

./vshadowmount /mnt/ewf/ewf1 /mnt/vss
vshadowmount 20190112

Unable to open source volume
libvshadow_volume_get_store: invalid store value already set.
mount_handle_open: unable to retrieve input: 1 from input volume.

vshadowinfo runs without errors, also in the 2018-Version everything, including the mount, works fine. Both versions (2018 and 2019) are compiled from the release-page on an up-to-date Ubuntu 16 LTS machine. Compilation shows no errors.

Have you encountered this error in the past? Do you need more information?

Greetings,
Dominik

Initial volume open/read time consuming on some VSS

I am doing some experiments with Libvshadow and following recent changes can now open volumes successfully and read data.

However, I have found that the first call to read data can be very slow (sometimes over 20 seconds). This is accompanied by a significant increase in memory footprint. Presumably, this is because the library is building a map of the cached data blocks?

I have tried the following three methods to read data with the same results:

libvshadow_store_read_buffer_from_file_io_handle()
libvshadow_store_read_buffer()
libvshadow_store_read_buffer_at_offset()

Please can I check:

Am I correct that the three methods about are really just different ways to achieve the same thing?
Is the slow start-up expected and is there anything that could be done to improve it please?

Thank you,

Jim

ambiguous versioning schemes

Hi,

I have reported the issue in repology/libversion#4 but it seems may something to do with the way how you release it.

Here is the quote:

No, broken and ambigous upstream (and I mean both software projects and repositories here) versioning schemes cannot and will not be fixed in libversion.

Here 'alpha' it's not even part of the version. Tag is numeric, version in configure.ac is numeric, 'alpha' is only mentioned in release name and even there it preceeds version which suggests it's not a part of it. No other repo use this suffix either.

This is all confusing. Could you name releases (all libc* affected) to would match a version in a source code?

Redirected shadow storage not supported

I've made a little and quick test program using libvshadow in C++ that does the following:

 libvshadow_volume_initialize
 libvshadow_volume_open_wide
 libvshadow_volume_get_number_of_stores

 for store in stores
      libvshadow_volume_get_store
      libvshadow_store_get_copy_identifier
      libvshadow_store_free
 libvshadow_volume_free

For every call there are appropriate error control routines

 libvshadow_error_sprint

The environment:

I've built the library using Visual Studio 2010 and run in Windows 7: everything works fine
I'm using this little program on a spare live volume so I pass something like \?\Volume{066cb78e-f66a-4d00-9baf-28301ed28265} libvshadow_volume_open_wide and it works well
I use vssadmin to create and delete snapshots

The experiment:

After this I redirect shadowstorage of volume E on D and D on E, than create shadows.
libvshadow_store_get_copy_identifier fails.

Remarks:

Its appear because records with type=2 stored on original volume, and records with type=3 on target volume.

Attached logs: libvshadow_D.log

display only differences

Would it be possible to add a flag which would mount the shadow volume to show only the files that are included in the shadow volume and not the original volume.

MinGW compilation can't include FUSE support

Hi Joakim,

As the Windows compliation is having trouble with Dokan I was wondering if I can compile using MinGW.

I tried as describled in the Wiki and got the following output at config:
configure:
Building:
libcerror support: local
libcthreads support: local
libcdata support: local
libclocale support: local
libcnotify support: local
libcsplit support: local
libuna support: local
libcfile support: local
libcpath support: local
libbfio support: local
libfdatetime support: local
libfguid support: local
FUSE support: no

Features:
Multi-threading support: winapi
Wide character type support: yes
vshadowtools are build as static executables: no
Python (pyvshadow) support: no
Python version 2 (pyvshadow) support: no
Python version 3 (pyvshadow) support: no
Verbose output: no
Debug output: no
FUSE support isn't enabled.
I even tried to force it using --with-libfuse=/usr/include
but same results.
looking at the config.log I get the following:
configure:39912: checking whether to use search for libfuse in includedir and libdir or in the specified DIR, or no if not to use libfuse
configure:39919: result: /usr/include
configure:40018: checking fuse.h usability
configure:40018: i686-w64-mingw32-gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -I/usr/include/include -I/usr/i686-w64-mingw32/sys-root/mingw/include conftest.c >&5
conftest.c:160:18: fatal error: fuse.h: No such file or directory
#include <fuse.h>
^
compilation terminated.

Did I missed something?

Thanks for your support.

LIBCERROR_DLL_EXPORT: No such file or directory

Seems like there is some inconsistency in the source code for libvshadow right now, compiling on Debian stable I'm getting:

gcc: error: @LIBCERROR_DLL_EXPORT@: No such file or directory

synclibs.sh is version 20171003.

missing include headers

I was getting relevant error messages (XXX not defined) and had to add the follow two lines:

--- vshadowtools/vshadowmount.c.orig    2017-07-15 15:18:38.000000000 +0800
+++ vshadowtools/vshadowmount.c 2017-07-20 16:26:48.334872904 +0800
@@ -26,6 +26,10 @@
 #include <types.h>
 #include <wide_string.h>
 
+/* blshkv */
+#include <asm-generic/errno-base.h>
+#include <errno.h>
+
 #include <stdio.h>
 
 #if defined( HAVE_ERRNO_H )

No idea about the second one because HAVE_ERRNO_H suppose to add it

Request: Test data

A tiny ntfs image file with VSS for testing.

vshadowinfo add human readable media size

fix header guard

https://github.com/libyal/libvshadow/blob/master/libvshadow/libvshadow_block_tree.h#L23

libvshadow performance degradation with multithread support

I've noticed that in certain circumstances, libvshadow can be awfully slow to access VSCs, and consumes a large number of system handles (locks) in the process. These locks are held by libcdata_list objects, which are used by the libcdata_btree objects used in libvshadow. This is clearly not needed, as libvshadow itself maintains locks around libvshadow volume objects for thread safety.

So, as a workaround, disabling multithread support when compiling libcdata gives greatly improved performance. This is maybe more of an issue for libcdata - but I think we should consider ways to better support libvshadow from libcdata. Perhaps only the root of a libcdata btree should maintain a lock, and the child elements should forego locking, even if multithread support is enabled?

No sub system to mount VSS format on Debian build

mmls "~/Win10_32/Win10_32.raw"
vshadowinfo -o $((104448*512)) ~/Win10_32/Win10_32.raw
vshadowmount -o $((104448*512)) -X allow_other ~/Win10_32/Win10_32.raw /mnt/test

The results are troubling me !

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   0000104447   0000102400   NTFS / exFAT (0x07)
003:  000:001   0000104448   0025288703   0025184256   NTFS / exFAT (0x07)
004:  000:002   0025288704   0026210303   0000921600   Unknown Type (0x27)
005:  -------   0026210304   0026214399   0000004096   Unallocated
vshadowinfo 20200504

Volume Shadow Snapshot information:
	Number of stores:	2

Store: 1
	Identifier		: 7c965892-c57e-11ea-bdc7-08002774c15e
	Shadow copy set ID	: 70a73270-aa84-4b2f-b62d-2169b2e67e6a
	Creation time		: Jul 13, 2020 19:14:13.882010800 UTC
	Shadow copy ID		: 1c996669-ad3f-4afc-8fbd-5021ff31c567
	Volume size		: 12 GiB (12894339072 bytes)
	Attribute flags		: 0x0042000d

Store: 2
	Identifier		: 0118b423-c546-11ea-bdc9-08002774c15e
	Shadow copy set ID	: c3232f7c-c506-4eca-b2f9-42a92c4813cd
	Creation time		: Jul 13, 2020 20:21:12.735740600 UTC
	Shadow copy ID		: 598eedc5-208d-460f-97df-8f4932e8ac42
	Volume size		: 12 GiB (12894339072 bytes)
	Attribute flags		: 0x0042000d

vshadowmount 20200504

**No sub system to mount VSS format.**

Please ./configure shows :

Building:
   libcerror support:                            local
   libcthreads support:                          local
   libcdata support:                             local
   libclocale support:                           local
   libcnotify support:                           local
   libcsplit support:                            local
   libuna support:                               local
   libcfile support:                             local
   libcpath support:                             local
   libbfio support:                              local
   libfdatetime support:                         local
   libfguid support:                             local
   **FUSE support:                                 libfuse**

The OS is Debian. and I build the .debs using dpkg-buildpackage -b -rfakeroot -us -uc and install them sudo dpkg -i libvshadow*.deb.

I still get : No sub system to mount VSS format.

question

Hi,
i want to use libvshadow and libewf both, but they are in conflict because they have libcdata(when i use both libshadow.a and libewf.a),
could you please tell me how to compile?
thanks !!!

Can't retrieve certain store metadata after 31st snapshot

I've made a little and quick test program using libvshadow in C++ that does the following:

libvshadow_volume_initialize
libvshadow_volume_open_wide
libvshadow_volume_get_number_of_stores

for store in stores
    libvshadow_volume_get_store
    libvshadow_store_get_copy_identifier
    libvshadow_volume_get_store_identifier
    libvshadow_store_get_number_of_blocks

    libvshadow_store_free

libvshadow_volume_free

For every call there are appropriate error control routines

libvshadow_error_sprint
libvshadow_error_backtrace_sprint

And I just print the information on console.

The environment:

I've built the library using Visual Studio 2010 and run in Windows: everything works fine
I'm using this little program on a spare live volume so I pass something like \\?\Volume{e5766785-278e-477f-8716-5730fbbe3d35} to libvshadow_volume_open_wide and it works well
I use vssadmin to create and delete snapshots
I've ran these experiments on one Windows 10 and two Windows Server 2012, vanilla virtual machines, default writers and providers, unlimited shadow storage area

The experiment:

I start with some files in the volume, no snapshots there. I run the program and I get the obvious results: successfully opened volume, no stores.
Then I start taking snapshots: any snapshot type is fine. After every couple of snapshots I run this test program and everything works flawlessly: I get the number of stores (for now, the same number of snapshots), I get the store copy identifier and the store identifier as well as the number of blocks for that store. I've also managed to get all the other parameters and available calls in the library.
When I take the 32nd snapshot (we have snapshots from 0 to 31)
libvshadow_volume_get_store succeeds
libvshadow_store_get_copy_identifier fails, the error is empty and the backtrace as well
libvshadow_volume_get_store_identifier succeeds
libvshadow_store_get_number_of_blocks fails, the error is libvshadow_store_get_number_of_blocks: unable to retrieve number of blocks store descriptor 31 and the backtrace is libvshadow_store_descriptor_get_number_of_blocks: invalid store descriptor - missing in-volume store data
I don't expect libvshadow_store_get_number_of_blocks to succeed but it may shed some light on the former error. The in-volume store data is there and I can tell by the result of libvshadow_volume_get_store_identifier

Now things get a little more interesting:
4. If I keep taking snapshots then libvshadow_volume_get_number_of_stores won't return more than 32 stores.
5. After passing the 32nd store, every time I run this program the results are the same. Same stores, same error. If I start deleting snapshots in between the first one and the last one I get the same results: same error, same store. I know that, internally, If I delete snapshots in between the oldest and the newest, stores remain the same, so I didn't expect this to change.
6. If I start deleting snapshots in order, from the beginning (let's say snapshot 0, then 1, etc) then the number of stores decreases and libvshadow_volume_get_number_of_stores reflects what's actually on <Volume>\System Volume Information. However, the failure persists as in point 3 but in the last store (e.g. if I deleted the first 3, there should be 29 stores, so it fails in store 28)
7. If I start taking snapshots again, then libvshadow_volume_get_number_of_stores reflects the correct number of stores until store 31 again.
8. If I keep taking snapshots then the number freezes to 32 stores again like in point 5 but in contrast to point 3 it doesn't fail at libvshadow_store_get_copy_identifier nor libvshadow_store_get_number_of_blocks

Remarks:

I've achieved this situation several times in three different systems. It is somewhat easy to recreate the problem over and over.
I've seen this program reporting 64 stores once from libvshadow_volume_get_number_of_stores in an unattended system that autonomously takes snapshots over time, but it still stuck in that number (wouldn't increase with subsequent snapshots) An inspection on <Volume>\System Volume Information revealed more than a hundred of stores for that volume

Noob needs assistance

I am not cognizant of how to use the files in the folder.

Have: Ubuntu 20.04 64-bit: updated as of 9/25/2020
Python3 is installed.
The libvshadow tar is downloaded and unpacked in my Downloads folder.
I understand how to navigate Ubuntu and Windows based operating environments if that matters.

Need: detailed instructions on how to get the application to work. I have tried using the sh scripts and i am absolutely clueless as to what to do. Am i supposed to install the program? am i supposed to compile it first? I do not know what i have and what to do. What has been provided in the Git always delivers errors of some kind that i cannot rectify. Mercy. I need help please. I understand that the Github is probably for advanced users, though i am interested in libvshadow for uncovering lost files on NTFS drives.

Any help is appreciated. Thank you!

Packages needed for building on Fedora

According to the Wiki, Debian needs sudo apt install git autoconf automake autopoint libtool pkg-config.

I've found that Fedora can work with the following roughly equivalent set of packages (although on my system it seems like git and pkg-config were preinstalled):

sudo yum install git autoconf automake gettext-devel libtool pkg-config

Just thought this might be worth adding to the Wiki.

Support for snapshot description (custom name for the restore point)?

Are there plans to add the ability to retrieve a snapshot description that is set by the user when creating a restore point?

I did some research, but all I was able to accomplish was to find the relationship between the snapshot name and the snapshot itself (by storage ID), and a few other things. But I couldn't find an offset indicating the structure of the snapshot name. I'm sure it's possible to avoid using disk signature carving (carving is a long process): Windows is very fast at finding snapshot names when requesting a system restore through the user interface.
I have attached a description of the part of the snapshot name structure that I am investigating.

Each such structure starts with 8F11E16A1A59E047B2C33CFA26EC2B80 (constant across all snapshots and all machines). Unknown byte sequences are marked in yellow, but they are constant across snapshots and machines. From these constant signatures it is possible to find the name structure using carving.
Using Shadow copy set identifier and Shadow copy identifier, it is possible to associate a snapshot name with a specific snapshot.
Snapshot creation time refers to the snapshot creation time, which is displayed in the Windows UI during system recovery (libvshadow extracts from Catalog entry type 0x02 a creation time that differs by a few seconds from the Snapshot creation time).
Next is the length of the snapshot description (name) and the description itself (name).

Researched structure:

Store Information format:

Example of the Store Information:

man page: vshadowinfo accepting -o argument is not documented

RE: release 20140731

vshadowinfo -h provides basic syntax showing the -o arg for offset. The man page and info page don't show that argument as supported.

Limit symbols exported by shared libraries

Hi Joachim,

In Debian, shared library packages can contain a .symbols file (see deb-symbols(5)) that contains information about which versions of a given library export which symbols. This is useful for automatically determining versioned install dependencies in packages containing programs that are linked against a given shared library.

In libvshadow (and all the other libyal* packages I maintain for Debian) I noticed that many symbols from your other libraries were also exported, e.g. libcdata_*, and put a workaround in place.

But one might as well limit the symbols that are exported when linking the shared library in the first place. This can be done by adding -export-symbols-regex ^libvshadow_ to libvshadow_la_LDFLAGS in libvshadow/Makefile.am

Do you see any problem with such a change for libvshadow and all the other libraries?

Cheers,
-Hilko

libyal / libvshadow Goto Github PK

libvshadow's Introduction

libvshadow's People

Contributors

Stargazers

Watchers

Forkers

libvshadow's Issues

The environment:

The experiment:

Remarks:

Recommend Projects

Recommend Topics

Recommend Org