故障存储: 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文件的恢复方法,大家在遇到此类问题时,可以和我们联系。
CHS实验室官方QQ群I:11391767 QQ群II: 758414867
客服QQ:490476236 微信:151 3508 5893