NTFS General Information
> NTFS Recovery Concepts > File Recovery Concepts > Defining clusters chain
Defining 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@ UNERASER.
Example of defining clusters chain on FAT16
Lets continue to examine an example for deleted file MyFile.txt from the previous topic.
The folder, we scanned before contains a record for this file:
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 fine in our case - it means that these clusters are not occupied, i.e. most likely our file has not been overwritten by other file's data. Now we have chain of clusters 03, 04, 05, 06 and we are 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 might not be true.
There are a lot of cases where the file's data cannot be successfully recovered, because clusters chain cannot be defined. Most of them occur when you write another data (files, folders) on the same drive where deleted file is located.
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.
Previous| NTFS Recovery Concepts | Next