Recovering data from a DVR


    For many years , disks and flash drives from CCTV systems have been brought to our DATALABS laboratory for data recovery. These are stationary video recorders and car registrars. Most of them are single-disk, but there are also many disk, and car ones, as a rule, with microSD.
    Under the cat, an overview of how the recovery process takes place.

    Data loss problems are different:

    1. Initialization of Windows.

    There was data on the disk. Either they did not know about the software on the manufacturer’s website, or there is no such software on the website at all, but they wanted to merge the necessary event onto the computer. Most often various kinds of crimes.
    Since in the vast majority of DVRs, the zero sector does not have a standard Windows bootloader, that is, there is no 55AA signature, Windows suggests initializing the disk, which people successfully agree with, and thereby killing the zero sector with the registrar info. And it’s not always only zero ...
    Windows XP Classic is a zero sector, but other Windows like GPT, that is, EFI, and it rubs both the beginning and the end of the disk. The trouble is that for some DVRs, service information is not stored at the beginning, but in the last sectors of the disk.
    Data recovery in such cases comes down to installing an empty disk in the DVR, formatting through the menu and subsequent analysis of the initial and last sectors. Sometimes you can stupidly replace a sector, but in most cases you need to edit it, as there may be information about the size of the disk, the beginning and end of the video stream, and anything else that comes to mind to the Chinese brothers. If the substitution is successful, then you can open the software disk from the manufacturer’s website, or on the recorder itself.

    Avtech AVC-776 Sector Zero Example


    2. Rhinos climbed the menu.

    There was data on the disk. But not qualified people accidentally or deliberately click Disk Cleanup in the menu of the recorder itself. These are perhaps the most terrible cases, in terms of the complexity of data recovery. Since rubbing basic service data, calendars, attributes of occupancy and other amenities.
    Here you have to seriously reengineer the storage device on disk. Naive people set ordinary recovery programs, but naturally get a banana. 95% of DVRs do not use typical file structures, despite the fact that everyone says that Linux is not the fact that ext2 / 3 / xfs is used. So it makes no sense to search for files.
    You can restore it in two ways, figure out how the stream is described, or cut the stream itself. The second in most cases is simpler, find where the description of the camera number is and scatter the stream through the cameras, then convert the received files to a digestible format with the same virtual dub or similar software. In both cases, you have to write software.
    Pitfalls can be like this: it is not always possible to programmatically emulate the work of the registrar processor, that is, the encoding program cannot convert it, here you can try to feed these software files from the manufacturer of the Wiereg (if any). This software may not swallow the stream stupid, you will need to download backup files from the registrar and watch their structure. With backup, the registrar can form a header over the stream, it will be necessary to deal with this header to form its own. The worst thing is that when these files are immediately converted, let's say avi, and the stream there is no longer the same as on disk, it will not be suitable for analysis.
    Although there is something pleasant in modern registrars, most write in the H.264 codec and the encoding software calmly swallows the stream, or even a freebie when you can give the file with the stream the extension mpeg and feed Vlc ... But again, do not forget about the cameras, maybe one frame from one camera, followed by one frame from another, etc., or maybe 25 frames, or maybe even pieces in time.
    If nothing happened with the stream, you need to make the registrar show the data. From the point of view of reengineering, this is the most difficult. To figure out where and how the data is described, write software that will generate it again, blow it back into the registrar, sometimes this doesn’t take weeks, and as usual, the clients urgently need it ... because the trial is coming soon))) (I almost wrote the judgment day))
    Thank God if the software for such a registrar is already written, you don’t need to draw anything, but the variety of registrars is great and we have no case, then it's a holiday.


    3. A cycle has passed.

    Often accessed when a video was required now, and the event was long ago. The disks on the recorders are not rubber, and depending on the quality of the picture and the number of cameras, they write a certain time interval, and then they begin to grind the old data, well, in general, in a circle.
    In most cases, there is nothing to catch, since everything is frayed. But there were rare cases when the cycle has just begun and you can look for “some tailings” “in the tail”.

    4. The registrar itself broke.

    Well, there is no need to restore anything, the data is left on the disk. However, there is an ambush that on the manufacturer’s website there is no software capable of displaying video from a disk, then either search for the exact same DVR, or still recover data using the above methods.

    5. Automotive.

    There are two troubles: deletion and underwriting.
    Any software from the Internet can handle the remote ones, since there is a file structure and files as such, the main thing is not to write after removal.
    But with over-recording it is more difficult, here the software will no longer help. Pens, my friend, pens. Automotive files store MOV, AVI, etc. that is, it is already containers with a stream. With its “cap”, “atoms”, etc., there are articles in their net about their structure.
    The registrar creates a header, empty or with minimal data, then writes the video stream directly and only at the end of the recording forms a valid header, thus a normal file is obtained.
    At the time of the accident, either the USB flash drive flies out of the DVR, or the battery flies, or God's providence (rather of Satan) does not allow the formation of a valid header and the file does not work.
    To restore such a file requires serious meditation and knowledge of the format.
    There is also a freebie if the format of the MJPEG dashcam. When a stream is a bunch of jpg pictures. Stupidly you recover all jeepegs, and you make a notorious movie maker video. Although some customers like the storyboard, as an accident is a matter of seconds and personnel-like in the matrix).

    Well, that’s it, I’ll answer the rest in the comments.

    Also popular now: