數(shù)據(jù)恢復(fù)案例.doc

案例1.佳能相機EOS5D CF卡 提示格式化 恢復(fù)成功今天客戶拿來相機說 卡提示格式化 想要里面的視頻，插在電腦上一看 的確提示格式化，按著杜老師教的用Winhex打開一看MBR 還在DBR全部變成FF了搜索F8FF 只找到FAT表2 FAT1 只剩下后面部分了分析了一下FAT表2很完整并得知為FAT32文件系統(tǒng)。接著搜索2E20 到根目錄看一下 有一個名為DCIM的文件目錄項 且沒有損壞接著到3號簇和4號簇5號簇看一下都沒發(fā)現(xiàn)問題計算簇大小為64Sec , 接著計算FAT表大小 為3811Sec 利用FAT表大小得知 分區(qū)扇區(qū)總數(shù)為31219584 好了 接著從別的硬盤Copy一個FAT32 分區(qū)的DBR 分別填入以上參數(shù)簇大小64SecFAT大小3811Sec和分區(qū)大小31219548Sec保存彈出從新插拔一下 進我的電腦已經(jīng)可以打開了 數(shù)據(jù)恢復(fù)成功?？偨Y(jié)：需要對分區(qū)結(jié)構(gòu)、基礎(chǔ)知識牢固。利用winhex軟件案例2. 加1減1，數(shù)據(jù)恢復(fù)有時就是這么簡單！昨日去辦事情，偶遇一客戶。手機8GB卡由于熱插拔導(dǎo)致提示“未格式化”。找了一臺電腦下了一個WINHEX。打開U盤，發(fā)現(xiàn)分區(qū)開始位置沒有DBR，而DBR卻被向下移動了一個扇區(qū)。這個很簡單，我并沒有把DBR向上復(fù)制，而是把分區(qū)的開始扇區(qū)號加了一個“1”，把DBR里的保留扇區(qū)減去一個“1”。好了，點保存，WINHEX提示IO錯誤。最終解決了IO錯誤，彈出卡，然后再插入，分區(qū)正常打開，數(shù)據(jù)很完整。IO問題是tf卡有保護總結(jié)：靈活利用知識案例3最近流行的U盤病毒，導(dǎo)致WORD打不開的恢復(fù)方法最近接到幾個U盤.問題基本都是一樣,里面的WORD文件基本是打不開的,原本以為是什么大問題,可能想著要設(shè)計到重組碎片,價格就報了幾百元,打算不弄,后來我就隨便用WINHEX打開看了一下,發(fā)現(xiàn)文件頭的前面每6個字節(jié)都破壞.我就打開個好的WORD把前面6個字節(jié)覆蓋到壞的里面.文件就可以正常打開.我運氣還是算好，去年老遇到前面的扇區(qū)很有規(guī)律的被覆蓋。雖然這個沒有什么技術(shù)含量.希望可以對其他人有幫助?？偨Y(jié)：文件損壞，分析文件結(jié)構(gòu)損壞規(guī)律案例4實際數(shù)據(jù)恢復(fù)案例-手工修復(fù)FAT32文件系統(tǒng) 找來的一篇好文章，拿出來跟大家分享！ 今天接到一個朋友的客戶做數(shù)據(jù)恢復(fù)，原來是4個分區(qū)CDEF?？蛻粲捎谟X得C盤小，利用PQ分區(qū)大師將D盤部分區(qū)域劃分給C盤，重啟系統(tǒng)后，原C D F三個分區(qū)數(shù)據(jù)正常，E盤分區(qū)找不到。朋友用R-Studio掃描全盤，E盤數(shù)據(jù)始終找不到。 拿到盤后看到情況如下，用Winhex查看發(fā)現(xiàn)分區(qū)4只是聯(lián)想硬盤中的隱藏分區(qū)（用來還原系統(tǒng)的，不在客戶所說的四個分區(qū)中）。分區(qū) 3 文件結(jié)構(gòu)和磁盤大小都正常正常。分區(qū)2的DBR顯示大小和實際大小不一致只有80GB，所以初步判斷客戶需要的E盤應(yīng)該是和原來D盤合并成了現(xiàn)在的分區(qū)2。但如果僅僅是簡單的合并 利用R-Studio應(yīng)該可以直接掃描出來，現(xiàn)在卻沒能正常掃描到，需要進一步分析。磁盤分區(qū)分布圖 根據(jù)分區(qū)2DBR顯示大小找到實際結(jié)束位置，在194579343扇區(qū)發(fā)現(xiàn)了一個NTFS的DBR，但是這只是個孤立的DBR沒有緊接著并沒有NTLDR，可能是個備份。而且繼續(xù)向下查找，發(fā)現(xiàn)一個FAT32分區(qū)的DBR。 繼續(xù)向下分析，在194579351 位置發(fā)現(xiàn)了 NTFS INDX文件，并且向下發(fā)現(xiàn)了更多的NTFS分區(qū)信息。本來以為這只是個孤立的事件。但在向下查找過程中意外發(fā)現(xiàn)了類似 FAT表的數(shù)據(jù)，找到頭部，發(fā)現(xiàn)居然然是 一個完整FAT表，而表后是目錄項。然后對剛剛發(fā)現(xiàn)的那個 FAT32 DBR進行解析，如果把這個FAT32 DBR 當(dāng)成備份的話，剛剛看到的這個FAT應(yīng)該是FAT2。而且顯示的分區(qū)大小和到分區(qū)3之間的扇區(qū)數(shù)相等。而且從分區(qū)3開始的位置，從后向前找NTFS分區(qū)備份，也未能找到，說明丟失的E盤應(yīng)該是FAT32分區(qū)。 通過以上分析我猜測，丟失的分區(qū)正是個FAT32分區(qū)，分區(qū)DBR和 FAT1 在PQ移動過程中被覆蓋掉，現(xiàn)在盤上發(fā)現(xiàn)NTFS DBR的位置正好是原來 FAT32DBR的位置。根據(jù)這個想法，把備份FAT32 DBR 貼回，計算FAT1的實際位置，將FAT2還原到FAT1，如表 恢復(fù)后 所示。用Winehx 展開當(dāng)前恢復(fù)的分區(qū)，數(shù)據(jù)正常訪問，用工具恢復(fù)數(shù)據(jù)，恢復(fù)完成?？偨Y(jié)：1、不能盲目相信恢復(fù)工具，在文件系統(tǒng)關(guān)鍵信息丟失的情況下，恢復(fù)工具無法智能分析出文件系統(tǒng)結(jié)構(gòu)；2、使用PQ工具是一定要注意備份當(dāng)前數(shù)據(jù)；3、對文件系統(tǒng)結(jié)構(gòu)要非常熟悉。案例6硬盤在電腦上無法識別到盤符故障1硬盤檢測不到有很多問題：就先講一個很常見的問題。對新手很有用今天接到一個ST 80G的臺式機硬盤，把故障盤接到電腦上，電腦就好像死機一樣，故障盤拔了電腦有可以正常使用，原本一般我遇到這樣的問題大部份是壞道導(dǎo)致，當(dāng)然也有其他問題也會導(dǎo)致以后案列中會講到, 我用MHDD檢測沒有發(fā)現(xiàn)任何壞道，用指令看也是正常的，然后又用SPFDISK查看分區(qū)表也是正常的，后來沒有辦法，我就在DOS下用SPFDISK這個命令把分區(qū)給刪除。在插到電腦上，電腦沒有死機了。winhex打開后，分區(qū)都看不見。當(dāng)然要做的是把分區(qū)表信息填好，分區(qū)表出來以后直接用WINHEX拷數(shù)據(jù)出來就可以。如果不用WINHEX把數(shù)據(jù)拷出來。重新啟動電腦一樣會卡死。所以這個方法是很使用的。數(shù)據(jù)拷完重新分下區(qū)硬盤就可以正常使用了。案例7通過查找$MFT反推DBR位置手工構(gòu)建DBR一次手工恢復(fù)誤GHOST嚴重損壞的分區(qū)實例兩天前下午，我在淘寶店（）接到一個客戶，他介紹說他用GHOST安裝系統(tǒng)，結(jié)果安裝兩三次系統(tǒng)都不能正常啟動，然后用他原來系統(tǒng)的GHOST備份恢復(fù)，系統(tǒng)起來了，但系統(tǒng)中就只有一個C分區(qū)了，還有兩個分區(qū)D和E不見了，讓我給他恢復(fù)原來E分區(qū)中的數(shù)據(jù)。想到這種問題一般都很簡單，就是恢復(fù)一下分區(qū)表就完事了，所以也沒有先遠程看一下，就接了下來。遠程連接到客戶電腦上，打開事先讓客戶下載好的Winhex，再在Winhex中打開待恢復(fù)的硬盤，硬盤在Winhex顯示就只有一個分區(qū)。根據(jù)經(jīng)驗，這種情況在Winhex中是看不到原來的分區(qū)的，于是決定先用PTDD掃描一遍看看再說。用PTDD掃描分區(qū)信息，掃描完成后，只在硬盤的后面部分有一個原來的分區(qū)信息，大小為99.7G，這個分區(qū)可能就是原來的E分區(qū)。根據(jù)客戶的描述，原來的三個分區(qū)是C分區(qū)45G左右，D分區(qū)25G左右，E分區(qū)230G左右。顯然PTDD掃描出來的分區(qū)并不是原來的分區(qū)。但還是不死心，萬一是客戶記錯了呢？于是重建這個分區(qū)。接下來在Winhex中打開硬盤，此時在目錄瀏覽器中顯示出了剛才重建的那個分，但單擊這個分區(qū)，跳轉(zhuǎn)到它的起始扇區(qū)，結(jié)果發(fā)現(xiàn)這個扇區(qū)數(shù)據(jù)全是0，現(xiàn)在很明顯重建的這個分區(qū)并不是客戶的E分區(qū)?？磥碛密浖呙璨坏皆瓉淼姆謪^(qū)了，只得手工恢復(fù)了。通常情況下，XP在分區(qū)時會將第一個分區(qū)分為主分區(qū)，其余分區(qū)分為邏輯分區(qū)，D、E兩分區(qū)很有可能是邏輯分區(qū)，于是首先嘗試查找擴展分區(qū)表。在Winhex中打開待恢復(fù)硬盤，根據(jù)客戶所說C分區(qū)大約45G，于是從40G位置開始，設(shè)置搜索條件為512508，向下查找000055AA。通過一翻搜索，倒是搜索到一個擴展分區(qū)表，但經(jīng)查看，卻是PTDD中搜索到的那個分區(qū)，看來沒有這兩個分區(qū)的擴展分區(qū)表項。搜索擴展分區(qū)表失敗，接下來想到直接搜索DBR。搜索了一部分扇區(qū)后，想到PTDD都沒能搜出來，這兩個分區(qū)的DBR扇區(qū)應(yīng)該是已被破壞沒有了，于是停止了搜索。由于客戶要的是E分區(qū)的數(shù)據(jù)，E分區(qū)大小為230G左右，應(yīng)該是NTFS文件系統(tǒng)。由于客戶不清楚這個分區(qū)是什么文件系統(tǒng)，因此只有先按NTFS文件系統(tǒng)嘗試。是NTFS文件系統(tǒng)就一定有$MFT這個原文件（當(dāng)然前提是$MFT沒被損壞），于是去搜索這個原文件的文件名的十六進制值24004D0046005400，這次從50G位置開始向后搜索，搜索到若干個24004D0046005400后，終于在155698795扇區(qū)找到了一個$MFT的文件記錄。接下來要確認這個扇區(qū)是$MFT還是$MFTMirr的起始扇區(qū)。由于$MFTMirr只是前四個MFT項的備份，因此只要確定一下155698795扇區(qū)之后的若干個連續(xù)扇區(qū)中的MFT項是不是超過四個就能基本確定155698795扇區(qū)是$MFT的起始扇區(qū)還是$MFTMirr的起始扇區(qū)了。于是搜索NTFS文件記錄的特征字節(jié)值46494C45，結(jié)果在155698795扇區(qū)后的部分連續(xù)扇區(qū)中找到找到了二三十個MFT項，可以確定155698795扇區(qū)就是$MFT的起始扇區(qū)了，沒再往下搜索了。在這些MFT項中隨便找了幾個文件名給客戶看，確定了那就是原E分區(qū)的文件。找到了$MFT的起始扇區(qū)，接下來的工作便是確定E分區(qū)的起始扇區(qū)號了。而E分區(qū)的起始扇區(qū)號只有通過$MFT的起始簇號和簇大小扇區(qū)數(shù)去反推。首先計算簇大小。分別查看80屬性182F字節(jié)處的8個字節(jié)的值（屬性結(jié)束VCN）和282F字節(jié)值（屬性內(nèi)容分配大小）再用“屬性內(nèi)容分配大小/（屬性結(jié)束VCN+1）/512”得到簇大小扇區(qū)數(shù)為8（其實NTFS文件系統(tǒng)的簇大小一般都是8，這里只是為了確認一下）。這里對屬性結(jié)束VCN和屬性內(nèi)容分配大小這兩個值沒做記錄，只記得計算出來的簇大小扇區(qū)數(shù)了。接下來需要根據(jù)$MFT的80屬性中記錄的$MFT起始簇號和從簇大小扇區(qū)數(shù)去反推E分區(qū)的DBR位置了。查看80屬性的第一個運行，得出起始簇號為3754787（這個與常見的$MTF起始簇號786432還不一樣）。由于NTFS文件系統(tǒng)的0號簇是從DBR開始的，因此用3754787*8得到E分區(qū)的$MFT距DBR的扇區(qū)總數(shù)為30038296（3754787*830038296），再用$MFT所在扇區(qū)號155698795減去30038296得出E分區(qū)的DBR扇區(qū)應(yīng)在125660499（15569879530038296125660499）。跳轉(zhuǎn)到125660499扇區(qū)，這個扇區(qū)有數(shù)據(jù)，但顯然不是原來E分區(qū)的DBR，看來只有在這個扇區(qū)把寫一個DBR。為以防萬一，先把125660499扇區(qū)做一個備份。首先拷貝一個正常的NTFS的DBR到125660499扇區(qū)，接下來要修改的幾個參數(shù)有：簇大?。ㄇ懊嬉延嬎銥?）、隱藏扇區(qū)數(shù)（即該分區(qū)前的扇區(qū)數(shù)，就為125660499），分區(qū)大小扇區(qū)數(shù)，$MFT起始簇號（為3754787），$MFTMirr起始扇區(qū)號?，F(xiàn)在還差兩個參數(shù)：分區(qū)大小扇區(qū)數(shù)和$MFTMirr起始扇區(qū)號不知道。先查$MFTMirr起始扇區(qū)號。$MFTMirr的文件記錄項是$MFT的后面一個MFT記錄項，跳轉(zhuǎn)到155698797扇區(qū)查看該扇區(qū)中的文件記錄項，從文件名屬性（30屬性）可看到它確是$MFTMirr的文件記錄項，查看80屬性運行列表，得出它的起始簇為23979812。然后確定分區(qū)大小值。根據(jù)客戶所說E分區(qū)是最后一個分區(qū)，于是只需將后面的全部扇區(qū)全分配給E分區(qū)就行了，在這里我也沒全部分配，從目錄瀏覽器中看到有一個未分區(qū)空間起始扇區(qū)為625137282，與硬盤總扇區(qū)數(shù)相差不過數(shù)千扇區(qū)，于是便以它為E分區(qū)結(jié)束位置。則E分區(qū)大小扇區(qū)數(shù)取625137281125660499499476782。跳轉(zhuǎn)到125660499扇區(qū)，用NTFS的引導(dǎo)扇區(qū)模板修改以上參數(shù)（分區(qū)大小扇區(qū)數(shù)為499476781，一會兒在分區(qū)表中分區(qū)大小填寫為499476782）后保存，DBR就寫好了。最后要做的就是寫分區(qū)表了。分區(qū)表的三個主要參數(shù)分別為分區(qū)類型（NTFS為07），分區(qū)起始扇區(qū)號和分區(qū)大小扇區(qū)數(shù)。經(jīng)客戶同意，D分區(qū)不要了，只要把C分區(qū)和原來的E分區(qū)的分區(qū)表寫出來就好了。確定C分區(qū)和原來的E分區(qū)的起始扇區(qū)和分區(qū)大小就可以了。C分區(qū)起始已有了的，為63，大小為原E分區(qū)起始扇區(qū)12566049963125660436。E分區(qū)起始即為125660499，大小為499476782（因為DBR的備份位于分區(qū)的最后一個扇區(qū)，這個要比DBR中描述的多1）。得到這些參數(shù)后，把兩個分區(qū)表寫上就行了。跳轉(zhuǎn)到63扇區(qū)，修改C分區(qū)DBR中的分區(qū)大小值為125660435（C分區(qū)也是NTFS格式，因此這個值比分區(qū)表中描述的少1）。最后，跳轉(zhuǎn)到125660499扇區(qū)，將該扇區(qū)中的DBR數(shù)據(jù)拷貝下來寫到625137281扇區(qū)做一個DBR備份。修復(fù)到此就結(jié)束了。在Winhex關(guān)閉硬盤，重新打開硬盤，分別打開兩個分區(qū)，第一個分區(qū)就是原來的系統(tǒng)了，經(jīng)客戶確認，第二個分區(qū)就是原來的E分區(qū)的數(shù)據(jù)。經(jīng)客戶重啟計算機，確定數(shù)據(jù)完全正確，至此本次恢復(fù)完畢。由于遠程操作太慢，此次恢復(fù)竟然用了6小時左右時間。順便拋出一下問題大小討論一下：一般情況下，誤GHOST后造成只有一個分區(qū)的情況下是不會損壞后兩分區(qū)分的DBR的，而且客戶的系統(tǒng)分區(qū)有45G左右，一個XP系統(tǒng)怎么也不會有45G吧，也就是說應(yīng)該不會覆蓋掉后兩個分區(qū)的DBR，這兩個分區(qū)的DBR怎么會損壞呢？這個問題到現(xiàn)在我都還沒弄明白。Ntfs手動修復(fù)刪除文件對于數(shù)據(jù)恢復(fù)來說，雖然文件刪除后所有的數(shù)據(jù)運行都能夠在殘留的MFT中找到，但是數(shù)據(jù)運行的個數(shù)越少即文件碎片越少或者沒有碎片，文件被覆蓋的可能性就越小，數(shù)據(jù)恢復(fù)的概率也就越高。以下是手工恢復(fù)NTFS卷中誤刪除文件的過程。1. 需要恢復(fù)的文件NTFS卷中一個文件被刪除時，其MFT并沒有被刪除，前面已經(jīng)介紹過，這里以恢復(fù)一個NTFS卷中一刪除的文件為例，假設(shè)在用戶的NTFS卷D盤中有一個名為photo的目錄，該目錄下有一個名為“penquan.jpg”的文件，如圖5-1所示。假設(shè)用戶不小心將此文件刪除。圖5-1 NTFS卷中將被刪除的文件2. 找到要恢復(fù)文件的MFT首先通過WinHex選擇文件所在的邏輯磁盤將其打開，如圖5-2所示。圖5-2 選擇磁盤分區(qū)打開磁盤的分區(qū)后找到該分區(qū)的MFT，如圖5-3所示。 圖5-3 轉(zhuǎn)到MFT的起始位置3. 恢復(fù)數(shù)據(jù)找到分區(qū)的$MFT后，通過文件名查找文件的MFT，如圖5-4所示。圖5-4 查找文件的MFT查找到的結(jié)果如圖5-5所示。圖5-5 已刪除文件的MFT先來看看MFT頭，偏移15.16H為0表示該文件已經(jīng)被刪除了，系統(tǒng)根據(jù)這個標志來決定建立新文件時是否能夠覆蓋這個MFT而創(chuàng)建自己的MFT。10H屬性就不分析了，除非希望恢復(fù)的文件所有的時間屬性和以前一樣，用戶對此要求一般沒有那么高，所以跳過10H屬性不分析。30H屬性這里也不分析。關(guān)鍵是要分析80H屬性，即數(shù)據(jù)屬性，在該屬性所有的描述中，對恢復(fù)數(shù)據(jù)最有用的信息有兩個，一個是偏移00C12DD160H開始的8個字節(jié)的屬性是該文件的實際大小506E，單位是字節(jié)。還有一個地方是偏移00C12DD170H開始的數(shù)據(jù)運行位置描述，這里為十六進制數(shù)41H 06H 83H 0BH 90H 00H。其中41H定義了其后面有1個字節(jié)表示該文件的數(shù)據(jù)運行所占的簇的個數(shù)，4個字節(jié)表示該數(shù)據(jù)運行的起始邏輯簇號，這里定義了其運行占用了06個簇，其起始邏輯簇號為900B83H。知道了起始簇號和數(shù)據(jù)運行的真實大小，甚至知道運行所占的簇的個數(shù)，要恢復(fù)文件數(shù)據(jù)就很容易了。在WinHex中選擇“位置”|“轉(zhuǎn)換到扇區(qū)”命令，打開對話框，在“簇”文本框中輸入9440131（900B83H轉(zhuǎn)換后的十進制數(shù)），然后單擊確定，即可找到數(shù)據(jù)的起始位置，其中FFH DBH是.jpg照片的文件頭標志。在找到的數(shù)據(jù)起始位置右擊，選擇“選塊開始”命令。如圖5-6所示。圖5-6 文件的起始位置繼續(xù)在WinHex中選擇“位置”|“轉(zhuǎn)換偏移量”命令，打開“轉(zhuǎn)到偏移量”對話框輸入20590（506EH轉(zhuǎn)換成十進制數(shù)）如圖5-7所示。圖5-7 轉(zhuǎn)換偏移量單擊確定后會跳到文件的結(jié)尾位置，單擊右鍵選擇“選塊結(jié)尾”命令，如圖5-8所示，即可完全的選擇到用戶要恢復(fù)的文件數(shù)據(jù)。圖5-8 找到文件的結(jié)束位置選中所有要恢復(fù)的數(shù)據(jù)內(nèi)容后，在選中的任意塊上右擊，選擇“編輯”|“復(fù)制選塊”|“進入新文件”命令如圖5-9所示。圖5-9 復(fù)制所有數(shù)據(jù)然后將文件命名并保存到指定的路徑，如圖5-10所示。圖5-10 保存文件保存成功后，關(guān)閉WinHex，按照剛才保存的路徑打開文件，數(shù)據(jù)恢復(fù)成功，圖5-11是恢復(fù)后的文件。圖5-11 文件恢復(fù)成功案例Oultlook文件修復(fù)今天接到一個網(wǎng)友的求助 ，說是一個outlook.bft文件恢復(fù)出來打不開 。問我怎么辦。說實在 的，這樣的問題還沒弄過，但是 ，數(shù)據(jù)恢復(fù) ，異曲同工，我于是遠程了他。將他 的損壞 的這個文件用outlook打開，提示損壞。用winhex查看 其結(jié)構(gòu) ，發(fā)現(xiàn)其文件尾丟失， 復(fù)制好的文件尾 ，并修改相應(yīng)參數(shù)后，問題解決。佳能照片損壞恢復(fù)案例存儲介質(zhì)：4GSD卡佳能數(shù)碼相機故障描述：朋友介紹，照片在相機上顯示正常，所有圖片均能預(yù)覽，但拷到電腦上后，部分照片打不開，如圖1所示：圖1. 名為IMG_0683.JPG的大小為3965K的圖片無法打開于是朋友就把拷出來的照片又全部拷回去，以期能重新打開，后果可想而知，進一步擴大了照片損害程度?；謴?fù)軟件：WinHex、FinalData恢復(fù)思路：由于損壞圖片較大，初步判斷為文件頭損壞，手動修復(fù)文件頭即可。恢復(fù)過程：現(xiàn)以圖片IMG_0683.JPG為例，簡要描述恢復(fù)過程。首先，用Winhex做磁盤鏡像，避免進一步損壞數(shù)據(jù)。把損壞文件拷到本地，共58張（正常文件已被朋友剪切到本地），如圖2所示：圖2.58張損壞的圖片用Winhex打開IMG_0683.JPG，如圖3所示圖3. Winhex打開IMG_0683.JPG打開后嚇我一跳，前面近1M的數(shù)據(jù)幾乎都是有規(guī)律的數(shù)字，顯然是被篡改了，恢復(fù)并不像預(yù)想的改改文件頭那么簡單了。曾試過N多次把好的JPG文件頭以不同長度拷到損壞文件，均不見成效。在近乎絕望時我想到了FinalData，于是用FinalData恢復(fù)磁盤上所有文件，果然有新發(fā)現(xiàn)！在恢復(fù)出來的照片中通過對比58張損壞文件，發(fā)現(xiàn)有12張可用文件！至此成功恢復(fù)12張，還剩46張待恢復(fù)。接下來才是真正的恢復(fù)！在“Deleted Files”下面出現(xiàn)一個的“.JPG”文件夾，里面全是大小一樣，以所在扇區(qū)號命名的.JPG文件，如圖4所示：圖4. 用FinalData恢復(fù)的355個大小為1036K的JPG文件細心的我通過對比已損壞文件與.JPG下的文件屬性，發(fā)現(xiàn)：兩者圖片尺寸相等為4000X3000，圖2中的照片“修改日期”竟然有20張與圖4中的“相片拍攝日期”完全一樣！而且有預(yù)覽，但只能打開一半，如：圖2中的IMG_0683.JPG同圖4中的#69655.JPG。圖5、圖片#69655.JPG只能打開一半于是我大膽猜想：圖4中那20張日期相同的圖片極有可能是從原圖片中復(fù)制而來，原圖中隨機填充亂碼。那是不是把#69655.JPG的數(shù)據(jù)覆蓋IMG_0683.JPG的前半部就好了呢？說做就做，用Winhex分別打開#69655.JPG和IMG_0683.JPG，如圖6所示：圖6，用Winhex打開#69655.JPG復(fù)制#69655.JPG中的16進制數(shù)據(jù)，寫入（不是粘帖）到IMG_0683.JPG中，保存。再打開IMG_0683.JPG如下圖7：圖7，恢復(fù)好的IMG_0683.JPG恢復(fù)成功！分別用此法恢復(fù)另外19張圖片。至此58張圖片共恢復(fù)32張，其它由于數(shù)據(jù)被覆蓋，無法恢復(fù)?；謴?fù)心得：數(shù)據(jù)丟失不可怕，千萬別回寫數(shù)據(jù)，此案例中，若朋友別把損壞數(shù)據(jù)重新拷到卡上，說不定就能全部恢復(fù)了。前段時間，接到一某大型醫(yī)院的數(shù)據(jù)恢復(fù)單子。因為是設(shè)備連電腦的，現(xiàn)在硬盤出現(xiàn)壞道，且連系統(tǒng)都無法進入，要求恢復(fù)到能夠使用到某檢測軟件。因為儀器是德國進口，而且已經(jīng)聯(lián)系不上，估計是關(guān)門了?，F(xiàn)在軟件備份也沒有了。麻煩呀*)_未經(jīng)本人允許不得轉(zhuǎn)發(fā)+ 首先上MHDD檢測，16，000，000之前壞道大概上100個且不是連續(xù)的，上PC3K，直接做硬盤對拷。拷貝完成之后發(fā)現(xiàn)C為raw，意料之中的了。D盤文件全在，但是D盤資料是沒用的，客戶只要求需要恢復(fù)到系統(tǒng)的檢測軟件能夠正常使用。無奈之下，只有把拷貝好的硬盤掛電腦做副盤，然后用自己的XP系統(tǒng)進去做掃描，一段時間之后，掃描完畢。然后用windows xp的安裝盤進去做安裝修復(fù)。結(jié)果提示找不到原來的系統(tǒng)。把硬盤做主盤看了一下硬盤啟動提示什么先，結(jié)