The introduction of DVR Examiner 2.0 brought big changes to our user interface and workflow flexibility. While some of these changes brought their own challenges, we have been hard at work fixing bugs and updating the program.
Brad Barkhurst, a Forensic Specialist Supervisor, recently reviewed his experience with using DVR Examiner in fire investigations.
When we released DVR Examiner 2.0 this past July, we made a number of significant improvements to the program and user interface. However, we recognize these changes did not come without their challenges. I want to take a minute to break down the decisions we made and share what we are doing to address some of the challenges and concerns you have encountered.
You have shown up at your local convenience store where an unfortunate homicide has taken place, and your suspect is on the loose. Looking at the ceiling, you notice a plethora of cameras looking in all directions, including one trained on the front door. The manager of the establishment takes you back to the DVR - its lights are blinking and fan whirring and the manager tells you “I have no clue how to use this thing, or if it even works!”. How do you recover the footage you need? Time is ticking…
When it comes to adding support for new DVRs into DVR Examiner, or recovering video manually for a laboratory case, understanding the proprietary metadata of a given DVR filesystem is critical.
While I will be posting a series of posts over the next few months on understanding the proprietary structure of DVR filesystems, I wanted to share some information about Hikvision systems that was recently requested.
Most DVR filesystems store key metadata in 2 different places: the index(es) and at the beginning of each frame. In the case of the Hikvision-based systems, the index information is stored at the end of each data block, and provides a date time range per channel for the clips within that block. In this metadata, the date time is stored as a traditional Unix epoch timestamp (seconds since 1970). However, the date/time metadata at the frame level is stored in a very different manner.
We are often asked what type of DVR system someone should purchase for their home or business and if there is a specific brand or model we recommend. The truth is, it is usually more about how you configure the system (including the cameras) than which system you buy. Sure, there are some really cheap systems out there which will limit your capabilities, but there are plenty of very expensive systems out there which (when configured incorrectly) can result in even worse video.
Two questions I am often asked are “What type of forensic video analysis system should I buy?” and “I have “X” system and I’m really comfortable with it, should I get another one or is there something better out there?”. I’ve answered this enough times that I figured I’d actually put it down in a blog post. As you’ll see, my goal in this post isn’t to recommend one specific system over another, but to present some things for you to consider when looking to acquire a new system.
Occasionally, you will encounter video clips that only appear to display the first frame when played in VLC. When this occurs the progress bar continues to move but no additional video frames appear to be displayed. “Scrubbing” across the video will sometimes allow you to move to a certain position beyond the first frame, but even this doesn’t always work. We recently had a DVR Examiner user ask us about this. They were reviewing AVI files exported from DVR Examiner and some of them played fine in VLC and some simply froze at the first frame.
Many computer forensic examiners utilize the E01 forensic image file format to store bit for bit copies of hard drives used in their examinations. It is the default imaging option for many computer forensics tools and has become a defacto standard of sorts.