📜 ⬆️ ⬇️

Data Recovery from the DVR

image

For many years, DATALABS has brought disks and flash drives from video surveillance systems to our data recovery center . This stationary and DVRs and car recorders. Mostly single-disk, but there are also many disk ones, and automobile ones, as a rule, with microSD.
Under the review of the cut as the process of recovery.


Problems of data loss are different:
')

1. Initializing Windows.


The data on the disk was. 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 a different kind of crime.
Since in the vast majority of DVRs, in the zero sector there is no standard Windows bootloader, that is, there is no magic signature "55AA", the Windows proposes to initialize the disk, with which the people successfully agree and thus kill the zero sector with the registrar info. And not always only zero ...
The classic Windows XP is zero sector, but other Windows like GPT, that is, EFI, and it rubs and the beginning and end of the disk. The trouble is that in some DVRs service information is not stored at the beginning, but in the last sectors of the disk.
Data recovery in such cases is reduced 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 the sector, but in most cases you need to edit it, because there may be information about the size of the disk, the beginning and end of the video stream, and something else that the Chinese brothers climb into their heads. If the substitution occurred successfully, then you can open the disk with software from the manufacturer’s website, or on the recorder itself.

Avtech AVC-776 zero sector example

image

2. Rhinos polazili on the menu.


The data on the disk was. But not qualified people inadvertently or intentionally press the disk cleaning in the menu of the recorder itself. This is perhaps the most terrible cases, in terms of the complexity of data recovery. As the main service data, calendars, attributes of occupancy and other delights rub.
There will have to seriously re-engineer the storage device on the disk. The naive people incite the usual recovery programs, but naturally they get a banana. In 95% of DVRs, typical file structures are not used, in spite of the fact that everyone has it written in Linux, it’s not a fact that ext2 / 3 / xfs is used. So it’s pointless 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 is in most cases easier, find where the description of the camera number is and scatter the stream around the cameras, then convert the resulting files into a digestible format with the same virtualdab or similar software. In both cases, you have to write software.
Pitfalls can be such: it is not always possible to programmatically emulate the operation of the recorder processor, that is, the encoding program cannot convert it, here you can try to feed these files to the software from the vendor vendor (if there is one). This software may not swallow the stream in a stupid, you will need to download backup files from the registrar and watch their structure. When backing up the recorder can form a header above the stream, you will need to deal with this header to form your own. The worst thing is that when these files are converted right away, let's say avi, and the stream there is no longer the same as on the disk, it will not work for analysis.
Although there is something pleasant in modern recorders, most people write in the H.264 kodak and the soft coding will easily swallow the stream, or even a freebie when you can give the file with the stream the extension mpeg and feed the Vlc ... But again, don't forget about the cameras, maybe one a frame from one camera, followed by one frame from another, etc., and maybe 25 frames each, and maybe even pieces of time.
If nothing happened with the stream, you need to force the registrar to show the data. From the point of view of reengineering this is the most difficult. Understand where and how the data is described, write the software that will regenerate it, blow it back to the registrar, sometimes this does not take weeks, but clients usually need it urgently ... after all, soon the court))) (almost wrote doomsday))
Thank God, if the software for such a registrar has already been written, nothing needs to be drawn, but the variety of registrars is great and we have a case, then a holiday.

image

3. Passed the cycle.


Often turn when the video was needed now, and the event was a long time ago. The discs 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 fray the old data, well, in a circle in general.
In most cases, there is nothing to catch, since everything is ground. But there were rare cases when the cycle has just begun and you can search "in the tail" for some scraps.

4. The recorder broke down.


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

5. Automotive.


There are two evils: deletion and underwriting.
Any software from the Internet can cope with remote ones, since there is a file structure and files as such, the main thing is not to write after deletion.
But with the lack of recording more difficult, then the software will not help. Pens, my friend, pens. Automotive store files MOV, AVI, etc. that is, it is already containers with a decorated flow. With its “cap”, “atoms”, etc., there are articles in nete about their structure.
The registrar creates, empty or with minimal data, a header-header, 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 a flash drive crashes out of the DVR, or a battery crashes, or God's providence (rather, Satan) does not allow a valid hider to form and the file is not working.
To restore such a file requires serious meditation and knowledge of the format.
It happens and a freebie, if the format of the DVR MJPEG. When the stream is a bunch of JPG images. Stupidly recovering all the jeeps, and doing the video with the notorious muvmeykerom. Although some clients like the storyboard, because the accident is a matter of seconds and in personnel as in the matrix).

Well, that's all like, the rest will answer in the comments.

Source: https://habr.com/ru/post/232771/


All Articles