How forensics recover reliably deleted data

[Марат]

For the investigator who analyzes the suspect’s computer, there is always data of particular interest. But it seems to some that if you overwrite the area where the file was located with random data, then nothing will be restored. This is true, but only in part. Even after such reinsurance, data can often be retrieved!

What happens when a file is deleted? Very simple: in the file system, one attribute is changed for it, and thus it is marked as deleted. At the same time, the contents of the file still remain on the hard drive, and it can be restored using one of the many paid and free programs (for example, R-Studio). We have written many times about how to safely delete files without the possibility of recovery. Fortunately, a huge number of shredder utilities have been developed, which, using simple techniques, overwrite the disk sections on which the deleted data was located. Thus, even when using recovery technologies, in which data is read directly from magnetic media, it will be impossible to recover deleted files. Even real professionals in the field of data recovery have assured us of the effectiveness of this approach. But - the gurus still have loopholes for extracting information!

Image files

Let's start by looking at a simple case - deleting a regular photo. Suppose we have a folder with photos, and we get rid of one of them. And we delete by all the rules, overwriting the desired area of the disk several times. In theory, nothing else should betray its existence (unless we ourselves had previously copied it to another folder and forgot about it). But here, just many people forget about one feature of Windows - the file Thumbs.db. This is a special storage used by the operating system, which contains thumbnails of images from the current folder. If you select the "Page Thumbnails" display mode in the explorer, then the OS will take the thumbnails of the images just from this file. It is created in each folder in which there are pictures, and contains thumbnails of images in JPEG format (regardless of the format of the original image).

Let's conduct a small experiment - create a folder and place any three pictures there. Now open this directory in Explorer - Thumbs.db has appeared (to see this file, you need to enable the display of hidden files). We can view and analyze it using the Thumbnail Database Viewer utility. The program, as expected, shows thumbnails for all three files. And now we will delete one of them using the SDelete program or any other program for the safe deletion of data:

sdelete.exe -p 2 file1.jpg

The parameter p is responsible for the number of passes of the shredder, that is, it indicates how many times the file will be overwritten before deletion. As a result, the image will be permanently erased from the hard drive. But let's see if this deletion somehow affected Thumbs.db? Reopening it, and what do we see? The thumbnail for the deleted picture is still in place! It turns out that the file can easily contain thumbnails of already deleted images. And on this, as I was told, more than one smart person was caught ...

How to avoid this? Very simple - you just need to disable thumbnail caching in Thumbs.db files. On Windows XP, you must set the DisableThumbnailCache key in the HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Advanced key to "1". On Windows 7, this key is named NoThumbnailCache and is located in HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ Explorer. And, of course, it is important not to forget to delete all Thumbs.db.

Swap file

Substations on the part of the operating system on only one file with thumbnails do not end there. As you work with a document, information about it falls into various parts of the OS — a temporary folder, registry, and so on. Therefore, it is very difficult to track and delete all data associated with a file. On top of that, there are places where a copy of a file can happen by accident (sometimes such an accident can be very expensive). I am talking about the page file (pagefile.sys) and the memory swap used during Hibernation mode (hiberfil.sys). It is obviously impossible to predict the contents of the swap file, and no one can guarantee anything. I suggest in another experiment to make sure that this is a dangerous place.

Since the operating system just doesn’t allow you to view or copy the swap file, we have two options: use special utilities or boot into another OS and access the file from it. The second method seemed simpler to me, since the Back Track, stuffed with various utilities, including for file recovery, was at hand. Therefore, having booted from LiveCD, I mounted the Windows partition and went to the "BackTrack-> Forensic" section, from where I launched the Foremost utility. This wonderful console program can recover files based on their headers and internal structure. It is only necessary to transfer the name of the input file in which the search will be carried out, and indicate the directory where all the data found will be saved:

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

As the input file, I specified the swap file /mnt/hda1/pagefile.sys, and the directory for saving the results was / root / Desktop / page_file. The program began its work. In a short time, Foremost managed to find and extract 524 files.

Statistics of extracted files:
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 conveniently sorted all files by type and sorted them into different folders. The first thing I did was to check what got into the jpg folder. Of all the recovered files, about half refused to be displayed, but the other was perfectly visible. And what was not among the pictures: a couple of pictures that I deleted recently; many small images from websites; Facebook friends avatars and more. Honestly, I did not plan to detect so many images. In addition to the pictures, I also wanted to know what the only doc-file that got into the page file. But, unfortunately, Word only cursed that the file was damaged and could not open it. An unexpected surprise awaited me in the cookie folder - scrolling through a few files, I found the addresses of videos that I watched almost a year ago on YouTube. Here is another proof that even deleting all cookies and history in the browser can still be punctured.

