此案例由于合同原因不对文件结构等具体性内容进行描述，也没有截图，只是把奋战两天的过程记录下来，算是个纪念吧！

客户描述如下：

     有一专用高速拍摄设备生成的扩展名为CI**的文件（其3 4秒钟的视频可能就有7 8G），大约为7G左右，使用文件系统为NTFS，逻辑盘大小为450G，在某次执行完毕时操作员从设备下载视频文件成功，在进行合成操作过程中进行了删除操作，操作员发现删除后，直接使用了FINADATA软件进行了扫描操作，产生了一定大约600多M的碎片很多的临时文件（当然这个是后续分析才知道的）。针对此种情况，客户提出了上门的要求，根据合同我们提供了×××。

分析过程：

       经过分析发现此类文件为特殊文件，文件结构和标准的AVI MPG等视频有极其大的差别，主要区别表现在标准的视频类压缩比例较高，而此文件可以说是高清了。在现场经过分析知道了文件头标识及相应的日期 时间在文件头中的偏移值（使用UNIX时间表示方法）。根据此情况，又根据该逻辑盘的其它正常的视频文件的分析情况（都是不连续的），得出结论此文件产生碎片的机率极高！

据此提供了第一套方案：

STEP1.通过对文件系统中的空闲簇搜索文件头标识，如果符合条件对文件头日期进行筛选，指定到用户所描述的日期，为了不漏掉对日期进行了模糊筛选的方法，即定一大概日期，只要符合此条件就为须要文件。

STEP2.定位到文件头所在位置后进行文件结构深入分析，看是否存在碎片，如果存在进行碎片定位。

第2步是建立在第1步的基础之上，所以先不进行第2步的深入分析。开始写程序，经过进行调试，程序可以正常运行，程序在扫描时会对空闲簇中全部为0的簇进行跳过的操作，这样会加快扫描速度。经过1个多小时扫描，得到了结果，令人遗憾的是没有发现用户所说日期的文件，此方案的失败，开始对用户所描述的末做任何操作产生怀疑！在WINHEX中对比文件日期发现有一大约有90多个碎片且簇跨度很大的文件是在做过删除操作的同一日期，看文件头为FINADATA*****（后续貌似是标签的意思想不起来了），再次沟通，用户说是做过扫描操作，用的就是FINADATA，但是他能看到文件名，文件大小却为0（在删除大于4G的文件时管理 文件会对文件记录中的文件长度为簇位置分布DATARUN进行清0操作），之后就再没有做过操作了。

到了这一步得到如下结论：

此删除的视频文件很有可能被部分覆盖了，因为那个FINDATA的文件跨度很大，但是长度却不是很大，而视频文件头可能就是被覆盖了，导致程序定位不到。下一步进行操作就必须对此视频文件进行深入分析，看其在数据区等位置有无标识区。对比样本文件，由于时间紧张，用户找来了做合成的老师做配合，通过电话沟通对此类文件有一个深入了解，很快制定了第二套方案。

STEP1.先进行管理区定位，看管理区是否存在，（由于 此文件管理区占用较少扇区也就20多个扇区，簇大小为8SEC，所以认为覆盖的可能性很大）

STEP2.直接进行数据区定位，由于搞清楚了此类文件的封装模式，搞清楚了分辩率（1600*1600，此类文件有两种封装模式，具体由于合同原因就不细说），进行数据区数据定位

STEP3.分析NTFS中原文件$BITMAP，得出空闲簇分配表，对大块区间进行重点关注

STEP4.提取符合条件的内容，进行合成。由于要合成须要写新的合成程序，通过和合成软件的老师沟通，针对合成的情况给出一个通过修改一个正常的视频文件的数据区（使用提取出来的数据区），并进行修改管理区参数的操作，从而“骗”过合成软件直接进行合成。经过测试此方案可行。

2号方案制定后和客户沟通，得到其认可。立刻进行修改程序的操作，经过程序进行扫描，提取了大量符合条件的内容（因为此盘也存在过很多同样格式的视频文件，做过很多删除提取操作）。对提取的内容进行在新视频中的修改，进行合成，合成 后让用户对比那些是其所须。

经过对比用户发现了其中很多符合条件的内容，对这些内容所在的提取文件名进行分析（文件名在程序中设定为偏移扇区所在），经过对比发现此文件可能产生过临时文件，剔除临时文件。继续分析数据区，通过比对，发现存在大约7个碎片，使用WINHEX合成碎片，重新生成新视频并修改管理区进行合成软件合成。合成后数据的连贯性得到了客户的认可，同时在起始和结束的一大部分可能是被覆盖了，起始部分破坏最大，这是比较遗憾的地方。

        至此恢复工作完成，用户对恢复的时间、质量给予极大的评价！综合恢复过程，可以大致判断文件在第一次删除后应该是完整的，但是后续产生的FINDATA临时文件由于跨度大的原因，对删除视频文件的起始和结束部分造成了破坏。

       此案例完成后我们也收获了此类特殊视频的碎片提取程序，有遇到此类特殊视频的朋友可以和我们联系。