This is a real-life story that happened to one of Belkasoft's test engineer specialists.
She was partially working from home, and had a Belkasoft product installed on her home computer. At the time, she was carefully testing one of our carving functions. When looking through chats carved by the product, she noticed something strange.
A few of the carved chats looked unfamiliar to her.
This stood out as odd, as the computer belonged to her only, while other family members had their own separate computers and they did not have accounts on hers. This meant that she must have been aware of all chats made from that computer. But she was definitely not recognizing a fair portion of the carved results, and, as she confessed later, was very confused if not frightened.
Before we continue the story, let us explain carving a bit. Carving can be completed from raw data and it disregards files and folders completely. It sees a drive or an image as just one big piece of data where it looks for specific groups of bytes, called "signatures". An example of well-known signatures may be "MZ" for executable files (though this is a bad signature because it is not quite unique) or "SQLite format 3" for SQLite databases (excellent signature because it is truly unique).
Another thing to mention is the difference between file carving and artifact carving. File carving is when you are trying to recover the entire file and use file signatures (both examples above are signatures of a kind). There are a number of problems that you may encounter with file carving. First is fragmentation: if you are carving a large file as one contiguous chunk following a file signature, it may be recovered partially incorrectly due to the fragmentation (this also happens to memory carving). Secondly, in most cases it is not possible to guess when the file ends. Some formats have a file length in their header, but very few of them do. Besides, you cannot trust this information all the time: if the header is damaged, this may result in an attempt to read, say a petabyte of data.
The same problem arises when carving utilizes a 'header-footer' approach (for files that have footers). A footer is another signature, which designates the end of a file. However, due to the same fragmentation or overwriting issue discussed above, of the tail of a file, a footer may be never met. With what again will result in an attempt to create an enormously large carved file. This is why the length of any carved file in Belkasoft is limited to 5Mb, this helps with saving case storage.
Unlike file carving, artifact carving always results in a small chunk of data. For artifact carving you are looking for a signature and subsequent data for a single item, such as a chat, a browser link, a call, or a similar item, typically measured by a hundred bytes or so.
This is why, while file carving may not recover old deleted files due to fragmentation and overwriting, artifact carving may perfectly recover very old data (of course, of unencrypted media).
This was exactly the case with our test engineer. After taking a deep breath and analyzing the details of these unfamiliar chats (which is possible to do thanks to 'Origin path' properties), she was able to understand that it was indeed not her history that she was looking at.
At this point she remembered that she bought the computer second-hand and though it had appeared clean at that time, it was now obvious to her that just a quick format was performed by the previous owner before selling the computer—and as you remember, a quick format does not indeed delete anything (unless this is an SSD drive—but this is another story).
This is one more reminder, that to maintain a correct chain of custody, it is not enough to sanitize your donor hard drives by just quick formatting them.