Closed randomaccess3 closed 5 years ago
I am not quite sure what this would be good for. A shadow copy of the database is a backup of a previous state, so logically, the current file is more complete than the backup and the backup has nothing extra to offer.
Do you have a use-case where you need to merge the volume shadow copies?
I use this tool for digital forensics cases occasionally; if someone has deleted messages then merging them all into one would be useful to show that the messages have been deleted. I'm not sure how to present the information but maybe merge them all into one with a "source" identifier that says where the messages came from. Then if you want, you can query each database individually.
I've looked into this a bit now, and it gets a tad tricky. Libraries like libvshadow or pyshadowcopy need to match the OS architecture (64-bit library for 64-bit OS). Meaning the calling application must also be either 32-bit or 64-bit.
But Skyperious needs to be a 32-bit application, in order for the "Contacts+" page to work - it uses API calls to communicate with the running Skype application, and Skype only has 32-bit version. So even the 64-bit Skyperious executable is actually 32-bit, just compiled on x64 architecture.
So, this would introduce a lot of work and changes, for not a great lot of gain. At least at the moment I don't see a good simple way of achieving this.
Do you happen to know more about accessing VSS? As in, is there a roundabout way to get shadow copy paths from a 32-bit program, regardless of OS architecture?
Currently my manual process is as follows: Mount drive Open all volume shadow copies of the skype directory Load main.db's into skyperious (current and all vss) Use the merge feature to merge all into the current main.db
I'm happy to do the first two parts manually; that's not particularly difficult. The update could be including the other issue (allowing for the removal of selected databases rather than having to do it one at a time) then an option to merge all selected databases into one new one. Not sure how to deal with conflicts but there shouldnt be any in the messages/calls/file transfers. The new database would just need to identify which databases the items came from (ie "message", pathtodb1;pathtodb2) so that you can easily tell if a message was deleted. Currently working on a case where there are messages of interest only in one vss main.db; so it looks like that chat has been deleted and is no longer in the current main.db. The only way I determined this was manually flicking through each of the databases and looking at the message counts (which were all 0 except for one db)
Would be a great feature to utilise libvshadow (https://github.com/libyal/libvshadow) to parse and merge the volume shadow copies of the same database rather than having to manually do it