What can be done here? There are several options. The first is to disable the swap file altogether. To do this, go to "Control Panel-> System and Security-> System-> Advanced System Settings-> Performance-> Advanced-> Virtual Memory-> Change" and select the "No paging file" option. The second option is to force the operating system to overwrite all the data in the swap file before turning off the computer. This mode is activated if you set the ClearPageFileAtShutdown key in the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management value to "1". Unfortunately, the second method is very slow, and shutting down the system will take quite a long time, so whether to put it into practice or not, decide for yourself. A similar situation exists with the hiberfil.sys file. It can also be simply disabled, which will save additional disk space.

By the way, you can also explore the swap file under Windows. But since the operating system does not allow viewing and copying using standard tools, we need the FTK Imager program. Go to the "File-> Add Evidence Item" section and indicate the drive where the page file is located. A directory tree will appear in the left pane where you need to select pagefile.sys and use the export function through the context menu. The swap file will be copied to the folder specified by us without any problems, and no system locks from this moment will prevent it from being analyzed. For analysis, by the way, you can use DiskDigger or PhotoRec. The first is simpler, but the second can restore a wider range of different file formats.

Defragmentation

Let's move on to the next reason for the appearance of ghost files. To make it clearer and more understandable - again, we will conduct a small experiment. For him, we need a flash drive and the ability to handle WinHex. First, we will provide the conditions for the experience by deleting all the data from the flash drive. To do this, run WinHex, give the Open Disk command and select our device in the window that appears. After opening, completely select all its contents (Ctrl + A) and hammer it with zeros (Ctrl + L). One note - the dubbing process takes a sufficient amount of time, so I recommend taking a smaller flash drive. From this moment on, there is no data on the drive and, moreover, there is no file system. So the next step is to format the flash drive in NTFS. By default, Windows XP only allows the USB flash drive to be formatted in FAT, but NTFS is required for our manipulations. For the operating system to format the device to the file system we need, you need to go to the device manager, find the USB flash drive there and set the "Optimize for performance" option in the parameters. After that, Windows will be able to format the USB flash drive in NTFS.

The goal of our experience is to see what happens to files during defragmentation. To do this, we will create artificial fragmentation on our information carrier. Take any three jpeg files and any three audio files or video clips (the main thing is that their size be larger than jpegs) and copy them to a USB flash drive in the following order: 1.mp3, 1.jpg, 2.mp3, 2.jpg , 3.mp3, 3.jpg.

I wonder how they are located on the disk? To see this, we will use the DiskView tool from Mark Russinovich. It displays a graphical diagram of the disk, on which you can determine the location of the data or find out which file is occupied by certain clusters (for this you need to click on the cluster with the mouse). Double-clicking provides more detailed information about the file to which the cluster is allocated. Run the program, select our flash drive and click <Refresh> . First comes a green bar, indicating system clusters, but right after it is the area of blue clusters representing our files written one after another. Now create fragmentation by deleting all the audio files. Click again <Refresh> and we see that before each jpeg-file there is an empty area. Now briefly switch to WinHex. To make sure once again that there are no unnecessary graphic files on the flash drive, we will search by signature: look for the sequence "jfif" that is present in the header of any jpeg file. As a result, the editor, as expected, found exactly three such sequences, by the number of remaining files.

Well, the time has come to put things in order: it doesn’t matter when the files are scattered around like this . We launch defragmentation, 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)

Defragmentation has passed, let's see what has changed on the flash drive. Click on <Refresh> in DiskView, and what do we see? Files that were located at a distance from each other are carefully transferred to the beginning of the disk, and are placed strictly sequentially. Now attention! Defragmented files copied to the beginning of the disk, placing them sequentially, but did she overwrite their previous copy with zeros? To answer this question, we again turn to the powerful hexadecimal editor. Search again for "jfif". Oops, now instead of the three lines found, we get as many as six! And this can only mean one thing - now each file is presented in duplicate. Any of them can be easily restored using DiskDigger or Photorec. Now imagine that instead of graphic files we had some confidential documents or files with credit card information. Even if we used utilities like Sdelete and rewrote these three files hundreds of times before deleting them, their ghosts would still remain on the disk and exist there indefinitely. Until overwritten by anything else. And all this time they can be restored!

Truth and myths about magnetic microscopy

Very often people go to two extremes. Some openly hammer on their safety and store on the screw all the incriminating information, being sure that <Shift+Delete> save them. Others, on the contrary, wipe the screw every day and reinstall the OS. Maybe I'm exaggerating. Nevertheless, quite often one has to read disputes on the Web about how many times it is necessary to rewrite a screw so that information cannot be restored. I propose empirically to find out whether one full rewrite is enough to permanently delete all data. So, again, let's take our experimental flash drive and completely rewrite it with zeros, and then format it in NTFS. To check, let’s drop some file on it: let it be JPEG again. It can be easily found in WinHex by the signature "jfif". I have it located at offset 274432. Well, let's start the shredder (I used the HDD Wipe Tool) and erase the entire disk. Now, if you look at WinHex, which is located at offset 274432, then we will see only zeros. To reassure and be more confident, you can try to recover data using DiskDigger, Photorec, Foremost and other utilities. But this is obviously a waste of time - nothing will come of them.

