當Filesysem Index (如NTFS的MFT, NTFS FAT表)損壞時，就算使用資料恢復軟體也無法重建檔案系統檔案跟目錄名稱. 這時只能用File Carving (Raw Recovery) ，從原始扇區hex的原始hex中“雕刻”出某些檔的“形狀”。所以這狀況會需要從整個硬碟0扇區跑到跑到底.會很耗時間
File Carving技術就是基於檔案結構特徵和內容特點的，“架構”出檔案來。
一、什麼時候需要做File Carving?
例如遇到整個分區被誤格掉然後又有其他資料複蓋掉原本的分區的索引Data，用一般的救援軟體是無法回復的 也沒有原有的文件名稱。
此時就必須利用碎片搜索文件雕刻的方式慢慢的將想要的文件重組回來。
但重組回來也不見得是完整的檔案，必要時仍然必須將檔案處理過後才可使用。
但對影音檔而言，經常遇到即使在無覆蓋風險的情況下，恢復出來的視頻也是不完整的。原因在於傳統的資料恢復技術通過系統資訊進行的資料恢復不具有資料偵測能力，一旦資訊不完整，即使資料仍保留在數位設備中，也無法恢復。沒有了可依賴的系統資訊，我們唯一可以做的就是利用影音檔的結構特徵和內容特點,在“無差別”的資料區中偵測每個“未分配”的資料簇，判斷它們是不是我們期望得到的視頻碎片資料。在一個忽視系統資訊的環境中,如何偵測到每個影音檔碎片,並將它們有序銜接起來,並非本文研究的重點。這有許多工具可以做到。
本文要探討的是屬於資料重建中很難處理的視訊檔重建。而在過程當中最常碰到的問題就是MOV檔的重建，也是本文所要討論的重點。
二、常用工具R-Studio是怎麼做的?
很多專業資料恢復公司使使用R-Studio這套軟體來做數據恢復。所以我們先來看看R-Studio怎麼做的。
實際上在救援的經驗當中發現R-Studio對於碎片搜索檔案重建的結果很不理想。
根據R-Studio的說明書中的Customizing File Type一節中，使用者可以自訂檔案的特徵值，請參考這是下載說明書看。
更詳細的說明書可至http://www.r-tt.com/zhhk/TechnicalSupport.shtml 下載。
我們以MP4檔案為例，檔案是 https://support.apple.com/en-us/HT201549 中的sample_mpeg4.mp4，下載後用Winhex打開。後可以看到MP4的特徵值。
在檔頭的部分可以看到ftypmp42及mp42mp41。連續性的值(16進位)是
00 00 00 18 66 74 79 70 6D 70 34 32 00 00 00 01 6D 70 34 32 6D 70 34 31
所以這個mp4檔案的特徵值是可以寫成底下的方式以供R-Studio搜尋時使用。
\x00\x00\x00\x18ftypmp42\x00\x00\x00\x001mp42mp41
當然，MP4檔案的特徵值已直接被R-Studio所支援，使用者不需另外創立。當然R-Studio也有內建MOV的特徵值，但為什麼MOV檔案重建後的結果很不理想呢？我們推測是可能檔案重建時只有做Raw Data特徵值的比對，所以當特徵值某些部分被蓋掉後就有很大的機率判斷不出來或是誤判。為什麼會發生這樣的情況了，其實這跟MOV檔的特徵值有關。所以要做MOV檔案的檔案重建呢就必須先了解MOV檔的檔案結構。
三、MOV的特徵值
我們先來觀察一下正確的MOV長什麼樣子，下載 Apple官方的Sample mov。
用Hex軟體打開後可以看到如下的檔案資訊。
MOV檔案有幾個重要的Atom，Atom是QuickTime檔案的基本數據單位，每個Atom包含了大小跟類型以及之後的數據部分。Atom主要格式有wide、mdat、moov等。MOV檔在檔頭是由一些連續性的組塊(Chunk)所組合而成，每一個組塊是8個Byte：前面4個Byte代表組塊的大小，後面4個Byte代表組塊的類型。
現在跟大家介紹一下MOV檔頭是根據ISO制定而成，各有其意義。首先看到
offset 0~3分別是00_00_00_20。這個代表了這個box的大小總共有32個Byte。offset 4~7分別是66_74_79_70，指出這個box的類型是ftyp。
offset 8~B分別是71_74_20_20，指出這個類型的商標是qt(QuickTime)。
offset C~F分別是20_05_03_00，指出這個商標的主要版本。
offset 10~13分別是71_74_20_20，指出這個商標的相容的商標是qt(QuickTime)。
看完了檔頭的box之後，我們來看wide atom，從這裡開始即完全要遵照Qucik Time File Format所定義的來做。
offset 20~23分別是00_00_00_08，代表了這個atom的大小總共有8個Byte。
offset24~27分別是66_74_79_70，指出這個atom的類型是wide。
在wide atom之後是另一個atom。wide atom 是表示後面是個擴展的atom，後面接的是mdat atom，也是資料主要的地方。
offset 28~2B分別是00_31_CA_34，代表了這個atom的大小總共有3263028個Byte。
offset2C~2F分別是6D_64_61_74，指出這個atom的類型是mdat。
那mdat atom的結尾在哪呢？來計算一下
0x27+0x31CA34=0x31CA5B
mdat atom之後就是moov atom，moov atom由0x31CA5C開始。
offset 0x31CA5C ~0x31CA5F分別是00_00_52_C5，代表了這個atom的大小總共有21189個Byte。
offset 0x31CA60 ~0x31CA63分別是6D_6F_6F_76，，指出這個atom的類型是moov。
在這邊看到moov atom後面還有一個子結點mvhd atom。mvhd是moov的檔頭。
offset 0x31CA64 ~0x31CA67分別是00_00_00_6C，代表了這個atom的大小總共有108個Byte。
offset 0x31CA68 ~0x31CA6B分別是6D_76_68_64，，指出這個atom的類型是mvhd。
現在可以來驗證一下檔案長度是否正確，0x31CA5B+moov atom的長度
0x31CA5B+0x52C5=0x311D20。跟截圖的值是吻合的代表沒有算錯。
由此可知，除了檔頭之外atom的資料也不能有錯誤，這樣才能正確的救回MOV檔案。但假如原始的資料被破壞太多的時候就會有資料不全的問題產生，導致救回的MOV檔案格式是錯的。
四、案例分析
67072.mov是一個用R-Studio救回來的MOV檔，發現無法預覽畫面用VLC撥放器也無法播放。用Winhex打開後觀察MOV的特徵值會發現重建後的資料是錯的，軟體將原本應該是檔案尾的moov資料寫到檔頭來了，造成播放器無法播放此檔案。
將多餘的檔頭砍掉後即可發現已可播放幾秒鐘的畫面，此時檔案雖然已經可以預覽了但仍然不是正確的MOV檔，原因是少了後面的moov資訊。這時要將moov資料重建，重建moov資料後即可正常播放影像。
為何檔案可以預覽這麼重要呢？因為當用Raw Data Recovery一次拉出來可能會有幾萬個檔案，這時確認是否是重要的資料的程序就很重要，利用此方法可以先預覽畫面確認檔案的重要性之後，再去維修檔案。
