Manual positioning files from NTFS file system
|
Manual positioning files from NTFS file system
I believe many of my friends in the books carefully read data recovery on NTFS file system after about a series of attributes, more or less confused some norm. Indeed, NTFS file system structure is more complex, and the book has not talked about how to use these properties to locate the file, which is for beginners, is undoubtedly a shortcoming.
Now on to a place called "MFT structural analysis" to manually locate the image file, which is stored path is E: \ tutorial \ data recovery.
Next we went to locate the file layer by layer on the property have learned to do a mastery Maybe some friends will say: In practice, you can search for files by name in the MFT way to make the location, so is also possible. I made the original intention of the analysis is to understand for beginners NTFS offers an idea.
Learned the FAT file system, must know how to locate partitions and DBR, Well, we started directly from the DBR
 From the results DBR, the number of sectors per cluster as 08H, ($ MFT bit short MFT) MFT start cluster as:. 00000C00H, were converted to hexadecimal 8-sector and 786,432 clusters. Now jump to 786,432 clusters, as shown below:
 We can see that this is the first MFT record, the record is its own. , Then we jump to the root directory on the MFT record, which is No. 5 records. Generally the root folder stored files and more. Therefore, it is non-resident, the information about these folders recorded in the other positions. In what position is recorded by the index assign attributes to record, that is A0 property, then focused look A0 properties, as shown:
 Positions marked in red on the map is running ( Data run) 31H represented by three bytes describe the position of the index starting LCN (3E9002H), a description of the length byte (02H). A description of where the next run is 00H indicates this end, there is only one run. (Hint: if the next run by the content, then it describes LCN LCN described before with a run is its real LCN, if the three runs, with the third run of the first two LCN LCN plus LCN is the real third run, and so on!)
We will convert it to decimal values to get such a message, the starting position for the 167,998 cluster index entries, multiplied by the number of sectors per cluster 8, equal to 1,343,984 sectors, the length of two clusters, jump to 1,343,984 sectors , as shown:
 This location is the root of index entries, you can see inside the index file called metadata. "Tutorial" This folder is also stored in the root directory of the inside, we search for the file name to find the corresponding index entry, because NTFS is the file name inside Unincode characters to represent, so the file name is converted to a hexadecimal value To 59650B7A8765H, we search the index entries in the root directory of the file name:
 In 1343994 sectors to find a "tutorial" index entry, (1343994-1343984 = 10, the number of sectors per cluster 8, indicating that the index entry is stored in the second sub-clusters inside) can be seen from the figure, its file record store In No. 6B3500H sector, converted to hexadecimal number 13675 for the record, an MFT occupies two sectors, start their documentation for the number of sectors down 27,350 from the first MFT record numbers on its file record storage location, is calculated as: 6,291,456 + (13675 * 2) = 6318806, jump to 6,318,806 sectors, as shown:
 This figure describes exactly what we're looking for MFT number, see the following run 31011BEB01H, converted to hexadecimal value is: 125,723, multiplied by the number of sectors per cluster 8 equals 1,005,784 sectors, now jump to 1,005,784 Area search for "data recovery" hexadecimal value this folder 70656E6362600D59H, the results did not find this folder is it not recorded? Impossible. Suspect, will be a resident. MFT stored inside SKIP 6318806 sector search 70656E6362600D59, the second sector of the MFT record found inside the folder.
 Jump to file "data recovery" MFT file record number: 23A100000000H, decimal number 41251 multiplied by two plus 6,291,456, equal to 6,373,958. Figure:
 On NTFS somewhat understand people will find that this is not the MFT. Why? I look at the distribution of the MFT, as shown:
  |
My MFT is divided into three blocks to store, and (my own name) then calculate:
The first one: MFT from 786432 clusters begin to 796,687 by the end of the 10,255 clusters = 82040 sectors, each two sectors for a complete MFT.
The second block: MFT from start to finish 397 686 397 607, 632 with the 79 clusters
The third block: ......
The first piece of MFT only used 10,255 cluster to record, (I used to, but the cluster is calculated) and we are looking for the file "data recovery" is stored in No. 41251, (41251 * 2/8 = 10,312.75 cluster) has been exceeded the recording range of the first block beyond 75.75 clusters calculated, which is stored in the second block "data recovery" MFT. Start position of the second block is 397,607 clusters, with 75 clusters, equal to 397,664 clusters, due to record data from the hard disk is zero, so this place should have to subtract 1. Jump to three-quarters of the cluster 397 663 (0.75) position, which is the first sector 6
 According run, that its starting LCN is A08AH (35488 * 8 = 283904), occupies a cluster. Jump to 283,904 Sector: Search for a file name "MFT" Structural Analysis 4D0046005400D37E7E00H
 Its file number is MFT 26A1H (record No. 41254), based on the calculated front MFT record block, "Data Recovery" MFT record number down three records that "MFT Structure" MFT record of the file. Go to this location
 Jump to 294,016, ending a selected sector
 Edit "MFT structural analysis jpg." to save the file named - - Copy - implantation of the new file. Double-click can open properly.
|