“Well,” you say, “what about the serious devices available to the competent authorities who can recover data?” Well, let's talk about magnetic microscopy. The essence of the method is to determine the state of each bit before overwriting it. That is, whether it was equal to one or zero. Take ASCII encoded text. Each character is encoded with eight bits in such a way that even if only one bit is restored incorrectly, a completely different character is obtained. For example, there is a sequence of “anti” characters, which looks in binary form as follows: 01100001011011100111010001101001. Suppose that magnetic bits have correctly detected all the bits except the last - as a result of this restoration we get the sequence “anth”. The problem turns out. And we are talking about the simplest text file. Imagine what will happen in the case of structured formats - such as archives, database files, executable files, and so on. In addition to this, the method is quite slow and expensive. So in many cases, the use of magnetic microscopy gives the same exact result as restoration by tossing a coin onto the tails. Therefore, there is no need to rewrite the disc three times.

Best defense is attack

What can be done to complicate the lives of people whom your computer may get for examination? There are several options. In the event that an “interesting” file is found on the computer, the time of its creation will be strong evidence against its owner. To trace the chain of events, experts also rely on the creation / access / modification time of the file. So why not confuse the footprints? There is such a wonderful utility on metasploit.com as Timestomp, which allows you to change the creation, modification or access time for a given file. The main options for its use:

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

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

There is also a very interesting option -b, which sets the above attributes in such a way that the EnCase program known in computer forensics circles does not see them and displays them empty .

Thus, to change the file attributes, it is enough to execute the command in the console:

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

You can easily sketch a script that recursively changes the temporary attributes of files. 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 spoil the life of fellow researchers of other people's HDDs. In their work, they use programs written by ordinary people, and therefore - containing errors. Yes, we can exploit vulnerabilities in the software used to search for evidence. You can read more about this in one of the reports from the DefCon conference.

Conclusion

Secure Data Deletion is not a panacea. I dare to assure you that the loopholes described are not the only ones of their kind. And who, by occupation, conducts computer expertise at a professional level, knows where and how to find the data he needs. Now your safety is in your hands - do not let “ghostbusters” find a single “ghost” on your computer. And even better - do not give them a reason to come to visit you .

Programs for safe data deletion:

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

 

[Детективное агентство Тула]

Are there any such specialists at our Forum?
If he (they) is modest (s), then please inform in a "personal".

 

[Гудимов Анатолий Геннадиевич]

Powerful magnets - a panacea for recovering all data! : lol:

 

[Детективное бюро Бориса Турецкого]

Thank you Marat!
Very useful stuff!

 

[Краев Евгений Леонидович]

Thanks, interesting!

 

[Плотников Юрий Михайлович]

Thank you Marat!

 

[Eugen]

At the moment, it becomes popular water cooling and therefore it will be very difficult for an expert to restore something. And I want to draw attention to the fact that after deleting information from the disk, formatting, recording the same amount of information - the data cannot be restored. Another feature is who will recover the data, which program (if the recovery is not successful, no one can restore the data.)

 

[Детективное агентство Тула]

But it seems to some that if you overwrite the area where the file was located with random data, then nothing will be restored. This is true, but only in part. Even after such reinsurance, data can often be retrieved!

And I want to draw attention to the fact that after deleting information from the disk, formatting, recording the same amount of information - the data cannot be restored.

Dear Colleagues!
On the issue of data recovery, you have two completely opposite opinions.
The law of unity and struggle of opposites.
I would like to read the opinion of a qualified IT expert in this thread.

 

[Eugen]

SKF Budaev and partners. Tula.
Yes, I do not argue, a person learns all his life. I have my own vision of the situation, I can also be mistaken - if so, provide a reasoned answer. (by the way, I did an experiment)

 

[Vlas]

"What can be done to complicate the lives of people to whom your computer may get for examination?"
You can use disk encryption. If protection like setting a password on the BIOS can be circumvented (it is ridiculous to even mention the password on WINDOWS), then nothing can be done with the encrypted drive.
You can encrypt using both the OS and third-party programs. In the first case, it is possible to encrypt even the system drive - in the other, only individual folders or non-system drives. If the password is long enough, then without knowing it, you can see the contents of such a disk only with the help of thermorectal cryptanalysis.
You can also use virtual machines.
Programs like VMWARE Workstation or VirtualBox allow you to run another virtual one under the main OS. In practice, this means computer-in-computer. On one computer, you can simultaneously run several independent from each other OS, while one will be the main and the other will be virtual in its window. In this case, the virtual machine will be stored on the computer as a file. Accordingly, "in which case" it all comes down to simply deleting the virtual machine file from the hard drive. If the removal was done correctly (by a special program-shredder), then it will be impossible to restore the virtual machine, as well as everything that was contained in it.