好尴尬....

本来可以秒的业务，结果搞了一下午，怎么办？自己吹下的牛，含着泪也要圆回来

剧情是这样的

有个客户的摄像机sd卡文件系统损坏，提示格式化。本来是很简单的故障，分分钟的事，跟客户也是拍过胸脯的。结果.....

客户已经自行恢复过，恢复完后大部分视频可以正常播放，但是中间的主持镜头不能连续播放，中间还会穿插之前拍过的镜头，大概有20多分钟视频不能顺利播放（播放卡顿，中间穿插其他视频画面）数据不连续。 接下来我们来分析一下：

WINHEX打开卡的镜像后解析文件系统发现都是乱码，分析发现是USBC故障。。

USBC首先不是中毒，但俗称“USBC病毒”此类故障大部分发生在FAT移动介质，比如TF卡，sd卡，cf卡等之类，有的会严重破坏文件系统，当然有的只是轻微的破坏造成目录偏移篡改之类的。网上说的chkdsk不要用，会改写原始的数据，那样会造成文件系统的二次损坏或者彻底恢复不了，我们要保持原样(保护案发现场)！！！在这里我们只说winhex，winhex才是王道！因为本案例用普通recovery软件是恢复不了的，我甚至都尝试过写WINHEX脚本全盘来做，做出的效果还是不够理想，中间还是会参杂别的视频信息，结果也是不敬人意

上图出现乱码的目录也是因为文件系统偏移或损坏造成，起始DBR信息已经损坏，根据分析定位FAT表信息以及根目录起始位置确定了FAT表长度，以及簇大小64。手工回写了DBR信息，顺利展开了损坏的文件系统

但是目录结构里面刚好缺失掉中午的视频素材，心情顿时凉凉的，怎么办。。。不是手工矫正文件系统后顺利拷贝客户需要的数据吗？ 以前都是这样的。这次失手了，难怪客户找了几家都没有恢复出来，去年年底的视频拖到了5月。

一头又扎到十六进制里面，有种“识数寻踪”的赶脚（这是本书，有想了解的可以百度），根据以往恢复经验，大部分的MTS视频开始都是003F3F3F3F47400010（3F通配符），通过手工编写winhex脚本精准定位到数据的起始扇区20938752sec，成功截取了视频，大概2GB左右。通过播放软件播放，效果很差，隔几贞就会有别的视频镜头，很是卡顿。明显是视频碎片化存储了（本案例无数据写入，没有覆盖）。

根据该视频的起始扇区推算出对应的簇号（326786）上面，根据分析文件系统的FAT表发现只破坏了前面一个扇区，FAT表基本完整，因此我们把思路转到了FAT表上面。FAT 表中记录了每个文件的簇链结构； FAT 表中记录的与数据区簇对应的表项，从0号标记开始至当前数据区所分配的簇的****数值，记录簇信息到FAT 项；但是注意：其中 0号~1号簇的值都是操作系统预先不留设定的特殊标记，而数据区的起始簇是2号簇。

接下来我们的工作就是通过FAT表链对应的数据区，手工截取该视频碎片文件。。。工作量好大啊~

通过FAT表链，分段截取视频碎片，合并成1.9GBmts文件，顺利播放。没有辜负我们付出的努力,同时也祝视频里面的新人新婚快乐~~