對 MFT偏移 的修正 ---親歷一次數(shù)據(jù)修復
前陣子，我在一次正常開機后，打開QQ空間，突然系統(tǒng)死機。點擊鼠標無反應，按鍵ctrl+alt+del想殺進程確無反應，于是只好按主機reset鍵強制重啟，結(jié)果RP爆發(fā)，百年一遇…
重啟后，無法進XP系統(tǒng)，用PE光盤進，發(fā)現(xiàn)C盤和E盤都提示“文件或目錄損壞且無法讀取”，于是用ptdd重建mbr，仍進不了系統(tǒng)。重啟又進入PE，發(fā)現(xiàn)此250G的5個分區(qū)的硬盤中，E盤反而可以正常讀取了，其他分區(qū)出現(xiàn)上面那個提示。用PTDD重建分區(qū)表，沒解決。 后來在網(wǎng)上搜過“文件或目錄損壞且無法讀取”的解決方法，最多提到的是chkdsk /f, 但是在PE里，提示無法識別ntfs。于是只好把硬盤掛載到室友的電腦里，用chkdsk /f修復，修復后我在Xp雙擊這些分區(qū)，原來的C盤，F(xiàn)盤G盤依舊無法進入，還是那個錯誤提示。而D盤可以了。后來掛載到我電腦另一個硬盤的linux里，竟然能進F和G盤，里面有FOUND.000這類文件夾，在里面找到了不少修復回來的文件，隨機在不同目錄點了幾個都能用。
于是接下來要解決的問題有：
1.同樣全部是ntfs系統(tǒng)，為什么XP無法讀取F和G分區(qū)，而linux可以？（雖然不可以在windows里讀取，但至少在linux下可以把數(shù)據(jù)導出備份，成功了一點點）
2.如果從數(shù)據(jù)修復的角度看，現(xiàn)在只剩下C分區(qū)了。頭疼… PTDD，DISKGEN，還有用過一些磁盤錯誤掃描，都檢查不出什么錯誤。（這里明顯我是病急亂投醫(yī)…）
本著不修復好不罷休的精神吧，雖然C分區(qū)的數(shù)據(jù)真的沒有了也不至于損失多慘重，可恰好我可以在另一個硬盤linux里的虛擬機里的XP上網(wǎng)，所以也不需要急用電腦而不得不重裝系統(tǒng)。（雙系統(tǒng)的好處之一 o(∩_∩)o ）之后是上網(wǎng)找
專業(yè)論壇，搜索期刊。順便做下廣告，我覺得中國硬盤基地技術(shù)論壇不錯。我也是第一次從這里知道可以用winhex修復數(shù)據(jù)。并且也通過搜索得知我的故障可能是MFT有錯。在里面看過一句話，“你要是不會手動16進制寫mft，不知道他的規(guī)則，計算方式。就別費勁了，你從現(xiàn)在學，學3個月有可能能學會”。天啊，估計我沒這耐性，更主要是我還有不少事情做…不過我試著去了解吧，趁機能懂點東西也不錯。于是，從一開始不懂mft，然后慢慢的去了解ntfs的文件系統(tǒng)…其實一共也不需花多少時間，中間快20天都忙著考試和找工。這里還有個小插曲，因為看過這方面的書，那時候印象較深，還去筆試面試了一個數(shù)據(jù)修復公司，吹吹自己會用winhex和其他修復軟件，通過了。說1月中旬給個回復去不去，去的話開始實習了，不過待遇感覺太低所以不想了的。畢竟生活壓力吧，還有綜合考慮興趣與待遇，還有發(fā)展。
說點硬盤ntfs文件系統(tǒng)的，或許很多人也聽過了。之前我沒怎么了解，后來借此機會也趁機學學了。硬盤由引導扇區(qū)（Boot Sector）與各分區(qū)組成。不超過四個主分區(qū)，原因是主引導記錄（MBR）里的分區(qū)表里只有64字節(jié)，一共只可描述4個分區(qū)表項，從winhex里看，描述一個分區(qū)表項用16字節(jié)。有人可以分七八個分區(qū)是因為用到擴展分區(qū)，現(xiàn)在我們的普遍分法是一個主分區(qū)+一個擴展分區(qū)，然后擴展分區(qū)又是由相應的EBR（即擴展MBR）里的分區(qū)表來描述。
一個以Ｃ盤為主分區(qū)，ＤＥＦ為擴展分區(qū)的硬盤數(shù)據(jù)結(jié)構(gòu)如下所示：
關(guān)于主引導記錄MBR。一般都占用63個扇區(qū)，即從第0-62扇區(qū)（這里有個例外，虛擬機里我看過只有56個扇區(qū)），而實際有寫入內(nèi)容的一般只有一個扇區(qū)，及常說的0柱面0磁道1扇區(qū)。1個扇區(qū)512字節(jié)，MBR其實分三部分，1.引導代碼446節(jié) 2.分區(qū)表64字節(jié) 3.結(jié)束標記55AA，及2個字節(jié)。
如果，兩藍色豎線把第一個扇區(qū)劃分為三部分，及上述的MBR三部分。兩藍豎線間為分區(qū)表。每16字節(jié)為一個分區(qū)表項，兩個緊挨著的數(shù)字為一個字節(jié)。
第一個分區(qū)中：第一個紅色框內(nèi)80代表活動分區(qū)。綠色框01 01 00代表磁頭號、扇區(qū)號、柱面號。第一個藍色框07代表NTFS分區(qū)。緊接著三條綠橫線，分別是本分區(qū)結(jié)束磁頭號、扇區(qū)號、柱面號，然后是本分區(qū)之前已用的扇區(qū)數(shù)（3F000000，必須倒過來，即0000003F，轉(zhuǎn)為10進制63，即MBR要占用63扇區(qū)，注意MBR是不屬于磁盤第一個分區(qū)!），最后是本分區(qū)的總扇區(qū)數(shù)（E5588101,倒過來，018158E5,即是25254117個扇區(qū)，25254117*512/1024/1024/1024=12.04G）
第二個分區(qū)：第二個紅色框00表示非活動區(qū)。綠色框00 C1 FF代表磁頭號、扇區(qū)號、柱面號。第二個藍色框0F代表擴展分區(qū)。三條綠線所表達的也與上面相同。（注意這里的第二個分區(qū)代表擴展分區(qū)，切勿與通常的D盤相混淆?。。。?br>因無其他主分區(qū)，所以第三、第四個分區(qū)表項為0。
最后以55AA結(jié)尾，代表MBR結(jié)束。
到這里，給道題目，如何知道D盤的EBR在哪里？
很簡單，從第一個分區(qū)表項得知，第一個分區(qū)有25254117個扇區(qū)，而在第一個分區(qū)前的MBR有63個扇區(qū)，因為整個硬盤扇區(qū)數(shù)從0記起，所以MBR扇區(qū)數(shù)+第一個分區(qū)扇區(qū)數(shù)=63+25254117=25254180，即通過轉(zhuǎn)到25254180扇區(qū)即可。這里就是D盤前面的EBR了。
對紅線進行分析（紅線前面446個字節(jié)，因為是擴展分區(qū)，不需要啟動代碼，用0填充）：
00：非活動分區(qū)
01 C1 FF 起始磁頭號、扇區(qū)號、柱面號
07：NTFS分區(qū)
FE FF FF:本分區(qū)結(jié)束磁頭號、扇區(qū)號、柱面號。其實可以發(fā)現(xiàn)，實際不需要理會這一項，所有分區(qū)表項都用這三個字節(jié)來表示本分區(qū)結(jié)束磁頭、扇區(qū)和柱面的。
3F 00 00 00：如前面分析MBR，倒過來是00 00 00 3F ，即63個扇區(qū)。
8D 0D 23 03:倒過來是03 23 0D 8D,轉(zhuǎn)為10進制是52628877，即本分區(qū)有52628877扇區(qū)，25.09G。
為計算第二個EBR在哪里只需將前面的“MBR扇區(qū)數(shù)+第一個分區(qū)扇區(qū)數(shù)”+“EBR扇區(qū)數(shù)+第二個分區(qū)扇區(qū)數(shù)”
………
略去對后面幾個分區(qū)的計算。
剛剛是對MBR，EBR（EBR實際與MBR類似，只是少了啟動代碼）的分析，現(xiàn)在對具體分區(qū)分析（以修復好的C盤為例）。
通過翻閱資料得知，NTFS文件系統(tǒng)的結(jié)構(gòu)是
如何進入具體分區(qū)呢？選擇winhex里的“工具—打開磁盤”，選中相應物理磁盤即可打開。我的硬盤（修復好后）顯示如下：
雙擊想要看的分區(qū)即可，如partition 1,進入…
會看到很多此分區(qū)的文件，甚至包括一些即使你在文件夾選項里勾選“顯示隱藏文件”都無法看到的文件。比如以$開頭的文件。每個NTFS分區(qū)中都有這種文件，如下：
注意：MFT里的11到15號記錄是為以后的元數(shù)據(jù)文件保留的。
以上是的截圖來自網(wǎng)上，補充下$Boot 、$MFT 、$MFTMirr的一些資料，因為此次修復與這幾個有關(guān)。
$Boot:NTFS的卷啟動扇區(qū)，也叫分區(qū)啟動扇區(qū)，卷啟動記錄等。雖叫扇區(qū)，其實包含了16個磁盤扇區(qū)（8KB），即你看到的$Boot文件大小是8KB。在winhex里雙擊相應的分區(qū)后，進去看到的該分區(qū)的第一個扇區(qū)就是$Boot所占的第一個分區(qū)。包含了BIOS參數(shù)塊（BIOS Parameter Bloce，即BPB）和卷啟動代碼。BPB里包含此分區(qū)基本信息，如分區(qū)格式，大小等。至于卷啟動代碼，是表示如何裝載WIN NT，2000等系統(tǒng)的NTLDR，把控制權(quán)交給它，得以繼續(xù)裝載系統(tǒng)其他部分。
對于$Boot里的BPB用以下的截圖說明下，彩色部分就是BPB，
對于$MFT文件，就是從BPB里定位的?。?！這句話很重要。
而我自己C盤的情況是
對比這里的說明：
圖中第一條藍色粗線是表示$MFT第一簇簇號，00 00 0C 00 00 00 00 00 ,倒過來是00000000000C0000，即16進制C0000轉(zhuǎn)為10進制是786432，表示MFT在第786432簇（注意這里表示的是相對于本分區(qū)的簇數(shù)，而不是整個硬盤）。接下來，轉(zhuǎn)去786432簇，看看是不是
通過Go To Sector到786432，與單擊$MFT去到的扇區(qū)都是一樣的。說明定位沒錯。
接下來看下$MFT吧…
$MFT：（Master File Table）文件。主文件列表。此文件是NTFS分區(qū)中最重要的文件，記錄了分區(qū)中所有文件（包括$MFT自身）的基本信息。通過$MFT就可以訪問分區(qū)中的所有文件和系統(tǒng)數(shù)據(jù)。$MFT由多個MFT記錄單元組成，每一個文件的描述占用一到多個（一個不夠的情況下）$MFT記錄單元。其中前十二個記錄單元中記錄著這里的十二個系統(tǒng)文件的信息。每個記錄單元記錄著文件的建立時間、在分區(qū)中的位置、長度、屬性、文件名等信息。
MFT中的第一個記錄就是$MFT自身，編號為0。每個文件記錄占用1KB，即兩個扇區(qū)。
識別一項MFT的起始很簡單，看開頭的4個字節(jié)是否46 49 4C 45 ，其相應的ASCII碼是FILE?，F(xiàn)在就看MFT怎樣記錄其本身$MFT吧。
同理，MFT的鏡像$MFTMirr用同樣的方法也可以計算得出和定位，$MFTMirr是對MFT里的重要文件備份，只有4K，即備份了4個文件記錄單元而已。
其實說了上面這些，還沒涉及到故障的解決，有人會說，明明可以在winhex里選中$MFT就定位了，為何這般復雜，實際上，我此次故障，就是遇到MFT偏移了！
說了前面這么多，只是為NTFS文件系統(tǒng)結(jié)構(gòu)做個很大概的描述，實際上真的很復雜。
在故障處理前，我雙擊C盤出現(xiàn)了這種情況：
看來問題跟這個MFT是有些關(guān)系了的…進去后，傻眼了，沒有其他的文件，只有以下這幾個，郁悶。
方法一：用前面的方法，從分區(qū)引導扇區(qū)計算出MFT位置。所以，證明前面說的不算是廢話。
方法二：留意提示，看到了offset C0000000 和 offset 18158E000 字樣，那就過去看看吧。 發(fā)現(xiàn)C0000000里，不是一項文件記錄的起始，文件記錄的其實，一定是“46 49 4C 45”開頭的，仔細找下，很明顯偏移兩行了?。?！這就是故障所在。MFT里的第一項文件記錄正是MFT本身，而現(xiàn)在本身位置都記錄錯了，如何定位其余文件呢？所以，此分區(qū)下的所有文件不可見！接下來嘗試修復了。至于另外一個18158E000，其實可以猜測到是$MFTMirr的…
其實我曾經(jīng)想過找相關(guān)MFT的修復軟件試下，但始終覺得會否因軟件“誤判”，反而搞亂了。
畢竟對于數(shù)據(jù)修復，一般是“只需一次成功，不許多次失敗的”。還是手動吧…
其實到這里我已經(jīng)找到了故障所在，和處理方法了，只是即使想手動也有點下不了手…期間在學校某個地方做過一次實驗，也是一件壞事…呃，把它的某個分區(qū)，用winhex寫0了…寫0了是什么概念應該猜到吧。不過也自私慶幸幸好不是在自己的硬盤這樣操作！這款軟件是有一定危險性的。
拿修復$MFTMirr舉例吧…$MFT的我忘了截圖。找到18158E000的那個扇區(qū)里（可以看到偏移了三行）…選中46 49 4C 45開頭的一段數(shù)據(jù)，多大好呢，我是一直選到非0的末尾，后面全0的就不選了。原因：記錄一個文件其實有時候不需要用到1KB的。
粘貼到正確位置…
就這樣，手工的找，手工的修復，看到就修復，反正間隔1KB就一個記錄…所幸不是很多，10來個而已。
保存退出，重啟…以為應該好了，默默的等待一種喜悅。結(jié)果啟動不了。沒辦法，只好到另一個硬盤的linux里進去看，久違的那個分區(qū)是出現(xiàn)了，可是掛載不了，如圖提示：
有點郁悶，現(xiàn)在只好把硬盤掛到室友的XP下去chkdsk下了，懶了，不想再研究了。
結(jié)果，在室友那里chkdsk修復后，把硬盤掛回自己電腦，啟動，見到了久違的XP和久違的桌面?。?！我成功了！?。∫苍S對于牛人來說，這不算什么，但是畢竟對于我，因為是通過自己努力去嘗試的，所以，有點成就感吧。
寫到這里基本完了...不過仍然有我不明白的地方，文中可能有些表述不當，還請指正下的，比較僅僅一個文件系統(tǒng)，還只是NTFS，都夠研究很長時間了。我現(xiàn)在存在的疑問是：
1.為什么有兩個分區(qū)F和G，是NTFS的，在linux下可以是識別并正常讀取里面的文件，但是在windows XP里不行。這是我至今還未解決的疑問。
2.在我用winhex修復并重啟后，雖然在ＸＰ和linux下讀取不了，但是在winhex里是可以看到完整的文件的，并且沒有found.000這個文件夾，如果我此時導出文件，相信文件位置不會出現(xiàn)錯亂。但是用chkdsk掃描修復后，為什么多出這么多零碎的文件放進found.000里了...
此次事件的總結(jié)：
1.一開始嘗試修復時，重建MBR，重建分區(qū)表，都是很傻的做法。當時病急亂投醫(yī)...當硬盤出現(xiàn)誤操作而又想盡力恢復數(shù)據(jù)時，切忌再往里頭寫數(shù)據(jù)，最好是先把硬盤拆下來，再到網(wǎng)上，或相關(guān)書本查詢。
2.硬盤數(shù)據(jù)修復，一般是只許一次成功，不許多次失敗。所以，在方案的取舍，切忌一個個的試，最好有其他硬件模擬試驗。我以前曾經(jīng)誤操作而用一個XP鏡像覆蓋全盤，后來用移動硬盤試過可以用PTDD重建分區(qū)表，做過實驗了，也就有大的把握確定成功率。
3.任何事情，只要投入時間，愿意琢磨下，即使不成功，也多少有點回報的。像我在某個網(wǎng)站看到的那句話，說“你要是不會手動16進制寫mft，不知道他的規(guī)則，計算方式。就別費勁了，你從現(xiàn)在學，學3個月有可能能學會” 看到后確實有點打擊，不過其實現(xiàn)在我還沒懂多少，至少能取回數(shù)據(jù)了。
