tag:blogger.com,1999:blog-5057815281194312844.post1372889036992446881..comments2024-03-26T19:09:27.512+00:00Comments on Forensics from the sausage factory: Volume Shadow Copy Forensics.. cannot see the wood for the trees?DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-5057815281194312844.post-5387215911666861522013-01-21T10:42:30.719+00:002013-01-21T10:42:30.719+00:00There is a free tool for mapping shadow copies @ h...There is a free tool for mapping shadow copies @ http://code.google.com/p/shadow-map/shooflypiehttps://www.blogger.com/profile/06925882757010789490noreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-24135384527996807922012-01-22T01:10:29.027+00:002012-01-22T01:10:29.027+00:00To clarify, shadow copies in Vista and Win7 are ve...To clarify, shadow copies in Vista and Win7 are very useful for forensics but only provided that you are aware how they work. A "shadow copy" when first created is not really a copy of anything but just a set of pointers back to the real drive. Then, as blocks are overwritten, the original data (as at the time of the "snapshot") is stored in the diffs file.<br />Once it has stored a particular 16k block in the diffs file, Snapvol knows it does not need to store another copy if it changes again - it only cares about the contents at the time of the snapshot.<br />For efficiency, one of the developers of Snapvol told me that it does not bother to preserve the content of blocks which at the time of the snapshot were marked as free space, or those which were used by the swap file or hibernate file. So, as you noted, a search of "free space" in the shadow copy is pointless, as it will just show the current contents of that area of the drive. There is also a registry key which lists other files (such as Temp file) that should be treated the same way - not exactly sure how this is implemented but it seems that it marks any 16k block which is only occupied by these files as if it were free space.<br /><br />Although Microsoft's documentation is silent or misleading (for example saying that previous versions of users files are only stored in Vista Business and above). The System Protection shadow copies contain the entire drive in all versions of Vista/Win7 including Home editions. So anyone trying to "secure erase" incriminating files will likely be unaware that he just copied them to the diffs file for you to find.<br />Finally a very nice feature of Shadow Copies is that they may enable you to find the file name and path of objects of interest that you first found using a scan of free space.PC Guru Austin TXhttps://www.blogger.com/profile/08726392024685446749noreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-63524247575530913152010-03-01T12:38:28.497+00:002010-03-01T12:38:28.497+00:00Hmm, I see what you are saying up to a point. Perh...Hmm, I see what you are saying up to a point. Perhaps it's me just not getting it. Try this.<br /><br />Shadow copy is triggered at midnight for example. The data contained in the shadow copy has aleady been written to it by this time (blocks being copied since the previous shadow copy). It is then 'finalised' or triggered by a system event.<br /><br />Let's assume that on the next and subsequent saves post midnight, that blocks other than 1,8 and 9 are changed. The relevant blocks will be copied to the shadow copy that is currently being written to and not yet finalised.<br /><br />Midnight the following night arrives and a shadow copy is triggered (containing all the changed blocks for the previous 24 hours).<br /><br />You will only be able to revert to the Word document 'as was' at the previous two midnights and not the changes in between, despite all those other changed blocks potentially being present.<br /><br />I think.Gary Enoreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-55484513327663299182010-03-01T11:25:33.284+00:002010-03-01T11:25:33.284+00:00I am not sure that there are any blocks that are c...I am not sure that there are any blocks that are copied and not used.<br /><br />What I think happens is:<br /><br />At the point a SC is created lets say a word doc occupies blocks 1, 7, 8, 9 and 10 (keeping it very simple here). When the word doc is changed by the next save blocks 1, 8 and 9 are changed. at this point the original contents of these blocks are saved to the SC. The next and subsequent saves also change blocks 1, 8 and 9 however no further copy needs to be saved to the SC because the original blocks have already been saved. If this file is then reverted to, the original state at the the time of the SC was created is restored (i.e. All the unchanged blocks plus the original contents of blocks 1, 8 and 9). This restoration will overwrite the subsequently changed blocks because changes between SCs are not monitored.<br /><br />Regards RichardDC1743https://www.blogger.com/profile/14186532367794900206noreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-14173588115046861002010-03-01T10:37:10.980+00:002010-03-01T10:37:10.980+00:00Although it seems that blocks are copied just befo...Although it seems that blocks are copied just before they are changed, you cannot recover every version of every file that is changed from a subsequent shadow copy.<br /><br />Save a Word document ten times and the only copy you will be able to revert to is the copy that was present when the shadow copy was triggered.<br /><br />Any thoughts on what happens to the blocks that are copied and not used?Gary E.noreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-46471705051173728182010-02-23T10:02:04.922+00:002010-02-23T10:02:04.922+00:00Hi,
Deleted file shadow copies do not seem to be ...Hi,<br /><br />Deleted file shadow copies do not seem to be mountable. There are probably many reasons for this but as a starter I suspect that because the SCs are incremental there must be some record of current SCs. The deleted ones are probably not included.<br /><br />Regards RichardDC1743https://www.blogger.com/profile/14186532367794900206noreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-45591050385009314702010-02-23T09:26:03.053+00:002010-02-23T09:26:03.053+00:00Thanks for the report Richard.
Have you had any s...Thanks for the report Richard.<br /><br />Have you had any success 'mounting' or recovering filesystem data from deleted Volume Shadow Copies that have been found to contain pertinent files via carving etc?Unknownhttps://www.blogger.com/profile/01373796185461661113noreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-3097216603322794772010-02-23T08:18:54.631+00:002010-02-23T08:18:54.631+00:00Richard,
Great write-up - thanks. I tend to use an...Richard,<br />Great write-up - thanks. I tend to use an alternative method: ROBOCOPY to extract data from shadows mounted in a VM. <br /><br />First mount all shadows using a MKLINK and a FOR loop, then ROBOCOPY all live pictures/movies from the user's directory from all the mounted shadows preserving the MAC info, again using a FOR command.<br /><br />It only gets live pictures (rather than pics in compound files), but for an initial look, this is what we're after.<br /><br />You can then load the output from ROBOCOPY into EnCase, depude all the files based on path - now you have a list of all the files that have passed through a users 'hands'.<br /><br />IF it goes smoothly, not too onerous a task!<br /><br />Works a treat!<br /><br />James<br /><br />PS> I depude on path rather than hash because if a pic appears on a user desktop AND in Internet cache, I want to see the 2 separate instances.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-58502862353785075532010-02-23T00:33:06.841+00:002010-02-23T00:33:06.841+00:00Very nice! From what I understand, the creation o...Very nice! From what I understand, the creation of shadow copies in 16KB blocks is likely to capture at least portions of free clusters that exist at the shadowing moment. These free clusters may contain files that were deleted, but not referenced by any metadata, i.e., carvable files, as well as files that were created and deleted pre-shadow. Still, I wouldn't be carving anything from "free" clusters on a shadow copy. I'm still a little hazy about why Sony ended up in your first shadow volume, if even its MFT record was not created at the time of shadow creation. Date stamps, when available, should provide clues<br /><br />Concerning the triage of shadow volumes, I use Shadow Explorer (free) regularly. It's great when you need to look at only a few folders. I run it in a VM. <br /><br />In your last post and my comment thereto, we spoke of permissions with mklink. I found that the permisssions issue resolved when I used the <b>last</b> trailing backslash.Jimmy_Wegnoreply@blogger.comtag:blogger.com,1999:blog-5057815281194312844.post-20216087653276156092010-02-21T19:00:30.313+00:002010-02-21T19:00:30.313+00:00Richard
Thanks for the useful write up, I like th...Richard<br /><br />Thanks for the useful write up, I like the idea of using the hash sets.<br /><br />Your report about the recovered folders confirms my findings some while ago which was that any files that have been created post the shadow copy end up in unallocated in the shadow volume.<br /><br />I recently looked at about 20 shadow copies using mklink method in a virtual machine of the target and then used FTKi to create a custom image of just the Mozilla folders that I was interested in for the internet history.<br /><br />I also piped the list shadows to a text file for reference.<br /><br />HHPhttps://www.blogger.com/profile/11774876007771263349noreply@blogger.com