小米米家智能摄像头mp4多碎片手工恢复案例-编程知识

小米米家智能摄像头mp4多碎片手工恢复案例

智能摄像头品牌中小米算是绝对的大厂，其采用的方案也是比较成熟比较典型的：日志+截图+1分钟1个文件。小米米家的智能摄像头之前处理过很多，这次来讲一个比较特殊的案例。

故障存储: 32G TF卡 fat32文件系统簇大小32sec

故障现象:

此卡被格式化后重新使用了很短的时间，生成的文件容量大约578.14MB，剩余空间还有29G（如图1）。

图1：卡的剩余空间还有29G

故障分析:

小米的智能摄像头之前处理过不少，基本上规律如下:

1、1分钟生成一个文件。

文件格式为MP4，新式摄像头一般使用HVC高清编码。

3、采用的方案是在生成当前MP4文件结构体时，已经在采集新的视频画面数据，此时会导致两个文件碎片交叉，糟糕的是有时候碎片的大小仅仅只有一个簇，即碎片又小又多。

第3条会产生最不愿意看到的情况-----“音视频”数据区交叉，HVC采用的也是压缩算法，其会对采集画面进行量化后压缩，对于压缩来讲就是为了让数据不在松散，所以根本没有任何规律而言（有规律的一定是结构体而不是数据本身），此种情况下恢复难度是很大的，因为就算用CHS零壹视频恢复系列软件，也无法甄别数据区交叉碎片的情况，这个时候只能通过穷举遍历法结合恢复经验来判断。

图2：16.6M的文件碎片数量

可能觉得文件的碎片并不多仅有4个，不要被这个假象所迷惑，因为这个是格式化之后生成的文件，小米智能摄像头这种方案文件的碎片是会随着IO次数的变多而不断增加，后期此方案我们恢复出来的碎片数量最多的是480个，普遍在300个碎片以上。这也就是这个案例的特殊之处：

块(簇)大小为32SEC，块(簇)是文件系统分配的最小单元，其值越小意味着碎片数量更多，小米常见的块（簇）大小是64SEC;
文件容量更大，可能是摄像头分辨率更高吧，所以导致文件容量是常见的一倍还要多一点（常见的一般是4M到8M，此案例中文件大小基本是在12M到18M之间），更大的容量意味着需要的块（簇）数量更多，也就意味着碎片是常见案例的几倍甚至十几倍。
客户指定的时间段区间较大，近一个小时，这个也是之前案例中没有的。

故障处理:

根据这种复杂的情况，通用型的恢复软件是无法恢复的，原理如下：

删除或者格式化后FAT32或者exfat 都会对FAT表进行清0，清0后存在碎片的文件是无法得到有效的链表的，没有链表就无法得到准确的数据。
由于文件不连续存放，所以此时通用型恢复软件只能通过目录项中的文件第一簇指针和文件长度，来定位文件头。然后按照连续存放的方式读取，这就导致恢复的文件除了第一簇其它全是错误的。

图3：通用型恢复软件R-Studio新版本增加了文件校验并提示发现存在碎片，文件当然是无法播放的。

但是我们可以使用通用恢复软件来扫描并定位文件的目录，FAT32格式化后只要目录项所在簇没有覆盖就能定位文件的第一个簇，也就是文件头所在，在来定位文件尾，两者之间就是数据区间

由于文件名中就包含了日期和时间所以这个也可以精确定位到客户需要的文件，经过通用软件扫描发现客户要的文件名都在，而且第一簇起始是相对靠中间的，所以恢复的机率还是比较大的。

下边这些话照抄之前的案例，解释的很清楚，就不再码字了 :-） :-） :-）

下图可以看到通用恢复软件只会定位到文件目录所在的第一个簇，也就是文件头所在，但是后边的区域就是直接以长度获取了，所以肯定是不能用的。通过这个方法成功定位了客户所要的时间段，由于是采用裸流，所以计划提取文件头所在的簇，得到第一帧画面，来和客户确定数据。但是发现失败了，因为以一个簇为单位进行提取发现视频帧是不完整的，说明碎片极小可能只有一个簇的大小（可以理解为首帧长度>簇长度）。其原理如图5，第一帧至少有三个DATA分割分别是DATA0~DATA2,注意DATA区本身就是对现实环境抽象化取值再转换成数字化的底层数据其是压缩类数据，没有参考值。另外就是图5中是为了方便介绍用了比较简单的方式，现实中可能DATA1和DATA0会“距离”很远，极端情况下也有可能DATA1位于DATA0之前（这在所有文件系统中都是允许的）。