How forensics recover deleted data

[DronVR]

How forensics recover deleted data

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).

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 Explorer, then the OS will take thumbnail previews of the images 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

Parameter R It 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 came across.

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_USERSoftware MicrosoftWindowsCurrentVersionExplorerAdvanced section to "1". On Windows 7, this key is named NoThumbnailCache and is located in HKEY_CURRENT_USERSoftware Microsoft WindowsCurrentVersionPoliciesExplorer. 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'm talking about a page file ( pagefile.sys ) and the memory swap used during mode Hibernation ( 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 section
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ ControlSession ManagerMemory Management value "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 program [DLMURL="https://anonym.to/?https://accessdata.com/support/adownloads"] FTK Imager [/ DLMURL ]. 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 [DLMURL="https://anonym.to/?https://diskdigger.org/"] DiskDigger [/ DLMURL] or [DLMURL="https://anonym.to/?http : //www.cgsecurity.org/wiki/PhotoRec "] PhotoRec [/ DLMURL]. 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 use the tool [DLMURL="https://anonym.to/?https://technet.microsoft.com/en-us/sysinternals/bb896650"] DiskView [/ DLMURL] by 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. The time has come to put things in order: it doesn’t matter when files are scattered like this on a disk. We launch defragmentation, so beloved by users, for our media:

 C: Documents and SettingsAdministrator> 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 “jfif” signature. 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 that 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 that looks in binary form as follows: 01100001011011100111010001101001. Suppose that magnetic microscopy has correctly detected all the bits except the last one - as a result of such 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 case a “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 MonthDayYear 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, well-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"

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.


Programs for safe data deletion:

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

Source @Blacktime