資安論壇

行政院 國家資通安全會報 - 技術服務中心 - 資安論壇 http://forum.icst.org.tw/
現在的時間是 2012年 10月 22日, 03:54

所有顯示的時間為 UTC + 8 小時




發表新文章 回覆主題  [ 4 篇文章 ] 
發表人 內容
文章發表於 : 2010年 12月 1日, 11:31 
離線

註冊時間: 2010年 12月 1日, 02:15
文章: 3
***若不適合於本版發問此問題,請直接刪除,造成困擾請見諒***

請教!
狀況是這樣的~~~
這張CF卡是用在儲存拍攝的影音資料(單機拍攝沒有備份),大小是32GB,檔案系統是FAT32(0C),拍攝時Video和Audio共3個檔案是同時寫入的(Streaming),也就是說FAT的鏈排列肯定不單純...
拿到卡的時候,裡頭有拍攝的重要資料,到Winhex一看,MBR、DBR、兩份FAT、根目錄及下兩層目錄都不見了(都是零),好吧,猜想前幾個Clip應該也完蛋了,但資料區後面還有60幾個Clip看似完整,小弟先用Winhex把原始CF卡Clone到另一片同規格的新卡上,自此開始進行救援...
目前已經恢復好MBR、DBR、根目錄及底下應有的目錄結構,PC也都正常判讀,問題來了...FAT表那些交織的鏈小弟實在做不出來...
整理一下問題:
1. FAT表兩份都被填零,有可能用任何工具"強讀"出填零之前的狀況嗎?如果真能強讀,Clone出來的CF卡也能讀出來跟原始CF卡一樣的內容嗎?(恕小弟天真,哈!)
2. 如果拿原始CF卡給資料救援公司去救援,他們會怎麼處理?救得出來嗎?
3. 至此,小弟還能做哪些努力呢?
以上,還請各位先進指教,謝謝!


回頂端
 個人資料  
 
文章發表於 : 2010年 12月 1日, 12:05 
離線

註冊時間: 2002年 9月 25日, 10:57
文章: 8868
來自: R.O.C
用 FinalData Enterprise 試看看

_________________
天道循環,生死不昧,真空妙有,還於本然
諦聽我們的靈魂之聲,所有飄零的靈魂,此世虛幻,此生一夢,生者必死
勢不可去盡,話不可說盡,福不可享盡,規矩不可行盡,凡事太盡,緣分勢必早盡
貼圖空間
viewtopic.php?t=8816


回頂端
 個人資料  
 
文章發表於 : 2010年 12月 1日, 13:53 
離線

註冊時間: 2010年 12月 1日, 02:15
文章: 3
lu 寫:
用 FinalData Enterprise 試看看

謝謝您熱心回覆,小弟會去找這套軟體來試試看!

只是...
小弟不敢自誇,但小弟確實對FAT32相當熟悉,計算大小、Cluster位置、FAT規則這些都難不倒...
例如資料區中搜尋到一個需救援的2MB連續檔案(即同時間只有這個檔案在寫入),小弟可以輕易的在目錄區中自行添加檔名、副檔名、檔頭所在Cluster、檔案大小,然後到FAT表中添加一個鏈,再給個FFFFFF0F即可,如此即可完整救出這個檔案,只差建立時間與修改時間而已

但這個CASE,在3個檔案同時寫入的狀況下,勢必於FAT中記錄下3條交錯的鏈,如何交錯卻不可考,除非FAT是完整的沒有不見...
也因此,小弟比較懷疑有任何軟體、有能力在這樣的情況下回覆檔案,除非它真的能在被填零的區域中讀到甚麼資訊...
又也許,因為小弟對記錄媒體的底層原理了解不夠到位,所以不知道1個sector除了表面上看到的512Bytes之外,是不是還有甚麼看不到的秘密...(如果真有秘密,小弟超想了解,請大大指教!)

總之,小弟會去試這套軟體,有結果再來回報,謝謝lu大大!


回頂端
 個人資料  
 
文章發表於 : 2010年 12月 3日, 01:31 
離線

註冊時間: 2010年 12月 1日, 02:15
文章: 3
關於Finaldata Enterprise的測試,小弟作一下描述:

一、放1個300MB的AVI檔進CF卡,然後砍了兩份FAT,進行救援
結果:可找出這個連續檔案,並且成功COPY出來

二、放3個300MB的AVI檔進CF卡,趁第一個還沒結束就放第二個,同理再放第三個,故意造成3個檔案同時在寫入的情況,然後砍了兩份FAT,進行救援
結果:3個檔案都判定為連續,並成功救出(高興了一下,不過太早了...)

三、實際拍攝1個CLIP試試看,然後砍了兩份FAT,進行救援
結果:3個檔案都判定為連續,並成功救出,但回放時卻無法撥放,後來才發現,根本不是這麼回事

心得:
原來程式還是死的,無法像人一樣對讀到的資訊做出正確的判斷,拿上面3個實驗來說吧...
第一個實驗
電腦知道要寫一個300MB的檔案,所以在FAT中找出需要用到的(因為知道檔案大小)、連續的(空間夠的話)、空的Cluster位置,然後寫入,在FAT被砍後,救援軟體可以依據目錄區中的檔頭位址及大小兩項資訊,順理成章的找出這個檔案,根本不需要FAT,只因為這個檔是"連續的"...
圖示 111111111111111111111

第二個實驗
第一個檔同上,第二和第三個檔也一樣,都是已經先在FAT中預留好位置了(因為知道檔案大小),所以造成了3個"連續性",可被救出的檔
圖示 111111111111111111111222222222222222222222333333333333333333333

第三個實驗
Streaming寫入的狀況不同,因為開始寫入的時候不知道檔案是多大,所以只能一邊寫一邊等檔案結束
圖示 123321123121332112332112231213312132212133212332122112322313122
所以第三的實驗救出來的3個檔成了這樣
FILE1 123321123121332112332
FILE2 112231213312132212133
FILE3 212332122112322313122
沒辦法,因為救援軟體只知道檔案起始跟大小而已...沒了FAT,完全不知道自己在做什麼...
除非是一些常見的圖檔、影音檔,程式也許可以針對檔案的特徵去做出判斷

好吧!殘念,依舊要謝謝lu大大的建議,讓我也有所學習...
當然,還是要繼續請大家幫忙,還有甚麼軟體或招數,請不吝指教小弟!謝謝!


回頂端
 個人資料  
 
顯示文章 :  排序  
發表新文章 回覆主題  [ 4 篇文章 ] 

所有顯示的時間為 UTC + 8 小時


誰在線上

正在瀏覽這個版面的使用者:沒有註冊會員 和 3 位訪客


不能 在這個版面發表主題
不能 在這個版面回覆主題
不能 在這個版面編輯您的文章
不能 在這個版面刪除您的文章

搜尋:
前往 :  
POWERED_BY
正體中文語系由 竹貓星球 維護製作