Files carved from slack marked as Deleted:false

[reacan]

This happens on v.3.17.1. Maybe there is some logic behind this that I just don't understand, but to me it seems that those files should be marked as deleted:true.

Basic Properties
name Carved-1451704320.jpg
size 53485
type jpg
deleted false
category [Images in System Folders]
hash 228C7CB0453B2A2F817EB74C6689434E
path /img_2003538-SSD1.001/vol_vol2/System Volume Information/{632ae39a-4680-11e9-b352-88ae1dab2144}{3808876b-c176-4e48-b7ae-04046e6cc752}-slack>>Carved-1451704320.jpg

[lfcnassif]

Actually there is a logic and a reason for that. Sleuthkit shows VSC content in slack, not in the actual file. See sleuthkit/sleuthkit#466

So those carved files could not be deleted inside VSC, or could be...

If you thought it strange normal slack files (not related to VSC) larger than cluster size, see sleuthkit/sleuthkit#756

[gisms]

Hi!!!

A similar question to the case in question, but not located in VSC or slackspace.

We found a Thumbs.db database in a folder. Extracted from it, came an image file: Thumbs.db>>256_7029eae0d52ea46f>>Carved-24.jpg
(carved true and deleted = false)

In the same folder there is a pdf file to which this thumbnail seems to references.

Was this file actually carved from the database? I was wondering why the deleted=false?

[lfcnassif]

Is the Thumbs.db file with status deleted = true? Generally, deleted status of carved files should be equal to their parent item.

[gisms]

No, Thumbs.db file with status deleted = false.
So thats's why the carved image came as deleted = false.

Was the image really carved (in the sense of recovery technique) or was it actually more of a database extraction?

[lfcnassif]

It was carved. IPED uses an optimized data carving algorithm to recover/extract data from many non deleted areas, like pagefile.sys, hiberfil.sys, Volume Shadow Copies, binary files (exe, dll, etc), unknown files, files without a specific parser/decoder that may contain other files. So it will carve files embedded into other (unsupported) files. That usually is not done by other tools that use standard carving algorithms because they would take a long time to scan all those areas.

[lfcnassif]

In your specific case, our Thumbs.db parser is not perfect, so we use data carving to extract images contained in Thumbs.db files. Actually, 256_7029eae0d52ea46f is the embedded object in the Thumbs.db OLE container, it is the image thumbnail but with an additional 24 bytes header before the JPG header, data carving here is just extracting the JPG file from that object (removing the 24 bytes header in practice).

[gisms]

Ok, thank u a lot!!!