Given that you’re reading the blog from a data recovery company, you probably already know that “deleted” data does not immediately disappear from a drive, it is simply marked for overwriting by the operating system. With the right tools, this deleted data can be recovered quite easily.
It should be noted that DIY data recovery is almost always not advised. More often than not, DIY recovery attempts result in making damage worse, and often it means the data is unrecoverable. The only exception to this are commercial data recovery software tools, including Ontrack EasyRecovery. But if you would like to learn some basic data recovery techniques then you can get down and dirty with a hex editor.
Before reading any further though, you must be aware that using a hex editor to change file clusters could lead to permanent loss of data. Because of that risk, you should only proceed using a throwaway hard drive or USB flash drive. If you want to keep your data
We do not recommend trying to recover actual lost files yourself using these techniques as there are many, many other factors that can influence the recovery, including physical damage or the presence of multiple files. The intention of this blog post is purely for education.
If you are in any doubt at all, please download a free trial of Ontrack EasyRecovery, or get in touch with one of our data recovery consultants.
OK, with that out of the way, let’s begin.
If you are determined to try to recover deleted files from your NTFS drive, you will need the following:
- The drive containing the deleted data – Remember, this should be a drive with data that can be lost. We would recommend using a USB flash drive with a single deleted file on it.
- A host PC to perform the file recovery operation
- A hex editor (we recommend WinHex)
- A second drive to copy recovered data on to
- The name of the deleted file
Connect the two drives to your PC, fire up your hex editor, and you’re ready to begin.
There are three steps to the data recovery process using hex editors:
- Scanning the disk to identify deleted files (or entries)
- Identifying the clusters chain for the deleted file of interest
- Recovering the clusters that contain the deleted file
It is important to note that not every file can be recovered. If the clusters containing your deleted files have been overwritten, you the data is almost certainly gone. This is why we always recommend ceasing to use a device with data loss immediately, as any activity after the data loss can cause these clusters to be overwritten.
1. Scanning the NTFS volume
Using the search function built into your hex editor, scan the drive for the name of the file that was deleted. In this example, we’re looking for the PowerPoint presentation called “My Presentation.ppt” – the hex editor will return a string like this:
In the right-hand column, you can just make out the file name as M.y. .P.r.e.s.e.n.t.a.t.i.o.n…p.p.t.€
Among the many attributes returned by a disk search, is one called Flags, located 22 bytes into the File Record Header – it’s highlighted in red in the picture above. If the field is set to 1, the file is “in use”, or not deleted. In our example, the field is set to 0, which means that My Presentation.ppt has been deleted.
The search also returns values for the Cluster size, Compression Unit Size, Allocated size of the attribute, Real size of the attribute, and Data Runs attributes. Make a note of these values – you’ll need them for stage 2 of the recovery process.
2. Defining disk clusters
Next, you need to rescan the drive, going through all the file clusters until you identify the file size that is equal to the selected clusters. The NTFS file system assigns each file a _DATA_ attribute that defines “data runs”, which in turn point to the location of the file clusters that need to be recovered.
Before proceeding, you will need to decrypt the data runs. Consider the following snippet from the hex editor:
This is where things become more complicated:
- The first byte (0x31) shows how many bytes are allocated for the length of the data run, 0x1 in this example, and the first cluster offset – 0x3.
- The next byte – 0x6E – shows the length of the data run.
- The following three bytes indicate the start cluster offset – 0xEBC404.
- By changing the bytes order, we discover that the first cluster is 312555 (or 0x04C4EB in hex).
- By applying the length of the data run identified above, we know that the next 110 clusters (0x6E) contain our PowerPoint presentation.
We know this is correct because the next byte is 0x00, indicating that no further data runs exist.
Recovering the cluster chains
With the cluster chain identified, the last task is to copy the “deleted” data back to your other hard drive. Using the first cluster address identified in step 2 (312555), you then copy the 110 clusters that follow it – but first you need to calculate the offset of the first cluster.
You do this my multiplying the cluster size (512) by the First cluster address like so:
512 * 31255 = 160028160
This value then needs to be converted into hex, giving you the offset that marks the start of your missing data = 0x0989D600
By copying the next 110 clusters (512*110 = 56320 bytes) to your second drive, you will have successfully recovered the “deleted” file from your NTFS partition.
Is it worth it?
Although possible, it is obvious that recovering data in this way is very time consuming, and can potentially cause further data loss. As previously mentioned, there are many combinations and permutations that can affect the success or failure of a data recovery. This post, again, is only intended for educational purposes.
If you’d like to see more technical content about how data is stored and recovered then please let us know via Twitter: @OntrackUKIE.
Image credits: NTFS.com