File Recovery Process

Define clusters chain for the deleted entry

To define clusters chain we need to scan drive, going through one by one all file (NTFS) clusters or free (FAT) clusters belonging (presumably) to the file until we reach the file size equals to the total size of the selected clusters. If the file is fragmented, clusters chain will be composed of several extents in case of NTFS or we take clusters bypassing occupied ones in case of FAT.

Location of these clusters can vary depending on file system. For example, file deleted on FAT volume has its first cluster in its Root entry, the other clusters can be found in File Allocation Table. On NTFS each file has _DATA_ attribute that describes "data runs". Disassembling data runs to "extents" for each extent we have start cluster offset and number of clusters in extent, so enumerating extents, we can compose file's cluster chain.

You can try to define clusters chain manually, using low-level disk editors, however it's much simpler to use data recovery tools, like Active@ UNDELETE.

Example of defining clusters chain on FAT16

Lets continue examine an example for deleted file MyFile.txt from the previous topic.

The folder, we scanned before contains a record for this file:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
------------------------------------------------------------------------------
0003EE60   E5 4D 00 79 00 46 00 69  00 6C 00 0F 00 BA 65 00   aM.y.F.i.l...?e.
0003EE70   2E 00 74 00 78 00 74 00  00 00 00 00 FF FF FF FF   ..t.x.t.....yyyy
0003EE80   E5 59 46 49 4C 45 20 20  54 58 54 20 00 C3 D6 93   aYFILE  TXT .AO“
0003EE90   56 2B 56 2B 00 00 EE 93  56 2B 03 00 33 B7 01 00   V+V+..i“V+..3·..   

We can calculate size of the deleted file based on root entry structure. Last four bytes are 33 B7 01 00 and converting them to decimal value (changing bytes order), we get 112435 bytes. Previous 2 bytes (03 00) are the number of the first cluster of the deleted file. Repeating for them the conversion operation, we get number 03 - this is the start cluster of the file.

What we can see in the File Allocation Table at this moment?

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
------------------------------------------------------------------------------
00000200   F8 FF FF FF FF FF 00 00  00 00 00 00 00 00 08 00   oyyyyy..........
00000210   09 00 0A 00 0B 00 0C 00  0D 00 FF FF 00 00 00 00   ..........yy....
00000220   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Zeros! And it is good in our case - it means that these clusters are free, i.e. most likely our file was not overwritten by other file's data. Now we have chain of clusters 3, 4, 5, 6 and ready to recover it.

Some explanations:

• we started looking from offset 6 because each cluster entry in FAT16 takes 2 bytes, our file starts from 3rd cluster, i.e. 3*2=6.
• we considered 4 clusters because cluster size on our drive is 32 Kb, our file size is 112, 435 bytes, i.e. 3clusters*32Kb = 96Kb plus a little bit more.
• we assumed that this file was not fragmented, i.e. all clusters were located consequently. We need 4 clusters, we found 4 free consecutive clusters, so this assumption sounds reasonable, although in real life it may be not true.

Example of defining clusters chain on NTFS

When recovering on NTFS part of DATA attribute called Data Runs give us location about file clusters. In most cases DATA attribute is stored inside MFT record, so if we found MFT record for the deleted file, most likely we'll be able to determine cluster's chain.

In example below DATA attribute is marked with a green color. Data Runs inside, marked as Bold.

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
------------------------------------------------------------------------------
00012580   2E 00 70 00 70 00 74 00  80 00 00 00 48 00 00 00   ..p.p.t.€...H...
00012590   01 00 00 00 00 00 04 00  00 00 00 00 00 00 00 00   ................
000125A0   6D 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00   m.......@.......
000125B0   00 DC 00 00 00 00 00 00  00 DC 00 00 00 00 00 00   .U.......U......
000125C0   00 DC 00 00 00 00 00 00  31 6E EB C4 04 00 00 00   .U......1neA....
000125D0   FF FF FF FF 82 79 47 11  00 00 00 00 00 00 00 00   yyyy‚yG.........

Data Runs need to be decrypted. First byte (0x31) shows how many bytes are allocated for the length of the run (0x1 in our case) and for the first cluster offset (0x3 in our case). Next, we take one byte (0x6E) that points to the length of the run. Next, we pick up 3 bytes pointing to the start cluster offset (0xEBC404). Changing bytes order we get first cluster of the file 312555 (equals 0x04C4EB). Starting from this cluster we need to pick up 110 clusters (equals 0x6E). Next byte (0x00) tells us that no more data runs exist. Our file is not fragmented, so we have the only one data run.

Lets check, isn't there enough information about the file data? Cluster size is 512 bytes. We have 110 clusters, 110*512 = 56320 bytes. Our file size was defined as 56320 bytes, so we have enough information now to recover the file clusters.