In my last installment I described what a file entry record would look like if it were in fact a cluster holding file entry data. I went over the fact that the first two entries of the folder cluster would be a period followed by ten spaces, and the next entry would be two periods followed by 9 spaces. This data may seem innocuous, however they do have meaning and can help us in determining how the folders are related to each other.
The file entry record has several components that are used to extract the related stored data. One of these components is the starting cluster number of where the data might be found. Logic is then used to with the File Allocation Table (FAT) map to chain the clusters together. Lets say for instance that the starting storage cluster for file “foobar” is 1000h. Lets also say that the size of a cluster is 64k. Finally, lets assume, for illustration purposes that the file is 640k. With these facts in hand we can say that foobar will occupy ten clusters. If the file had been saved only once and not edited we can make a pretty educated guess that the file is not fragmented. So the following statement may be true “Foobar is stored in clusters 1000h – 1009h”.
The FAT would look like this
| 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 | 1009 |
| 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 | 1009 | 0FFF |
The top table shows the actual cluster number 1000h -1009h. The bottom table shows the value in each one of the FAT cells. The value in the FAT cell points to the next cluster, which in turn points to the next cluster so on and so forth. Finally the final FAT cell has the value 0FFFh which indicates the end of the cluster chain. This method is called a “one way linked list” as it links the clusters forward only, and not reverse.
Now, this is a FAT representation of a file that is not fragmented. The following set of tables for the same file, but this time the file is fragmented.
| 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 | 1009 | 100A | 100B | 100C | 100D | 100E | 100F |
| 1001 | 1002 | 1003 | 1004 | 100B | 0000 | 0000 | 0000 | 0000 | 0000 | 0000 | 100C | 100D | 100E | 100F | 0FFF |
Now, as you can see from the above table the cluster chain looks basically the same until we get to cell 1004h. Instead of the cell containing the value 1005 which would of course point to the next cell, it has the value 100B. This means to look at cell 100B to see if we are at the end of our chain, or if we in fact continue the chain. In our example we see that the chain does continue until it reaches the end of the linked-list in cell number 100F. This is an example of a fragmented file as it is divided into two fragments. The first fragment is from cell 1000 to 1004, and the second fragment is from cell 100B to cell 100F.
With all of this being said one can see how important it is to keep the FAT cluster map intact. When a drive is formatted for FAT the entire FAT table is destroyed and zeroed out. In the above fragmented file we can see that with the FAT destroyed there is no way to easily recover the data. The simple logic of a FAT recovery is to get the starting cluster from the File Entry record as well as the file size and then read each cluster contiguously until the file size is satisfied. In other words to recover foobarwe would read cluster 1000h since that is the starting cluster and continue for ten clusters since the size of each cluster is 64k and the file size is 640k. Doing this will lead us to cluster 1009h. Looking at our two examples we can see that in the unfragmented file we would get all of the data, however, in the fragmented file we would only get the first five clusters and the rest would be zeroes or garbage.
I have made several references to the starting cluster number which is found in the File Entry record and then used with the FAT to get all the data for a particular file. In my next installment I will explain the mechanincs of getting the starting cluster from the File Entry record. Until next time…
Related Articles:
- Part 1 Recovering FAT 32 With File Entry Data
- Part 2 Recovering FAT 32 With File System Markers
- Part 3 FAT32 Recover File Entry Table On-Disk Layout Using a C Structure
- Part 4Using FAT32 File Entry Record For Recovering Folders Using Software Logic
- Freeware Data Recovery
- Hard Drive Recovery
Find the root directory using “COMMAND” every 32 bytes. hehe, easy. Another way is to look for a “Volume” entry along with valid-looking file and folder entries.
Find partitions using many ways: One is to find the root directory, then work your way back. This at least gives you a count of the number of probable partitions, and gives a good estimate of starting/ending sectors.
2nd way: Finding the “FF…F8” or such signatures followed by bytes that mostly grow in sequence/are zero indicates the first and second FAT’s starting positions. Do a little subtraction to find out the number of clusters, among other things.
Wow, this is all so 1989. FAT32 came in the 90s, and then there came NTFS. NTFS is an entirely different ballgame. You have to know all kinds of tricks that make automated tools a life saver.
Oops didn’t see that this was a multipart article. I imagine that you covered most of that.