TS安防监控视频恢复方法

目前国内安防监控产品已经越来越多，这类产品大多数采用嵌入式文件系统进行音视频文件的管理。如果想要提取数据一般是通过和安防监控主机提供的USB接口连接存储设置，然后安防嵌入式文件系统会把存储在硬件上的264、265裸流通过管理程序合成为mp4类的通用多媒体文件，一些老式的设备可能合成的是AVI类文件。今天我们要说的这个案例很罕见，其合成的竟然是TS类文件，另一个让人惊奇的是自定义的TS类文件。下面我们一起奇“文”共赏！

故障存储: 1T机械硬盘

故障现象:

TS类文件是从某安防监控设备上获取的指定时间段的文件，这些文件后来存储在一块1T的移动硬盘上的第二个大小为403.44G的逻辑盘上。后来这些文件被人为全部删除，而安防监控由于存储时间周期的原因，原始文件已经被彻底覆盖。所以目前的恢复重点就是403.44G的逻辑盘，这个逻辑盘采用了NTFS文件系统。客户需要的文件是某个摄像头2022年6月18日15点30分到20点30分的一个文件，这个文件时长约5小时，具体文件大小客户并无印象。

故障分析:

NTFS删除文件的恢复不是什么难事儿，就算是文件不连续存放，存在碎片的情况。可以通过定位$MFT、INDEX、LOG等多种方式来获取文件的属性，比如$MFT获取文件名、大小，最关键的是获取datarun，这样就可以解析出文件的起始簇指针、每个簇块的长度等信息。有了这些信息就可以定位每一个碎片，然后再合成就得到了真正的数据。

但是问题就出在这些文件删除后，又做过写入操作，覆盖已经产生。新写入的文件会对删除文件的$MFT以及数据区造成威胁。但是由于删除文件数量和容量都比较大，而且后期写入文件数量不多且容量也不大，所以此文件的恢复还是有机会的。先用RStudio进行扫描，这个软件针对文件系统类的扫描效果还是不错的，像NTFS可以把$MFT、INDEX、LOG都全部扫描。但是扫描后却发现，能找到客户指定的文件名，但是此文件大小长度为0字节。

故障处理:

可以看到上图中文件名中包含了摄像头名称、起始时间和结束时间，这个是典型的安防监控合成文件的命名方式。现在的问题是为什么文件长度为0字节？这个答案和NTFS文件系统对删除文件的操作有关，如果一个文件长度大于4G，那么删除后除了做MFT元文件删除标识外，还要额外对此元文件的80属性进行清0操作，清0对象为：

1. 文件长度属性值
2. Datarun---（簇块组的起始指针和簇列表）

如果元文件较大存在独立20属性页的并不会清空20属性及下属页，撇开20属性页，就这两项清0对于定位文件就是致命的。这个是导致RStudio无法解析文件长度的重要原因。下图为此文件元文件截图,可以看到80属性的值都被挨个清0了。

到这一步基本上可以确定通用恢复软件是无法恢复此类情况的，文件系统层面解决问题是不太可能了。唯一能想到的就是通过解析TS文件结构进行底层RAW级恢复，如果文件存在碎片还需要重组碎片，最麻烦的是这个TS流是存在自定义的，当然这个无可厚非，因为TS标准本身就提供了这种冗余，允许自定义。

先来简单介绍下TS流，各位感兴趣的可以自行百度，下边贴一张TS流的包结构图

TS流:                     

  +-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |  TS   |  =  |  Packet 1 |  Packet 2 |  Packet 3 |    ...    | Packet n-1|  Packet n |

  +-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

一个Packet:             4bytes             184bytes        

  +-+-+-+-+-+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |  Packet | =  | Packet header |       Packet data       |

  +-+-+-+-+-+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

可以看到一个TS包长度固定为188字节，其有一个包Header+184字节的包data，真正的视频流和音频流，是打包封装在包data中的，如果一个流长度超过了184字节那么会分割成N个包来存储，当然这需要有分割标识。解决了流的封装还需要有元文件编码信息，这样才能解码,TS通过提供PMT和PAT做为编码参考，这样一个编解码的方案就完成了。通过PMT和PAT编码参考信息，播放器可以直接定位视频包和音频包并进行解码。这种方式的优点是包小，如果有问题直接扔提解码下一帧就行，前后帧并不影响纠错能力强，易于传输，这和MP4有天壤之别!

好了再来说说这个自定义的事儿，主要涉及到PID值和adaptation中的ID，不知道出于什么原因除了PMT之外PAT开始到数据流包全部是自定义的，个人猜测可能一开始厂商想要用自己的播放器来解码，但是可能后期发现没必要，而这些改了的值就没有再改回来！

整理这些自定义值，然后制定程序算法，通过不断测试最终程序达到了预期效果,以下为程序运行截图。

程序发现文件数量为663个，经过甄别成功找到了这个时间段的数据，此文件有26个碎片，最大的2G多，最小的只有9M多，由于时间关系，重组这一步直接手工完成。因为程序自动调节了簇对齐，经过对比发现都没有问题，使用WINHEX的文件连接功能，把文件拼接到一起，最后此文件总容量为4.3G，长度已经超了4G这和之前分析的情况完全吻合!

以下为此文件信息截图，可以看到时长是4小时59分，仅仅有一个视频流，并无音频流，视频流编码为HEVC,反向推断此安防监控的视频编码为265。这个文件在播放查看时解析全部正常，这意味着完整性没有问题，数据区并没有被覆盖。

这么如此罕见的案例很值得记录下来.