analyzing-mft-for-deleted-file-recovery

概觀：analyzing-mft-for-deleted-file-recovery 技能

這個技能能做什麼

analyzing-mft-for-deleted-file-recovery 技能可協助你分析 NTFS Master File Table（$MFT），以還原已刪除檔案的中繼資料，並在可行時找出內容或路徑歷史的線索。它是為 DFIR 工作而設計，不只是在做「找回刪除檔案」，更重點在重建檔案曾經存在的樣貌、變動時間，以及時間戳或中繼資料是否被動過手腳。

誰適合安裝

如果你在 NTFS 磁碟區上做事件回應、鑑識初篩或 Security Audit，而且需要一套有結構的刪除檔案復原流程，就應該安裝 analyzing-mft-for-deleted-file-recovery 技能。當你手上已經有映像檔、原始 $MFT，或 MFTECmd 的輸出，並且需要可重複的分析，而不是泛用提示詞時，這個技能特別合適。

為什麼它有用

它的主要價值在於實際的工作流程支援：聚焦於已刪除記錄、時間戳、$UsnJrnl、$LogFile 與 MFT slack space。這種組合比單純的「解析 MFT」提示詞更能提升資訊增益，因為它鼓勵交叉比對，而不只是列出記錄。

如何使用 analyzing-mft-for-deleted-file-recovery 技能

安裝並先檢查正確的檔案

依照 repo 說明中的安裝路徑執行：npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill analyzing-mft-for-deleted-file-recovery。安裝後，先閱讀 SKILL.md，接著看 references/workflows.md、references/api-reference.md 與 references/standards.md。如果你要驗證輸出品質或報告格式，最好提早打開 assets/template.md，讓你的提示詞和預期交付內容一致。

提供能直接辦案的輸入

analyzing-mft-for-deleted-file-recovery usage 最適合在你一開始就提供三樣東西：證據來源、問題、限制條件。比如說：「分析這份來自 C:\Users\...\NTFS 的 MFTECmd CSV，找出已刪除檔案、可能的刪除時間，以及 timestomping 指標；請回傳精簡的 Security Audit 摘要。」這會比「幫我找回刪除檔案」更有用，因為它直接告訴技能該優先產出什麼。

依照 repo 的工作流程順序來做

實用的 analyzing-mft-for-deleted-file-recovery guide 流程是：先擷取或提供 $MFT，再用 MFTECmd 或 analyzeMFT 解析，接著篩選已刪除記錄（InUse = False），比對 $SI 與 $FN 的時間戳，然後交叉參照 $UsnJrnl 和 $LogFile 來補足序列與刪除脈絡。如果你懷疑只能部分復原，主解析完成後再檢查 MFT slack space，才不會漏掉殘留的屬性資料。

用輸出限制提升提示詞品質

在要求分析時，先指定你要的格式：表格、時間軸、初篩筆記，或可直接納入報告的摘要。也要說清楚你要的是只有已刪除記錄、只有 timestomping 可疑項目，還是完整合併時間線。若是 analyzing-mft-for-deleted-file-recovery for Security Audit，就要求明確結論、信心說明，以及任何證據缺口，這樣結果才適合放進審查資料包。

analyzing-mft-for-deleted-file-recovery 技能常見問題

這只適合做已刪除檔案復原嗎？

不是。這個技能以已刪除檔案復原為核心，但也支援時間線重建與反鑑識檢查。如果你的實際任務只是一般 NTFS 初篩，且沒有刪除或時間戳爭議，那麼通用的檔案系統鑑識提示詞就可能已經足夠。

一定要用 MFTECmd 才能發揮效果嗎？

MFTECmd 是最自然的輸入路徑，但不是唯一選擇。這個技能也能對應 analyzeMFT 和原始 MFT 檢視。如果你只有磁碟映像，還沒有解析結果，先擷取 $MFT 或先產生 CSV，通常會得到更好的結果。

初學者適合用嗎？

可以，只要使用者能提供證據與清楚的問題。對初學者來說，這個技能比空白提示詞更有幫助，因為它會把人導向正確的證據項目與檢查方向。若使用者連 NTFS 磁碟區和一般檔案清單都分不清楚，那就沒那麼適合。

什麼情況下不該用？

如果檔案系統不是 NTFS、案件沒有刪除或時間戳問題，或者你需要的是完整內容 carving，而不是以中繼資料為主的復原，就不要用 analyzing-mft-for-deleted-file-recovery。在那些情況下，換一套鑑識流程會更快。

如何改進 analyzing-mft-for-deleted-file-recovery 技能

給它更強的證據，不只是目標

更好的輸入會直接說明來源與範圍：例如「來自一台工作站的 MFTECmd CSV，聚焦 Downloads 中已刪除的文件，請包含父層路徑與刪除指標。」這比「分析 MFT」更好，因為技能可以先處理相關列，而不是把全部內容都攤開來摘要。

要求正確的鑑識比對

品質最關鍵的驅動因素，是 $SI、$FN、$UsnJrnl 和 $LogFile 之間的比對。如果你在意 analyzing-mft-for-deleted-file-recovery skill 的輸出品質，就應該要求模型解釋不一致之處，而不只是列出時間戳。這有助於抓出 timestomping、重新命名歷史，以及那些雖然已刪除，但仍保有可用路徑中繼資料的案例。

留意常見失誤模式

最常見的失誤，是從不完整的中繼資料過度宣稱復原確定性。已刪除的 MFT 記錄可能保留檔名與時間戳，但不一定保留檔案內容。另一個常見問題是忽略重新配置風險：如果記錄已被重用，復原出的細節可能只是一部分，甚至會誤導。要明確要求技能把已確認事實和推測內容分開。

用更精準的第二輪提問迭代

拿到第一版輸出後，可以用更窄的提示詞再追問一次：「重新針對只有已刪除記錄、且 $SI 與 $FN 建立時間不一致的項目做分析；回傳一個簡短的發現表和一段 Security Audit 結論。」這樣能逼技能先排序證據，而不是把資訊重講一遍。