Data Recovery with DVR Examiner: Accessible, Inaccessible, and VERY Inaccessible
How does DVR Examiner work?
Data recovery with DVR Examiner works by reverse engineering the many different DVR filesystems to locate and extract video footage. Most DVRs use a proprietary filesystem. Sometimes this is in conjunction with a known filesystem, often Ext 2 or 3, but even in these cases the video data is typically located in a large proprietary partition which won’t be recognized by conventional computer forensic tools. However, if you take a closer look at these “unallocated” spaces, you may find some familiar structures and multitudes of highly compressed video data.
While it seems that for every generalization we might try and make of DVRs and the way they store their data there is an exception, there are also some common tendencies. Most DVRs will not actually store “files” as we know them, certainly not the files in the same format that are exported from the DVR. Instead, these files are built when the video is exported.
How is the video data stored, and how does DVR Examiner extract it?
Usually the video is divided into blocks of data in a similar way to most other filesystems. These blocks are laid down roughly in chronological order, first from one channel, then another and so on. Data at the front of the drive, or sometimes the front of each partition if the drive is partitioned, will provide an index which identifies which block belongs to which camera and corresponds to which time period. This way, the DVR can quickly find the correct blocks for playback or export. Of course, when the space allocated for video data is full, the DVR will begin back at the beginning, overwriting previously recorded blocks in an endless cycle.
In a typical case, DVR Examiner will read and interpret these indexes so that it, too, knows which blocks belong to which camera and time. It can then provide a list of clips for all the video data on the system, usually in a matter of seconds. These indexes can then be used to rapidly find the blocks which it can then process to package the bytes up for export or interpret them for replay. This is the process behind an “accessible” scan, which is so named because any footage that can be located by these indexes should be visible to the DVR as well.
How does DVR Examiner find footage the DVR cannot see, such as after the hard disk in the DVR has been formatted?
Just as with regular computer forensics, the DVR doesn’t overwrite the video data. Instead it will modify the index so that it knows which blocks are no longer in use, sometimes by wiping the relevant entries, or sometimes by marking them in some way. This is like a regular filesystem, and similarly, DVR Examiner can attempt to recover the data that remains in these blocks. This is known as an “inaccessible” recovery.
The time it takes to perform an inaccessible recovery and the data that can be recovered varies from one DVR filesystem to another. Though there are similarities, this is not the same as file carving. The data is usually H264 video, often broken up into slices, each containing a single frame. Each of these slices is typically preceded by metadata in a proprietary format; proprietary frame-level metadata. This may include the channel number, the size, and the date and time. Sometimes the amount of metadata will vary from across different frames. Sometimes the slices will be recorded in such a way that each slice will be wholly contained within a single block, and in other cases block boundaries may occur within a slice. In this case it is possible for the start and the end of a slice to be separated by blocks of data, usually from another channel.
This means that whenever an inaccessible scan is performed it is necessary to look beyond the index and into the video data itself, parsing the headers to retrieve information such as the time, date, and channel to present the user with a clip. This is particularly difficult if the data is fragmented, often the case if the slices are large or the block sizes are small, or if the slices themselves can be broken by block boundaries. For this reason, inaccessible scans often take much longer than accessible scans, some taking hours if the filesystem requires a lot of parsing and the drive is of substantial size.
As with more traditional filesystems, some DVR filesystems which allocate data in blocks may leave slack space. Whether this occurs and how often will depend on the filesystem. For example, if a system is designed so that no slice of video is contained in more than one block, it will be unable to write to the very end of the block whenever the slice will not fit – which would often be the case. This could leave data from one or more previously recorded slices. Similarly, a system may require switching to another channel either because a certain period has passed or because a buffer has filled, leaving a section of the last block unwritten to. There are many reasons why a system could leave some slack space.
With a “frame level inaccessible” scan, DVR Examiner will not only examine blocks which are not indexed with a regular inaccessible scan but will also examine the slack space within the blocks that are. Whether this is effective, or even possible at all, will depend on the filesystem, the block size and the size of the slices of video as well as other factors. This is a very time-consuming process, but on those systems where frame level inaccessible scans are possible, it may be possible to retrieve data from months or even years in the past. Often this will be just a few contiguous frames, but in cases where you might be looking for a static object such as a parked car, or if you just happen to be lucky, those few frames may make the difference in your case.