[原创] TS安防监控视频恢复方法

[复制链接]
  • TA的每日心情
    开心
    2015-1-15 15:06
  • 签到天数: 1 天

    [LV.1]布衣百姓

    75

    主题

    579

    帖子

    6218

    积分

    Intohard Team

    Rank: 7Rank: 7Rank: 7

    积分
    6218
    QQ
    发表于 2022-11-15 20:55:37 | 显示全部楼层 |阅读模式
    目前国内安防监控产品已经越来越多,这类产品大多数采用嵌入式文件系统进行音视频文件的管理。如果想要提取数据一般是通过和安防监控主机提供的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。这个文件在播放查看时解析全部正常,这意味着完整性没有问题,数据区并没有被覆盖。

    这就是TS文件的恢复方法,大家在遇到此类问题时,可以和我们联系。

    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有账号?立即注册

    x
    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    快速回复 返回顶部 返回列表