dear all I have an analysis on a windows 10 pro computer. It has 100 GB of ssd hard drive.
As usual I did the copy in E01, opened it with autopsy 4.15, launched few ingest file carving included.
lots of deleted files if extracted, are corrupted and can't be opened.
The activity of shell bags and recent file is high. Lots of file have been deleted. I suspect a fileshredder.
But i analyzed pagefile, hiberfil, prefetch and other. There's no evidence of a fileshredder. The file carving find not a lot of file.
So the question is may the file be overwritten naturally due to do little dimension of the hard drive or necessary overwritten by a shredder?
Files do not get overwritten "naturally".
Already deleted files may, if the available space is low.
Any "normal" user will "naturally" delete files he/she may not need anymore, particularly if the storage media is small, and once these files are deleted they will be overwritten by new files (still if the available space is limited), at the second iteration you will find a situation very like what you describe.
Anyway if what you call a "file shredder" exists and if it is used properly it is very unlikely that you will find any real evidence of its existence or usage.
SSD's are "bad beasts" due to their particular way of writing/updating data in "pages" or "blocks" and because of garbage collection and trim functions.
And, even if a "file shredder" was used, it has to be seen if it was used in a "normal" maintenance context:
Hey Jaclaz, thanks for answering me.
I talk about narurally overwritten, thinking they're deleted and then overwritten by other file.
I the past situation, I found easily the file shredder artifacts. This time no.
I the past situation, I found easily the file shredder artifacts.
Which means that in the past the "file shredder" used was either not a good one (i.e. it left evident traces) or it had been not used properly (i.e. the user left evident traces).
I mean, I doubt that if the user used -say - Sdelete from a PE you would find *any* artifacts.
You state that the files are mainly corrupted. I would expect most to be filled with Zeros.
As Jaclaz mentioned, TRIM will blank any data areas for deleted files. This may leave the directory entry intact, but the data will be all zeros within a fairly short period of time (often between minutes and maybe an hour for for large files).
thanks @mscotgrave. I tested pagefile.sys, hiberfil.sys and swapfile.sys all full by zero. I extracted few pdf, some of them are full of zero other seems sequence of number 6.5 6.4 6.3 etc other contains word as "This program cannot be run in dos mode" thta in a PDF seems strange
I extracted few pdf, some of them are full of zero other seems sequence of number 6.5 6.4 6.3 etc other contains word as "This program cannot be run in dos mode" thta in a PDF seems strange
To be picky, you extracted the extents on disk that - according to your carver - once belonged to currently deleted .pdf files.
Unless you start the carving "immediately" after the deletion of the file occurred those extents may well have been re-used by a completely different file, that may additionally have been since deleted as well, particularly on a filesystem filled up to the brim, where - BTW - fragmentation of the file system may additionally be relevant.
If you prefer what you report besides being common is not "random enough" (or someone may say "too random") to hint about using of a "file shredder".
The ones that are filled with 00's may well be the effect of "normal" SSD automatic cleaning (garbage collection and trim).
The "This program cannot be run in dos mode" is the normal message at offset 0x004E on any executable that is aimed to windows and part of its header, that starts with M - Z - NOP (4D 5A 90).
Normally the size of the executable can be determined by summing the fields SizeOfCode+SizeOfInitializedData, present in the PE header.
I beleive it is actually rather common that a carver mis-identifies a file (or again more precisely an extent) as belonging to a given file type while it is another file or just the remaining of a header followed by a new gile, and usually different carvers/recovery tools will return different results.
ok, many thanks to all