Tuesday, 19 May 2015 00:00

Ghost files: how do forensic examiners recover securely deleted data?

Rate this item
(0 votes)

The investigator carrying out an analysis of suspect`s computer, always finds evidence of special interest. But some people think that if they overwrite the area where the file has been, with random data, then nothing can be recovered. This is true, but only partly. Even after such abundance of caution data can often be retrieved!

What happens when you delete a file? Very simple: a single attribute changes for the file in the file system, and thus it is marked as deleted. The file content still remains on the hard disk, and it can be recovered by using one of the many free and paid software products (for example, R-Studio). We have written many times about how to securely delete files beyond recovery. There is a huge number of tools - shredders, which, with the help of simple algorithms, overwrite disk partitions on which the deleted data was located. Thus, even using recovery technologies, in which data is read directly from magnetic media, it is impossible to recover deleted files. Even high-caliber professionals in data recovery have been assuring us in effectiveness of such approach. But gurus still have loopholes for retrieving data!

Image files

Let's start with the simplest case - deleting a regular photography. Let's say we have a folder with pictures, and we get rid of one of them. And we delete it in due form, having overwritten the proper disk area a few times. Normally, nothing more should betray its existence (if we ourselves had not copied it to another folder and forgot about it.) But it is then many users forget about one peculiarity of Windows - file Thumbs.db. This is a special storage used by the operating system, which contains thumbnails of images from the current folder. If you choose the view mode of "Thumbnails" in the File explorer, the OS will take smaller previewing images just out of this file. It is created in each folder where there are pictures, and contains thumbnails of images in JPEG (whatever the the format of the original image is.)

Let's conduct a small experiment - let us create a new folder and put any three pictures there. Now let us open the directory in Windows Explorer - Thumbs.db appeared (to see the file, you must activate the "Show Hidden Files" option). We can view and analyze it using the Thumbnail Database Viewer utility. The utility, as befits, displays thumbnails of all three files. Now, let us delete one of them using SDelete or any other utility for the secure data deletion:

sdelete.exe -p 2 file1.jpg

The p value is responsible for the number of shredder runs, that is the number of times the file will be overwritten prior to deletion. The result is that the image will be deleted from the hard disk beyond retrieve. But let's see if the deletion somehow affected Thumbs.db. We open it once again, and what do we see? The thumbnail for the deleted image is still there! It turns out that the file could easily contain thumbnails of images already deleted. And as I was told, more than one clever man got nailed by that...

How can one avoid it? It is very simple - you just need to disable the thumbnails caching in Thumbs.db files. In Windows XP, you need to set the value "1" for the key DisableThumbnailCache in partition

 HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Advanced. 

In Windows 7, the key has the name of NoThumbnailCache and is located in

HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ Explorer. 

And, of course, it is important to remember to delete all Thumbs.db.

The page file

The tricks of the operating system do not end with the thumbnail file. As you work with the document, the information on it gets into different parts of the OS - the temporary folder, registry and so on. Therefore it is very difficult to trace and delete all the data associated with the file. On top of that, there are places where the copy of a file can come to be entirely by accident (sometimes this accident can cost an arm and a leg.) I'm talking about the page file (pagefile.sys) and swap memory used during the Hibernation mode (hiberfil.sys). Predicting the content of a page file is obviously impossible, and then no one can guarantee anything. I suggest you another one experiment to make sure that it is a dangerous place.

Since the operating system does not allow viewing or copying the page file for no special reason, we have two options: using special tools or booting another OS and get access for the file through it. The second method seemed simpler to me, as I had Back Track at hand, filled with a variety of tools, including file recovery. Therefore, booting LiveCD, I created a Windows partition and went to the "BackTrack-> Forensic" section and launched the Foremost utility there. This wonderful command line utility can recover files proceeding from their headers and internal structure. All you have to do is to enter the name of the source file where the search will be conducted, and specify the directory where you want all the data found to be saved:

#foremost -i /mnt/hda1/pagefile.sys -o /root/Desktop/page_file -v -q

I have specified the page file / mnt/hda1/pagefile.sys as the source file, and / root / Desktop / page_file as the directory to save the results. The program started processing. In a short time, Foremost managed to find and retrieve 524 files.

The retrieved files statistics:

jpg:= 73
gif:= 4
gif:= 19
jpg:= 77
jpg:= 95
doc:= 1
pgp:= 65
pgp:= 62
pgp:= 44
pgp:= 36
dat:= 7
lnk:= 3
cookie:= 38

The utility sorted conveniently all files by type and placed in different folders. First off, I checked out what has got into the JPG folder. About half of the retrieved files would not be displayed, but the other one could be viewed perfectly. There were various images: a couple of pictures that I deleted not so long ago; a lot of small images from websites, Facebook avatars of friends and so on. Honestly, I did not plan to discover so many images. In addition to pictures, I would like to know what a single doc-file was about, which had got into the page file. Unfortunately, MS Word just gave an error message saying that the file was corrupt and could not open it. Unexpected surprise was waiting for me in the Cookie folder - rifling through some files I found web addresses of videos that I have watched on YouTube almost a year ago. Here is another proof that even deleting all cookies and history in the browser, you can still make a blunder.

What is to be done here? There are a few options. The first one is to disable the page file at all. To do this, you should go to "Control Panel-> System and Security-> System-> Advanced System Settings-> Performance-> Advanced-> Virtual Memory-> Change" and select "No paging file". The second option is to force the operating system to erase all data in the page file at shutdown. This mode is activated by specifying the value "1" for the key ClearPageFileAtShutdown in the partition

 HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management.

Unfortunately, the second method is very slow, and the system shutdown will take a long time, so it's up to you to use it in practice or not.

The situation is similar with the hiberfil.sys file . It can also be simply disabled that will save additional disk space.

By the way, you can explore the page file in Windows, too. But since the operating system does not allow viewing and copying by regular means, we will need the FTK Imager utility. We go to the sub "File-> Add Evidence Item" and specify the drive where the page file is. In the left panel we will see a directory tree; we must select pagefile.sys and use Export function from the context menu. The page file will be copied without any problems to the folder specified by us, and no system lock will hinder analyzing it from this point on. By the way, you can use DiskDigger or PhotoRec for the analysis. The first one is simpler but the second is able to recover a wider range of different file formats.


Let us pass to the next reason for the appearance of ghost files. To make it clear and understandable - again, let's conduct a little experiment. For it, we will need a flash drive and ability to handle WinHex. At first, we will provide conditions for our experience by deleting all data from the stick. To do this, run WinHex, order Open Disk and select our device in the emerged window. After our device is fully opened, highlight all of its contents (Ctrl + A) and overwrite by zeros (Ctrl + L). One remark - the overwriting process takes a sufficient amount of time, so I recommend taking a stick small in size. From now there is no data on our drive and, moreover, there is no file system. So our next step is to format the flash drive into NTFS. By default, Windows XP allows formatting a USB flash drive only into FAT, but we need NTFS for our manipulations. In order that the operating system allowed us to format the device in the required file system, we need to go to the Device Manager, find our stick there and select the "Optimize for performance" option. After that, Windows will be able to format the flash drive into NTFS.

The purpose of our experiment is to see what happens to files during defragmenting. For this purpose we will create an artificial fragmentation on our medium. Let us take any three JPEG-files and any three audio or video files (most importantly, their size must be larger than of JPEGs) and copy them to the stick in the following order: 1.mp3, 1.jpg, 2.mp3, 2.jpg, 3.mp3, 3.jpg.

How did they locate on the disk? To see this, we will use the DiskView tool by Mark Russinovich. It displays a graphical chart of the drive on which we can define the location of the data or find out which file occupies certain clusters (to see it, you need to click on the cluster). Double-clicking allows you to get more information about the file in the selected cluster. We run the utility, choose our flash drive and click <Refresh>. The green bar comes first, indicating the system clusters, but right after it - the blue area of clusters representing our files written one by one. Now we will create fragmentation, deleting all audio files. Again, we press <Refresh> and see that there is an empty area in front of each JPEG-file. Let us switch over to WinHex for sa short while. To make sure once again that there is no extra graphic files on the flash drive, we will carry out the search by signature: we are looking for "jfif" sequence which presents in the header of any JPEG-file. As a result, the editor, as expected, found exactly three such sequences, matching the number of the remaining files.

Well, it's time to sort out the mess: that won't do when the files are round the disk like this :). Run defrag, so beloved by users, for our media:

C:\Documents and Settings\Administrator>defrag h:
Windows Disk Defragmenter
Copyright (c) 2001 Microsoft Corp. and Executive Software International, Inc.
Analysis Report
7,47 GB Total, 7,43 GB (99%) Free, 0% Fragmented (0% file fragmentation)
Defragmentation Report
7,47 GB Total, 7,43 GB (99%) Free, 0% Fragmented (0% file fragmentation)

Defragmenting has passed, let's see what has changed in the flash drive. Click <Refresh> in DiskView, and what do we see? Files that were located at a distance from each other, are gently moved to the top of the disk, and are strictly sequential. And now, attention please! Defragmenting copied the files to the top of the disk, placing them in sequence, but did it overwrite their previous copies with zeros? To answer this question, we turn again to the powerful hexadecimal editor. Make a search for "jfif" once again. Oops!, now we find six lines instead of three! And that can mean only one thing - now every file is represented in duplicate. Any of them can be easily recovered using DiskDigger'a or Photorec'a. Now imagine that there were some confidential documents or files containing data on credit cards instead of the image files. Even if we used utilities like Sdelete and overwrote these three files hundreds of times before deleting, their ghosts would still remain on the disk and exist there indefinitely long. As long as you do not overwrite them with anything else. And all this time they can be recovered!

Facts and fictions about the magnetic microscopy

People very often run into two extremes. Some people openly put a pin in their safety and keep all the sensitive information on the hard drive being assured that <Shift+Delete> will save them. Others, on the contrary, erase the drive every day and re-install the OS. I may be exaggerating. However, I quite often read debates on the web about how many times it is necessary to overwrite the drive so that information can not be recovered. I suggest empirically determine whether one complete overwrite is enough for permanent data deletion. So, again, we take our test flash stick and completely overwrite it with zeros, then reformat it into NTFS. And copy any file to it to check: let it be JPEG again. It can be easily found in WinHex'e by "jfif" signature. I have it located at the flushing of 274432. Well, let us launch a shredder (I used HDD Wipe Tool) and erase the entire disk. Now, if we look in WinHex to see what is located at flushing of 274432, we see only zeros. To rest content and more confident you can try to recover the data using DiskDigger, Photorec, Foremost, and other utilities. But it is certainly a waste of time - they won't make it.

"Well", you say, "but what about major tools, available to the cognizant authorities, which are able to recover the data?" Well, let's talk about the magnetic microscopy. The essence of the method is to determine the state of each bit before overwriting it. That is if it was equal to one or zero. Take a text in ASCII encoding. Each character is encoded by eight bits so that if even one bit is recovered wrong, a different kind of character will come out. For example, there is a character sequence "anti", looking in binary form as follows: 01100001011011100111010001101001. Suppose that the magnetic microscopy has correctly identified all the bits except the last one - as a result of such recovery we obtain a sequence of "anth". We can see a little mismatch. And we are talking about a simplest text file. Imagine what would happen in the case of structured formats, such as archive files, database files, executable files, and so on. In addition, the method is slow and expensive. So in many cases the use of magnetic microscopy gives the same accurate results as the recovery by flipping a coin. Therefore there is no need to overwrite the disk many times.

Best defence is offence

What can be done to make life difficult for the people to whom your computer can get for expertise? There are several options. In case if an "interesting" file have been found, its creation time is strong evidence against the PC owner. In order to trace the chain of events, experts also rely on the time of creation / access / modification of the file. So why not to foul the trail? There is such a wonderful tool, as Timestomp on the metasploit.com website, which allows you to change the time stamp as well as the access time to the specified file. The main options for using it:

-m <date> sets the date of the last file modification
-a <date> sets the date of last access to the file 
-c <date> sets the time of file creation 
-e <date> sets the time of file modification saved in MFT
-z <date> sets all four parameters listed above

The date is specified as follows: DayofWeek Month\Day\Year HH:MM:SS [AM|PM].

There is another very interesting option -b, which sets the above attributes so that EnCase software, widely known among computer forensic examiners, does not see them and display them empty :).

So, to change the file attributes, just execute the console command:

c:\>timestomp.exe boot.ini -z "sunday 1/12/2099 10:00:00 pm"

You can easily sketch a script that will recursively change the temporary file attributes. The simplest option is as follows:

for /R c:\tools\ %i in (*) do timestomp.exe %i -z "monday 3/12/2009 10:00:00 pm"

There are other ways to embitter slightly the life of examiners of someone else's HDD. In their work they use utilities written by ordinary people, and that is why containing errors. Yes, we can use vulnerabilities of software used to search for evidence. Read more about it in a report from the DefCon conference.


"The secure data deletion" is not a panacea. I dare assure you that described loopholes are not the only ones of their kind. And he, who by the nature of his occupation conducts examinations of computers in a professional manner, knows where and how to find the required data. Now your safety begins with you - do not let "ghost busters" to find any "ghost" on your computer. And better yet - do not give them a cause for coming to your house :).

Programs for secure data deletion:

  • Eraser 6.0.8;
  • SDelete 1.51;
  • Freeraser;
  • Overwrite 0.1.5;
  • Wipe 2.3.1;
  • Secure Delete;
  • CCleaner 3.03

Your hard disc suffered a crash? It will be rapidly retrieved in Seattle Data Recovery Lab. Click here for more information.

Last modified on Tuesday, 19 May 2015 22:22
Data Recovery Expert

Viktor S., Ph.D. (Electrical/Computer Engineering), was hired by DataRecoup, the international data recovery corporation, in 2012. Promoted to Engineering Senior Manager in 2010 and then to his current position, as C.I.O. of DataRecoup, in 2014. Responsible for the management of critical, high-priority RAID data recovery cases and the application of his expert, comprehensive knowledge in database data retrieval. He is also responsible for planning and implementing SEO/SEM and other internet-based marketing strategies. Currently, Viktor S., Ph.D., is focusing on the further development and expansion of DataRecoup’s major internet marketing campaign for their already successful proprietary software application “Data Recovery for Windows” (an application which he developed).

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.