Quite an old format, but it highlights some handy tricks!
Before the .PAR file extension now commonly used by Dedicated Micros, as discussed here and here, the first Digisprite DVR’s exported their footage with .DAT. They were very popular and are still widely used. The player is exported on the disk and autoruns if the feature is enabled in a modern PC.
When the .DAT file is loaded, the first issue can be seen.
The players video window is highly distorted, with a strange Display Aspect Ratio. The date and time information is displayed along the top of the image. The software is limited in terms of functionality with the ability to select camera/channel number by right clicking on the picture. There is a function to save a snapshot, under the File option menu. Interestingly, the size of images being saved are 720 x 512 and not as displayed in the player.
I had two tasks:
1. Identify a method to quickly deal with all 6 Channels of video in the file
2. Identify timing issues and validate the times displayed
By viewing the .DAT file in a Hex editor, (HXD was used here), I can see that it has a jpeg header and then various pieces of meta-data before the image data itself. By scanning through I could see that it was a file made up of separate images.
There are a few tools to extract all the jpeg’s as files but one of the easiest is JPEGsnoop.
This little tool make it very easy to review the digital makeup of the file, the meta data and allows you to extract all the jpegs. There are times when this automated tool doesn’t work and in these circumstances I usually lean on Scalpel to carve all the jpeg s manually.
Search for Scalpel in Linux repositories or use this GUI for Windows.
Before extracting all the images, I identified the recorded resolution was 720 x 256….. have to come back to that one!
Anyway, JPEGsnoop worked here and in 10mins I had a folder with over 20,000 jpegs! Dealing with all these and separating them up into Channels/Cameras could be a bit problematic but I have found that using Virtualdub is an easy method.
Open Virtualdub and then File > Open. Select files of type and chose Image Sequence. Select the first image of of the images extracted and then they load in sequentially. Obviously, the problem is that they are in camera order. In Video > Frame Rate, there is option to decimate the output. This means that it will only output every 6th frame. By Choosing a different ‘IN’ point each time, starting at a new camera and then outputting a new uncompressed AVI file, within a couple of minutes I had 6 AVI files for each camera.
For the purpose of demonstrative video, I used the frame rate displayed in the original player of 1 FPS. For sizing, I upscaled the vertical x 2 to give a 720 x 512 image. The videos were then suitable for viewing.
I have often wondered why CCTV manufacturers think that timing information is such a big secret and hide it away in the video or in some undecipherable index file. It is REALLY important and whilst we are on the subject, if you have developed functions to export video from your software remember to give investigators the ability to export the time / date info as well. There are standards for subtitle tracks – please use them!
Anyway, I digress! Finding the date and time information can be rather laborious but a handy utility is Hex Chomper. Firstly, copy the hex that you believe will contain the date and time information. I think its somewhere in the highlighted Hex!
Then paste it into Hex Chomper. Select all date types, and a From and To date parameter – then hit the Chomp button (looks like PacMan).
Get Hex Chomper and other great utilities from Mikes Forensic Tools
Hex Chomper has found the date I was looking for and I then confirmed this with the players interpretation of the time.
There was one more point though. A second is a long time in the video world – there are things called milliseconds. After the hex for date and time there are two more bytes. 00 5c.
By looking at these in a converter, it gives the milliseconds in Decimal.
So, by reviewing the hex of any of the extracted jpegs, it is possible to identify the exact encoding time of each image.
I hope some of this is helpful, as always let me know if it has!
A regular blog reader has now spent a bit of time analysing the other DM Formats and has found that they all have a similar UNIX timecode. I have posted the details here with his permission.
.dat (PC Playback) : Unix time + 2 byte (ms) (both big endian)
.dat / .idx (Video CD Player) : Unix time + 2 byte (ms) (both big endian)
.dmi (PC Playback): : Unix time + 2 byte (ms) (both big endian)
.par (NetVu Observer) : Unix time + 2 byte (ms) (both little endian)